Will there be an equivalent module for dojo/topic?

[sn3ek]

I'm currently working with the current dojo 1.11 release. I tried dojo 2. But I was missing the dojo/topic module so it was not possible to build my app directly upon dojo2. What are the plans for adopting the topic module to dojo 2?

[kitsonk]

We contemplated events, topics, pub/sub, etc. for Dojo 2 though we have yet found a use case in the examples we have built so far. Largely we have been trying to only build code when we have a clear use case and purpose.

So far all the use cases we have encountered have been more pure "event" based, where the listener has an intimate knowledge of the instance that is emitting the event, where as topics are more of a loose coupling where the listener and the emitter have a very loose relationship.

It might really help understand better what sort of use cases you have where this loose coupling between listener and emitters works for you?

[dylans]

I think it's probably worth understanding how the constructs in dojo/app, and in particular dojo/actions, somewhat replace the needs of dojo/topic.

That said, keep in mind that dojo/topic itself is less than 10 lines of real code, creating an API on top of dojo/Evented ( https://github.com/dojo/dojo/blob/master/topic.js ). So it is not a difficult thing for us to add. As @kitsonk noted, we're trying to only add things once they're needed, as it's far easier to add APIs than remove them.

The main question we had (and why we haven't added it yet) is, does dojo/topic make sense and is it needed given the other event-driven paradigms we have already created in Dojo 2?

@kitsonk the most obvious use cases I can think of at the moment are (from the perspective of a Dojo 1.x user who may not know much about Dojo 2):

• adding Dojo 1.x widgets into Dojo 2 (a lot of Dojo 1.x widgets leverage topics for notifying changes. I'm not sure if we have a need to read those events in our co-existence strategy, or if our co-existence strategy just includes loading the necessary Dojo 1.x modules)
• user interfaces where the presence of UI widgets was configured by the end user (e.g. portals), or included depending on the device.

It's probably worth expanding on the replacements for these approaches which relied on dojo/topic at some point.

[kitsonk]

That said, keep in mind that dojo/topic itself is less than 10 lines of real code, creating an API on top of dojo/Evented

Yes, though that was a migration from various other forms of dojo/topic before dojo/Evented existed. It is an objective of Dojo 2 though to try to not have multiple patterns to solve problems and that was one of the challenges in that Dojo 1 introduced dojo/Evented around the time of .on for an event based model where the emitter and listener were more intimate relationship between the emitter and sender. Dojo 1 had pub/sub, topics, events, etc... So I can understand the familiarity and the desire to make migration easier, we need to tread carefully or we will end up with too much baggage we carry along.

• adding Dojo 1.x widgets into Dojo 2 (a lot of Dojo 1.x widgets leverage topics for notifying changes. I'm not sure if we have a need to read those events in our co-existence strategy, or if our co-existence strategy just includes loading the necessary Dojo 1.x modules)

Because of the major architectural changes, if people were leveraging Dojo 1 widgets, they would also leverage other Dojo 1 modules. Therefore dojo/topic from Dojo 1 would automatically get loaded and used.

As hinted at above, Dojo 2 applications expect that widgets will execute actions, actions will perform business logic. This is a command pattern versus the observer pattern that largely applied to how Dijit interacted.

• user interfaces where the presence of UI widgets was configured by the end user (e.g. portals), or included depending on the device.

In Dojo 2 this use case would be addressed by changing the dojo/app application descriptor, either declaratively or functionally.

We are working on an architectural document that better explains the patterns we expect to be used with Dojo 2 applications (as well as provide a plan for how to re-use Dijits within a Dojo 2 application to make transition easier). I would still like to more information on specific use cases though.

[sn3ek]

Thank you for clarification. In our application we use the topics modules to notify other modules e.g., the view controllers when a change has made. A migration guide or documentation would indeed be helpful to understand the braking changes made in Dojo 2.

[kitsonk]

At the moment we don't have any plans for the RC to have a global event bus, as we see other patterns being preferred at the moment. We may refine and revisit this in the future, but for now going to close this.