Mediator vs. Controller about ui HOT 7 CLOSED

After some rethinking... Are you already doing exactly this?

I would say your Mediator already is the Component but the @actions method is what triggers the single Mediator.

Maybe it would even be sufficient to rename the Mediator to Component?
And then inside of the Component you would have s.th. like

@mediator.publish('eventName', {some: data});

from ui.

Hey there, I am on holidays until Sunday - i will answer next week 😉

from ui.

Yes I know, it is more a reminder for our call ;)

from ui.

Hey @DerMambo, I am back in town re-united with my Laptop after a great holiday trip to Budapest 😉

Ok let me explain how space:ui works in Chaplin terms:

1. Application: This is your Space.Application that is responsible to map, configure and initialize everything that exists in your whole app. Without it, nothing would be instantiated or mapped into the dependency injection system.
2. Router / Layout: You can use any package you want, it only has to use the standard Meteor Blaze templates for rendering. Currently I am using iron:router for that purpose, but space:ui has no dependency on it.
3. Dispatcher / Controller: There is no concept of "screen" or "one controller per screen" in space:ui since it follows the philosophy of React.js and Flow. That means that there are dumb, composable views (in our case these are plain Meteor templates) and for some (higher-level) regions there are mediators that know how to provide data to their managed views.
4. Models / Views: There are no models and views in the classic sense. The only place where data is manipulated and prepared for the rest of the app are stores. The views are just simple meteor templates that get their data from some mediator (but don't know that – they just access the data over some variable like state)

from ui.

To clarify your confusion about @actions:
There is exactly one Dispatcher for your whole application which works like a simple event bus. So you could get a reference to that anywhere by declaring dispatcher: 'Space.ui.Dispatcher' as a dependency. Then you can broadcast an action by calling @dispatcher.dispatch with a plain object. There is no filtering system or anything, it just gets broadcasted to any listener in your app – They can decide if they are interested in the action by looking on the payload object. The reason for this is simple: There are not many listeners, most commonly there are only a few stores that react to actions. All other parts of you application (e.g. mediators / views) are updated "magically" via the Meteor reactive Tracker. So your mediators / views dont need to listen to these actions (and they shouldn't have to).

The @actions pattern is just a simplification of the whole process, so you dont have to always get a reference to the dispatcher and do the whole ceremony. The actions are just pre-configured functions that internally do that for you – you can just provide them the stuff you want to broadcast 😉

from ui.

Thx by the way! :)

from ui.

You are welcome 😉

from ui.