Hacker News Reader

Comment by jonahx | Hacker News Reader

peter,

thanks for the examples. it actually seems analogous to angular. the "createClass" bit is like a directive definition, and the "renderComponent" bit is like your new declarative markup. i do agree that angular can be complex and opaque, especially once you start to delve into the internals (compiling, priority, transclusion, etc), and avoiding that complexity is a good selling point. if i were you, i would hit that hard :)

that said, those examples don't seem all that different to me than the angular way. maybe the simplicity would start to shine in more complex use cases. again, a good toy problem that requires angular gymnastics to solve, side by side with a straightforward react version would be compelling.

my final and important question is this: you mentioned react only solves the view problem. does that mean if i want to migrate from angular to react that i would have move from angular to "react + backbone" or "react + something else"?

View on HN

For Instagram we have higher level components that do data fetching via a JSON GET request. When the request comes back we store the response in state, and then we pass that state down to child components. We also pass callbacks down to those child components, so that when they want to perform a write to the server, the higher level component can do that.

We move the actual server request and response logic out of the component, of course, so it's just a one-liner within that component.

Instagram got really far with that, but there are parts of Instagram (converted from an earlier Backbone version) that have the child components directly update Backbone models which then handle the server requests. The on change Backbone events then trigger setState() calls on our UI.

At Facebook we have an in-house dataflow architecture that updates our components.

So it really depends on how you want to do it. But we don't provide a "React.Data" or "React.Router" or anything like that. This is by design, since we can't possibly account for everyone's specific use case.

I like the idea of being able to use my own raw domain objects as the model, which in angular you are supposed to wrap up as a service as i understand it -- a bit of boilerplate i don't love. I'll definitely keep my eye on this project, it sounds like it has a nice architecture.

My last piece of advice is docs, docs, docs. Making a framework easy to learn by example is the key to adoption imo. That was one of the chief complaints you heard about ember, though I think they've started to fix that. It's boring work and hard to make good docs, but it's so so important.

> I like the idea of being able to use my own raw domain objects as the model, which in angular you are supposed to wrap up as a service as i understand it -- a bit of boilerplate i don't love.

This is only a cultural thing. Angular is, at its root, a dependency injection framework. The upside of doing thinngs the angular way is that you can wire things together differently down the line (and you can actually get a lot of code reuse if you write 1-2 function services) with the downside being the boilerplate wrappers.

Thanks for taking the time to follow this conversation through :) We've spent a lot of time getting the docs to where they are today, but there's always more to do. We have more planned but think we got a pretty good point for our initial public release.

When we've showed the site internally at FB & Instagram we got a lot of the same feedback you're giving now, that we need more examples. We have some more in the repo and more we'd like to write. Coming soon!

Reply on news.ycombinator.com