Repository navigation
Consider adding broadcast #145
Description
Activity
+1, see this SO question
+1
I posted a response to the SO question. I think @sorvell might be describing a one-way message passing system which only flows to an element's children, whereas the SO thread seems to want PubSub.
Without going as far as full pubsub implementation, a simple broadcast or event bus capability would go a long way. The solution you linked to does the trick perfectly, I should start having a look at those articles (no clues in the API section). Shouldn't that
polymer-signalselement be part of the core, just ascore-ajax?Yep, we're discussing it. Thread to follow is here:
googlearchive/polymer-signals#3On Mon, Jun 16, 2014 at 9:17 AM, Renaud Fontana notifications@github.com
wrote:Without going as far as full pubsub implementation, a simple broadcast or
event bus capability would go a long way. The solution you linked to does
the trick perfectly, I should start having a look at those articles (no
clues in the API section). Shouldn't that polymer-signals element be part
of the core, just as core-ajax ?—
Reply to this email directly or view it on GitHub
#145 (comment).Broadcast seems like a bad idea at this point. There are other patterns:
- child elements bubble an event to register interest in a signal
- core-signals
- child element registers listener on body, signal is bubbled up instead of waterfalled down (flavor of [2], as implemented currently)
Sometimes a custom elements wants to give its descendants some generic information which they may, optionally, respond to.
This is very much like an event, but it's sent downward to children.