DominikGuzei
commented
9 years ago Hey there! I guess it would be better to integrate both solutions into 4.0, because I don't have the resources to maintain and update several versions, especially when I only use the newest for my production systems.
The space:messaging package is actually very similar to the flux dispatcher (which is also a central message bus). But it is more lightweight and integrates with the Meteor EJSON and check packages to give your messages a clear structure (checked at construction of messages).
I introduced it because I use it on the server-side for several weeks now and it works like magic to make my code more solid. By defining strongly-checked shapes for your events and commands you can't make mistakes with params and propagate wrong data which is sometimes very hard to debug. This is especially useful if you refactor parts of your app. Changes to your message API will immediately throw errors and tell you where you forgot to update the code.
The side effect is, that you don't have to use check directly on the server side, because your commands are automatically transformed to EJSON on the client, sent over a method to the server and checked on re-construction before handling it. So you don't have to sprinkle your checks into various methods and keep all of them up-to-date but it is baked into the message itself.
On the client-side you don't have to use extremly strong checks, String or Match.Integer are often enough to define a rough structure. But on the server-side I often use simple ValueObjects that encapsulate concepts like Quantity, Country or Language, where a simple check for String or Match.Integer would be ridiculous and you can quickly shoot yourself in the foot.
So I am not sure where space:ui should move to, I really like the space:messaging concepts that force you to define some maintainable structure for your most important system: Messaging! But if you really want the flux dispatching and basic actions back I could also re-add the necessary code so that one could use either concept.
ghost
Can you still apply updates to 3.x that would improve the current feature set of it. Like
I think version 3.x fits my needs feature wise quiet good. But there are still some issues. Currently I know about those regarding the reactive state that I have reported separately.
Why I don't want to move to 4.x
Right now I don't want to replace the Flux architecture with the central message bus. Maybe I haven't understood the full benefits of your new space-messaging package. But I prefer using Meteor methods and check on the server side directly. For the client side I like the restrictions and the simple mental model that the Flux architecture creates and even though I don't have a big app wit Flux yet, I think the Dispatcher will make it easier to prevent mistakes regarding the event flow.