This is a good summary of what is nonobvious to me, even as a full time JavaScripter. I generally try to stick to the ethos "Bubble events up, invoke down" wrt the object tree.
I've never heard the 'pass callbacks to descendants to modify state' considered as a best practice, but I don't think that's bad either. It's a tool in the tool box. But it's not more of a best practice than other tools.
DOM Event bubbling is pretty great, as it enables e.g. decorator patterns without having to replicate bubbling through your own EventEmitter system.
But once you're passing a multiple callbacks down to all children, it's just tedious. It may be better to just pass a complex object (not a function) to your children.
Tangibly, I think it's very reasonable for a ContentView (comment widget) to compose a Body Section and an Author Info section where both those latter two objects have a full reference to an EventEmitting Content Model. And they can call setters on that Content if they need to change the Content state and other Views would react. DOM Interactions bubble up to ideally as broadly scoped mediating controller as possible.
b) My friends who turned me on to React (as well as the StackOverflow that came up after a quick Googling) confirmed that you aren't supposed to create custom events in React, and should instead follow the callbacks-as-props model.
If I've misunderstood something, I'd love to know the better way.
I thought you meant it was a known best practice in JavaScript in general. I know have kept an eye on React and it's intriguing, but I have yet to hack with it because I mostly work in an ecosystem of libraries that have an alternative, which is pretty much literally an independent implementation of Backbone.View, but without coupling to the rest of Backbone like Model or Events.
I generally deploy these modules together to the web, and I want to keep the file size of my base layer small. I think React looks cool but I haven't gotten to the point where I want to send my users 30k more code when
It does seem promising for new projects. I hope to give it a go soon.
I've never heard the 'pass callbacks to descendants to modify state' considered as a best practice, but I don't think that's bad either. It's a tool in the tool box. But it's not more of a best practice than other tools.
DOM Event bubbling is pretty great, as it enables e.g. decorator patterns without having to replicate bubbling through your own EventEmitter system.
But once you're passing a multiple callbacks down to all children, it's just tedious. It may be better to just pass a complex object (not a function) to your children.
Tangibly, I think it's very reasonable for a ContentView (comment widget) to compose a Body Section and an Author Info section where both those latter two objects have a full reference to an EventEmitting Content Model. And they can call setters on that Content if they need to change the Content state and other Views would react. DOM Interactions bubble up to ideally as broadly scoped mediating controller as possible.
I have currently been planning on refacotring parts of the following codebase, and planning on splitting this Class into a few components that would work like what's described above. https://github.com/Livefyre/streamhub-sdk/blob/master/src/co...
Anyway, I think a combination is what works best. I'm curious what others think.