Allow sending arbitrary notifications to a Component.

[edelvalle]

Adds the reactor.component.broadcast(channel, **kwargs) to send a notification to any Component subscribed to channel. he message is delivered in Component.notification(channel, **kwargs).

[jbjuin]

Hi @edelvalle
this looks good to me, I just tried it and it works.

I have a question : why did you add the _ on methods or arguments that are part of the "public" API ? They are intended to be used by the developers. My understanding is that in python those should be without the leading _, keeping it for internal functionality that should not be used by developers. For instance: _template_name or _subscriptions.

I also have another use case that do not work with this version: I want to pass a callable to a sub-component so that it can be called and the value is sent to the parent component. I will post an issue for this one. On my version it works flawlessly (reactor 2 + jinja template). I use this for an autocomplete component for instance...

[edelvalle]

I have a question : why did you add the _ on methods or arguments that are part of the "public" API ? They are intended to be used by the developers. My understanding is that in python those should be without the leading _, keeping it for internal functionality that should not be used by developers. For instance: _template_name or _subscriptions.

You are right, it is like kind of private because:

• I don't want it to be exposed on the template context
• I don't want the front-end to be able to call it
• I want to signal in that way that those attributes are reserved for the component configuration.

I also have another use case that do not work with this version: I want to pass a callable to a sub-component so that it can be called and the value is sent to the parent component. I will post an issue for this one. On my version it works flawlessly (reactor 2 + jinja template). I use this for an autocomplete component for instance...

I see, in this case as I serialize the object state to the front-end, and serializing functions could be complicated. I would use this broadcast to talk to the parent component or any other component. The parent component could subscribe to a channel, where the child publishes updates.

• The good: You can send updates of any kind from any component to any component, even on different tabs.
• The bad: If you want to couple two components parent/child using this mechanism, you would have to generate a random ID for the channel of communication and pass it to the child. Why? Because otherwise all the parents in all tabs listen to the signal and get updated. Do I explain myself right?

So, should we merge this?

[jbjuin]

I have a question : why did you add the _ on methods or arguments that are part of the "public" API ? They are intended to be used by the developers. My understanding is that in python those should be without the leading _, keeping it for internal functionality that should not be used by developers. For instance: _template_name or _subscriptions.

You are right, it is like kind of private because:

* I don't want it to be exposed on the template context

* I don't want the front-end to be able to call it

* I want to signal in that way that those attributes are reserved for the component configuration.

I see. Ok makes sense. Let's continue like this.

I also have another use case that do not work with this version: I want to pass a callable to a sub-component so that it can be called and the value is sent to the parent component. I will post an issue for this one. On my version it works flawlessly (reactor 2 + jinja template). I use this for an autocomplete component for instance...

I see, in this case as I serialize the object state to the front-end, and serializing functions could be complicated. I would use this broadcast to talk to the parent component or any other component. The parent component could subscribe to a channel, where the child publishes updates.

* The good: You can send updates of any kind from any component to any component, even on different tabs.

* The bad: If you want to couple two components parent/child using this mechanism, you would have to generate a random ID for the channel of communication and pass it to the child. Why? Because otherwise all the parents in all tabs listen to the signal and get updated. Do I explain myself right?

That's indeed another solution for this problem.

So, should we merge this?

Sure !

[edelvalle]

Ok, merging then. Now I will the the recv_ merge request.