Angular Frondend app with multiple 'decoupled' modules

[giuseppe.corti]

Hi Megabyzus,

The 'CONNECTED' prefix actually guarantees that a physical connection with the server has already been established.
Only in the 'CONNECTED: STREAM-SENSING' case, which should be a quick transient, the client library is still evaluating the most suitable transport (Websocket, HTTP-Streaming, or polling) to use for the client session depending on the network conditions of the client.
Anyway please double check the documentation for all the casistics: https://sdk.lightstreamer.com/ls-web...onStatusChange

Finally, please let me stress out again that for subscribe requests you should not care about the status of the LightstreamerClient.

Regards,
Giuseppe

[Megabyzus]

Thanks. I'll look into that further. I have all this working nicely and in the final optimization steps of the code. So:

1. Given we get a subscription object via

let subscription = new Subscription(subscriptionMode, items, fields)

is there a way to do a reverse look up to get a subscription based on a given item? I.e.:

let subscription = new GetSubscription(item)
(see NOTE 1 below for my solution)

2. Similarly, if I RE-subscribe to the same EXACT 'items' array above do I get the same subscription reference or a new one?

The reason for this, as always, is decoupling. In this case, I've already decoupled various modules of the app to use the same Client instance (vertical decoupling) and if no CLIENT exists to create their own.
Similarly, I'm also decoupling the UI components inside the module to not be concerned with their stream or subscription source (in this case Lightstreamer and Subscription) which is 'horizontal decoupling' within the module. The most the UI components know about is a string (we internally call a 'topic') where a separate decoupled service can construct an 'item' from that 'topic' to pass to a

let subscription = new Subscription(subscriptionMode, createItem('topic'), fields).

Similarly when the UI component is destroyed it will unsubscribe('topic') as its last act--it knows nothing of Clients or Subscriptions or Lightstreamer and only knows the 'topic' string. I ideally do not want to manage my own Map<topic, subscription> internally OR pass the subscription handle or any other LS artifacts to the UI components.

NOTE 1: Given the documentation, reverse look-up can be done by the following psuedocode;

let subscriptions = _lightstreamerClient.getSubscriptions()
for (subscription in subscriptions) {
let items = subscription.getItems()
for (item in items) {
if item.includes('topic') exit both loops with found subscription object...
}
}

NOTE 2: For your reference, I'm managing that decoupled service using an NgRx state machine.

Thanks.

[giuseppe.corti]

Hi Megabyzus,

Thank you for the feedback about your integration process.

About your questions:

1. I can confirm that the combination of getSubscriptions and then getItems, as per your pseudocode of NOTE 1, is a good solution since there is no direct method that returns the set of active subscriptions for a given list of Items.

2. No, if you call subscribe with the same parameters (mode, items list and fields list) of a previous one the LightstreamerClient will create a brand new subscription in addition to the old one.
Basically you will receive the same data twice.

Regards,
Giuseppe

[Megabyzus]

Hi Megabyzus,
1. I can confirm that the combination of getSubscriptions and then getItems, as per your pseudocode of NOTE 1, is a good solution since there is no direct method that returns the set of active subscriptions for a given list of Items.

Thanks. To be clear, since there is no 1 - 1 correspondence between items and subscriptions (i.e. we can have multiple subscription references to the same items and vice versa) then my pseudocode needs to be modified to return an array of subscriptions for identical items. Then those array elements need to be individually unsubscribed. In other words, questions 1 & 2 in my mentioned post were related.

Thanks!