Eventbus Event Order

Question

Morning

I use the SimpleEvent bus to send data from my centralized data editor to Widgets. This works very well, I get one set of new data from the server, the RPC call success method puts it in Eventbus, each widget looks if the data is for it, if so, then it displays it, if not, it does nothing. There is only one data set for each request, and widgets are independent of other data already submitted.

Now I have a Tree widget. In addition, the child nodes of the tree generate these datasets, and these child nodes register with Eventbus to animate the data for their child nodes. Data must be received in a hurry (for obv performance reasons), so I will get several data sets that are placed in Eventbus at the same time (in a for loop). I control only the order in which they are placed (first the root, then the data for the first child ......). How does Eventbus now continue events?

• Does it wait until the completion of the first event, so the first child from the tree has already completed creation and registered with Eventbus to animate the data in order to create its children.
• It processes them simultaneously, so the widget is not even registered in Eventbus.
• Does he mix order?!?!

Modern solutions:

• The best solution I can think of is only to add new events on Eventbus when the previous one is finished. However, I found a method that does this, or if this is standard Eventbus behavior.
• Fire handle the processed processing event when the event was processed by widgets. Yucks ... this leads to a lot of additional code and causes big problems when data is placed on an Eventbus that does not belong to any widget ....
• Register a static variable that is set to true when the request has been processed, and Eventbus waits for this for a long time until it sends the next request to Eventbus (quiet, similar to two, but worse coding style and the same problems)
• All events are processed by the root tree element, which sends them up to the corresponding child element.

Which solution would you prefer and why?

Regards, Stefan

PS: my favorite answer would be that 1. is the standard behavior of Eventbus ^^ PPS: The solution should also work when implementing Web Workers.

Answer 1

EventBus#fireEvent is synchronous. This is by design. You can pass the event to the bus, have handlers, perhaps change it, and when execution returns to your method, you can check the event; this is used for PlaceChangeRequestEvent and its setMessage , for example.

FYI, if a handler throws an exception, it will not prevent other handlers from executing. fireEvent then completes the exceptions (plural, multiple handlers may throw) in a UmbrellaException .

Answer 2

Although EventBus is a great way to de-link parts of your application, this does not mean that it should be "excessive."
I also think that you should be careful not to bypass the asynchronous behavior of your client code by introducing synchronous / blocking behavior.

Javascript is single threaded, so I don't think you can have two events at the same time. They will be executed one by one. If you fire an EventBus event (i.e. SimpleEventBus ), it will just be an iterator through the list of connected handlers and execute them. If the handler is not connected, nothing happens.

I personally would prefer a fourth. especially if you plan to use CellTree for a while in the future. The Tree widget / CellTree widget processes the event and builds its structure, passing through the object.