refactor(ama-mfe-ng-utils): simplify resize directive

[maxokorokov]

Proposed change

This is for discussion first, I haven't modified tests yet.

Simplify resize directive and message consumer. Three changes:

1. Using [style.height.px] simplifies things greatly
2. connectId is handled at the consumer level, not at the directive level. Also I don't see the point in providing it in root as it is tightly coupled with connectId and directive instance.
3. I'm not sure I understand why there are both [connect] and [scalable] inputs? Can we just remove scalable input and use connect? I don't really see the point in specifying BOTH.

WDYT?

[nx-cloud]

View your CI Pipeline Execution ↗ for commit 6b0457e.

Command	Status	Duration	Result
nx run-many --target=test-e2e	✅ Succeeded	3m 20s	View ↗
nx run-many --target=test-int	✅ Succeeded	1s	View ↗
nx run-many --target=build --projects=eslint-pl...	✅ Succeeded	<1s	View ↗
nx run-many --target=publish --nx-bail --userco...	✅ Succeeded	31s	View ↗
nx affected --target=test --collectCoverage --c...	✅ Succeeded	35s	View ↗
nx run-many --target=prepare-publish --exclude-...	✅ Succeeded	7s	View ↗
nx run-many --target=documentation	✅ Succeeded	1m 26s	View ↗
nx run ama-sdk-schematics:build-swagger	✅ Succeeded	4s	View ↗
Additional runs (3)	✅ Succeeded	...	View ↗

---

☁️ Nx Cloud last updated this comment at 2025-04-02 22:19:02 UTC

[matthieu-crouzet]

LGTM

[mrednic-1A]

nice work :) it simplifies a lot the things. ok for points 1 and 2.
For 3 still ok, and as you changed the selector of the directive there is no need of scalable input :)

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 72.60%. Comparing base (9a333ef) to head (6b0457e).

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[maxokorokov]

@mrednic-1A, @kpanot, @matthieu-crouzet please take another look.

We've decided with @mrednic-1A to simplify it even more and remove completely the notion of 'who was resize message sent from'. We might introduce it later if necessary at the higher ConsumerManager level.

[kpanot]

If I understand well, with this change we will then limit the application to a single scalable iframe per app without strange behavior.
Not sure we want to bring this limitation at this stage to simplify the code.

[maxokorokov]

Hey, yes, of course one day we might need a mechanism to support multiple apps visible at the same time (ex. resize and subroute navigation). It's just today's consumer/producer model doesn't support this, because they're not configurable and register via DI.

I'd say passing and appId as a part of a data model every time is not the best way to do it ;) ex. if we have other app-specific messages?

We need something like, even though it is not probably the best way to do it:

consumer.configure({
  from: ['appId']
})

// or make `.start()` configurable:
consumer.start({
  from: ['appId']
})

I'd also argue that it is not up to ResizeDirectve to configure the consumer, but to one who knows the appId (iframe level?). I can go further and argue that ResizeDirective shouldn't even exist just to do [style.height] binding, but it should be done by the iframe wrapper (but I won't ;).

I can add configuration in a separate PR, or later if necessary, I just don't think resize directive should even know about appId.

WDYT?

[maxokorokov]

Here, I made a picture ;)

Basically the same way as switching by message type at the consumer manager level, we should also allow consumer instances to filter who the message is from

Maybe just adding from to the BasicConsumer would do the job:

export interface BasicMessageConsumer<T extends Message = Message> {
  type: T['type'];
  from: string[];
  supportedVersions: Record<string, MessageCallback<any>>;
}

or at the lower level (.start() or .configure()):

export interface MessageConsumer<T extends Message> extends BasicMessageConsumer {

  type: T['type'];
  supportedVersions: {
    [V in T['version']]: MessageCallback<T & { version: V }>;
  };

  configure(config);
  start(config): void;

  stop(): void;
}