inter module communication about aura HOT 18 CLOSED

But now, Mediator (or it's wrapper Facade) publish and subscribe methods has a different meaning. Publish is starting up widget and call it's subsriber function. The code like core.publish('message/recieved' ... ) will fail, since now it is expected 'widgets/message/recieved.js' module is expected. I think publish/subscribe loosing it's previous meaning.. now it's more like start / onStarted methods, as for me.

This is a very interesting point. I want to ensure that we're not breaking the Publish/Subscribe capabilities by having widget loading overriding what may be expected. Perhaps it would make more sense for us to just pass/publish from core the widget name and a config that lets Aura know you're attempting to load a widget instead.

Technically speaking I wonder if it would make sense for core to not just be calling publish directly but instead call start, which is an action explicitly telling the app to load up a widget. @dustinboston as you implemented core publishing the modules I'd be really interested in your thoughts on this. I think the OP has a valid point.

from aura.

I think publish/subscribe loosing it's previous meaning.. now it's more like start / onStarted methods, as for me.

@alexanderbeletsky @addyosmani Yes totally agreed.

I think the pub/sub behavior really does need to be cleared up. Basically any type of "autoloading" would need to go away. If the widget hasn't been started it doesn't get the message.

from aura.

@addyosmani @dustinboston thanks for response, guys

What I'm thinking now. We should probably have 2 separate interfaces:

1. for starting/stopping modules (widgets)
2. for between module communications

First one could belong to core (mediator), second could belong to sandbox (facade).

I'm also thinking that for communication something like amplify.js could be used.

What do you think?

from aura.

What I'm thinking now. We should probably have 2 separate interfaces:

for starting/stopping modules (widgets)
for between module communications

First one could belong to core (mediator), second could belong to sandbox (facade).

I agree. We should perhaps draft a list of changes we're proposing to make to Aura
(e.g lines) to bring this into place.

I'm also thinking that for communication something like amplify.js could be used.

We currently have our own lightweight implementation of Pub/Sub in place that works. I know well of Amplify and I've used it in the past, but I'd prefer for us to stick to the barebones of what we need for the moment, unless there's something Amplify offers which we can't cover ourselves.

We want to start to move away from external dependencies (Aura relies on both Underscore and jQuery at the moment) and adding another library in wouldn't be great if we could avoid it.

Other than that, all for the clearer interfaces.

from aura.

@addyosmani Agreed on all accounts.
@alexanderbeletsky Thanks for your contributions, great stuff!

from aura.

So we've effectively agreed upon having two different interfaces for communication. I'd like to get this issue fixed this week.

For starting/stopping modules, will that be proxing back to use the Pub/Sub bus or will we be starting and stopping modules directly? I feel like there's a low cost to using Pub/Sub for this as well, but wasn't sure if the OP had issue with it. Should start and stop literally just kick things off without any communication through pub/sub at all?

I maintain my agreement that our cross-use of Pub/Sub for more than one interface is causing confusion. The question I'm asking is whether we do a better job of hiding those interfaces behind the scenes whilst continuing to use Pub/Sub or make them use two completely different communication methods (direct, Pub/Sub).

from aura.

@addyosmani I'm happy to hear that decision has been taken!

I'll refer to my previous comment:

What I'm thinking now. We should probably have 2 separate interfaces:

1. for starting/stopping modules (widgets)
2. for between module communications

First one could belong to core (mediator), second could belong to sandbox (facade).

So, I vote for (direct, Pub/Sub) proposal.

Ps. If we agree on design I would be happy to help implementing it.
Pss. I think something that @rumpl already did here makes sense.

from aura.

@alexanderbeletsky I've updated based on some of the recommendations in the fork and make some fixes to a few things that were breaking controls. Could you take a look at d94be13 and let me know if you think there are any other changes that would be useful to improve comms?

from aura.

Hi,

Awesome, I am glad I could help.
There is one thing that remains though.

If you stop the todos module and add a new event in the calendar the todos module will receive the event. The stop method (of the mediator) has to cleanup all the subscriptions of the module.

However, my implementation isn't good. A module can cheat and pretend it's someone else if we let him tell us who he is. The best solution would involve the facade to know who is calling it and keep track of which module subscribed to what events.

from aura.

@addyosmani I've looked at the code and everything seems to be fine. Great job.

from aura.

As the mediator is providing the implementation for the subscribe/publish and normally any tracking of these actions should be done at that level, perhaps we should look to track what modules are subscribed to what events from there and expose through the facade/sandbox. Clarification: when you say a module can cheat, do you mean a widget or really just a module? I ask as normally when it comes to identification we would be talking about widgets. Just checking.

from aura.

@alexanderbeletsky thanks! It would be really great if we could nail down the final tweaks needed to address the rest of @rumpl's feedback above. Any help or suggestions you might have to solve those issues would be tremendously useful.

from aura.

Hello,

When I say module, I mean it in the Nicolas Zakas way, the independent unit of functionality, blah blah blah. That being said I am not sure I understand the difference between a module and a widget.

I have a working example of callbck cleanup when a module is stoped on my branch.

Now for the cheating part.

Here is what I think should be done:
Every module gets it's own sandbox that knows who is it serving. That way a module/widget can't pretend he is someone else.
If every module gets it's own sandbox we get the "Don't access DOM elements outside of your box" for free by appending the root element to every selector a module does. Example, if the todo widget tries to access sandbox.dom.find('.someClass') he will in fact get $('#todosapp .someClass').

I have a half arsed POC implemetation of what I am saying. I will try to clean it up and put it on GitHub early next week.

from aura.

@rumpl

So to clarify: module can be considered an independent unit of functionality. In Aura as we're using AMD as our module format of choice, we opt to not call anything else module and those are as such, our modules.

A widget is a piece of a page that is independent. It is a collection of modules (which can mean MVC, UI blocks, templates, anything) which can either be run on their own or which can communicate with other parts of the page, albeit only through the observer pattern via the facade and mediator.

I would be really interested to see the POC you're working on. I wouldn't as such call what you're doing cheating ; )

If you would be up for doing a PR of the callback cleanup work we could possibly iterate on it further.

from aura.

@alexanderbeletsky There have been changes to clean up our module communication since this issue was opened. Would you mind having a review to see if any of your concerns have been resolved?

from aura.

@addyosmani I got very brief look on that some time ago and actually happy what I saw. But haven't yet tried the things, the only way it's possible to see real issues :)

I'll try to find the time for review these days.

from aura.

Thanks! :)

from aura.

@addyosmani sorry, it took a while.. I checked out the code and examples, everything looks fine now.

I'll close that issue.

from aura.