You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If I have some state that I want to synchronise across multiple apps that can be set by multiple apps currently I have to add a special case to handle updating the state in the app that is broadcasting the message. This is a particular problem if disparate parts of an app publish and subscribe to these broadcast messages. Somehow the publish component would have to inform the subscribe component that the state has updated.
For example:
My current use case is slightly contrived and might not necessarily be the best way to solve the problem but it illustrates the problem with broadcast messages well.
I have a test harness app that allows new apps to be opened either in the root or in any nested iframe. This allows us to create deeply nested app hierarchies for testing messaging across boundaries. To open an app we broadcast a message on a public channel and the currently selected app then opens it (there are probably better ways of doing this as I said). Currently I need to add a special case:
Roaders
changed the title
Add additional parameters to addCOntextLIstener to allow broadcast to be received by app that makes the broadcast
Add additional parameters to getOrCreateChannel to allow broadcast to be received by app that makes the broadcast
Oct 29, 2024
Hi @Roaders. I think this (receipt of your own broadcasts) would be best handled via #1250 so that the different parts of the apps are using different copies of the API. I realise we've bumped that to the 2.3 scope for now - but I think if we are going to go that way we'd prefer to avoid adding additional arguments to the API calls. There has long been a desire to limit changes to the Desktop Agent API and I suspect the proposed change would be opposed by other participants.
Perhaps you could solve this in your own apps (that have this issue) by wrapping the broadcast and addContextListener functions so that contexts passed to broadcast are also passed to the handler added via addContextListener directly?
If neither route offers a solution you're happy with we can raise this at a Standards Working Group meeting for discussion - it would also end up in the 2.3 scope.
Thanks for the reply @kriswest - I thought that I had already replied here but obviously not...
Using sub agents might resolve some of the issues but it may well raise others. I guess that these issues are probably more to do with the sub agent proposal than this proposal so I have added them on the other issue that you linked.
Enhancement Request
Use Case:
If I have some state that I want to synchronise across multiple apps that can be set by multiple apps currently I have to add a special case to handle updating the state in the app that is broadcasting the message. This is a particular problem if disparate parts of an app publish and subscribe to these broadcast messages. Somehow the publish component would have to inform the subscribe component that the state has updated.
For example:
My current use case is slightly contrived and might not necessarily be the best way to solve the problem but it illustrates the problem with broadcast messages well.
I have a test harness app that allows new apps to be opened either in the root or in any nested iframe. This allows us to create deeply nested app hierarchies for testing messaging across boundaries. To open an app we broadcast a message on a public channel and the currently selected app then opens it (there are probably better ways of doing this as I said). Currently I need to add a special case:
Once again I'd like to state that if separate parts of the app do the subscribe and publish this would be much harder.
If we could optionally set the channel (and all context listeners) to broadcast back to the broadcast app we could simplify the code:
This could work with both public and private channels but I am not too sure about how you would configure the user channels.
I imagine the signature would change to:
The text was updated successfully, but these errors were encountered: