Devise way for widgets to subscribe to "global" channels that are created by the application controller

[aismail]

Need

In ubervu.com Single Page App we have a custom ApplicationController that creates default channels available throughout the lifecycle of the application. It's becoming really cumbersome to propagate these global channels (a few of them, really) to widget nested deeply within.

We need a quick and easy way for widgets to subscribe to these channels.

Deliverables

• an API for creating / retrieving a global channel:

class GlobalChannels

    create: (alias, type, params) ->
        ###
             Creates a global channel of the given type with the given params under the
             given alias. Global channels will have the "eternal" flag on - a.k.a. they will
             never be garbage collected even though there are no widgets subscribed to 
             them.

             The channel_alias -> channel_id mapping should be stored in the Mozaic
             global object. The result of the function is the channel id of the newly created
             channel because we might need to use it right away.
        ###
        return

    get: (alias) ->
        ###
            Retrieve a global channel id for a given alias, or return None if no channel with
            that alias was found.

            We should discourage widgets from using this API in order to increase their
            reusability. Therefore, this will be called only by the DataSource.
        ####

• make the creation of global channels an official feature of Mozaic by default
• enable a syntax like:

Utils.inject('widget',
    params:
        channels:
            '/social_profiles': 'GLOBAL/social_profiles_for_posting' # social_profiles_for_posting is the alias of the global channel

Then datasource will check the id of the channels it receives and transforms them for all operations.

• create a new API for widgets to subscribe to channels at runtime, and deprecate the old way of doing things. This new API should check for GLOBAL subscriptions and throw an error (it should not be the decision of the widget to be subscribed to global stuff, but the decision of the widget who injects it).

Notes

This is a long-standing request but it must be handled with care: we must not break Mozaic's best feature, forcing widgets to be reusable through the programming model. Therefore, we need to check that widgets don't subscribe themselves to global channels.

Also, I've considered including the feature discussed with @skidding some time ago to subscribe to channels created by ancestors of a widget. However, I think this would require widgets to make assumptions about the context in which they are injected from, limiting reusability.

[aismail]

CC @uberVU/mozaic-core-commiters

[aismail]

I've changed my mind and will move APIs for global channel management in channels_utils.coffee. No need to create yet a new file just for this.

[ovidiuch]

I agree that a widget shouldn't have knowledge of its ancestors, this breaks encapsulations. Parents know of children, children don't know of parents. One single global namespace for eternal channels would be better

I would make a different approach (haven't checked the code to see if it's possible). Passing global/ channels also implies extra lines of code in parent widgets. It'd integrate this in the widget starter somehow or even in the widget itself. A widget has a list of subscribed_channels. It goes through each of them and looks for the corresponding channel in its params.channels, if not found, looks in the global.channels, if not even there, throw error for channel mismatch.

[aismail]

@skidding - you mean you can create an eternal channel from anywhere and access it from anywhere? If yes, I think you can do that with the current implementation - only that by default some eternal channels are created from our custom ApplicationController.

I don't like "defaulting" to the global channels because the only decent chance to match channels is by name. And it forces us to write widgets who know about the global state, instead of deriving meaningful internal names for their own channels.

Appart from this, please check the PR and lmk what you think!

[topliceanu]

hub pull-request!