Hacker News new | past | comments | ask | show | jobs | submit login

I've always been a fan of eventful programming. If something interesting happens, broadcast an event. If you care about a particular thing happening, listen for the corresponding event. It completely decouples all your components so long as the event API is consistent.

React is composable. Cool. Why is it considered a best-practice to have ancestors pass callbacks to their descendants to modify state? I'd much rather see a component broadcast an event and have an ancestor listen for that event if it cares. That I have to pass callbacks through completely irrelevant intermediary components is just gross - the DOM gives me bubbling for free.

This is exactly the problem we've been running into building a medium sized interactive app in React. The management of data flow and state changes through the component hierarchy with callbacks can get quite complex, and you end up writing lots of callback boilerplate. So we've ended up rolling an event system that sits alongside the React components, and a lot of our app's interactivity is managed through the event system.

We're still learning, and are still not sure if we'll be using React for our production version of what's now a prototype. But I'm starting to feel more and more that we should use the strong points of React (the virtual DOM; so, send big CSS or DOM changes to the virtual DOM via state changes), and discard the other stuff (synthetic events, wiring components together via callbacks). It's tricky figuring out the best way to use it.

I'm starting to think that I would rather just have React as an "immediate mode rendering engine" -- a thin view library. In its entirety it feels too constraining.

This is exactly how react was intended to be used, and our larger apps use the flux system architecture which closely resembles what you've described. There's an example in the react repo. Om takes a different (but equally viable) approach.

Some links for folks that don't know what flux is:



Are caches (memcached..) an obstacle in the flux architecture?

Looking forward to hearing more about this.

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.

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.

I called it a best practice because:

a) It's in their official tutorial: http://facebook.github.io/react/docs/tutorial.html#callbacks... , and

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.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact