Hacker News Reader

Comment by fiatjaf | Hacker News Reader

React solves all the problems in the world with their nestable but still autonomous components approach. It dispenses controllers -- and automatically give control to the component which deserves it --, it dispenses templates, and automatically gives the power to make the entire app in modular small pieces of HTML, it dispenses models, because models are already embedded in the components in which data is rendered.

React is the Holy Grail of JS frameworks.

View on HN

When I investigated React in detail, I found that there is a lot to like about it, but it's certainly no "holy grail." Specific downsides: you have to go back to manually writing event handlers (instead of getting automatic two-way data binding) and the virtual DOM is a leaky abstraction.

Here's my article where I analyze this in much more detail: http://blog.reverberate.org/2014/02/react-demystified.html

Also React does not "solve all the problems in the world" -- it says nothing about routing, validation, testability, and many of the other problems that Angular has solutions for.

Until tomorrow when someone else on HN tells me "______ is the Holy Grail of JS frameworks."

I'm curious what happens when you want to share models across components. In angular.js you would use services to do this, but what's the analog in React?

If you're passing it to child components you pass it through attributes. If you're passing up to parents, however, you have to create a function on the parent that will get called to accept the child's new data. This can get really messy if you have deeply nested components and need to get data from one branch to another branch.

React encourages you to use a parent component that controls the state and passes it down to it's children via props.

Passing data to separate components without a shared parent is outside of what React is trying to accomplish but I've handled it before by passing a Backbone model to the separate components as props.

I have been successful by instantiating separate services to perform REST operations and a global event emitter to establish communication between all the services and all the components that relate to these services in any way.

I cringe when I hear the words "global" and "event" together in the same sentence. Projects I've worked on in the past that relied heavily on global events often became a maintainability nightmare.

Why? Please share your experiences. I don't understand what's the utility of event emitters if not for serving as glue to all the separate components of an app. Am I wrong?

You're not wrong. It's definitely one way to solve it. I just find it harder to jump into a project with heavy reliance on global events and be able to quickly understand what's going on. It gets even harder if you have events firing other events.

> I just find it harder to jump into a project with heavy reliance on global events

Harder than what?

Harder than the way that it is done in Angular, via services.

Reply on news.ycombinator.com