Hacker News Reader

Comment by smrq | Hacker News Reader

Can you explain what you mean a bit more? My experience with React is that composing components is so trivial (particularly compared to e.g. Angular directives) that I've tended to end up with very small view files (~10 lines of DOM max, plus whatever functionality is directly tied to that). It's seemed like one of React's greatest strengths to me, so I'm curious as to where your complaint stems from.

(I don't use React in my day job... yet. But I'm considering pushing for it, so getting a better understanding of its shortcomings is really important to me.)

View on HN

I think it might be an objection to what the style guide refers to as "logic components": components that use React's `setState` to handle interactions and decide what props to forward to a "presentation component".

Personally, I feel that React is a handy tool for both of these use cases, but the fact that we're finding these two distinct types of components suggests to me that React's "component" abstraction might be doing too much.

Maybe if we break React into the pieces that are helpful for "logic" and the pieces that are helpful for "presentation" we'll end up with two abstractions that are each better suited to their task.

React's ideology is still very young, so I'm hopeful that the community will start to head in this direction, and I'm super excited to see how this plays out :)

Don't quote me on this, but I believe that's exactly the rationale behind the 'stateless functional components' introduced in 0.14.

http://facebook.github.io/react/blog/2015/10/07/react-v0.14....

Yeah, I really dig those :D The concept of a "presentation component" has the exact same semantics as a pure function, so I'm excited that we're actually gonna get that abstraction.

The part that concerns me, though, is the logic component. Hierarchical state/event management seems like a hard problem, and React does it okay, but a lot of things end up coupled together: why does a component that manages a state hierarchy and event flow need to be coupled to the idea of rendering a virtual DOM tree? Can't I just declare that my TodoApp state is a composition of my TodoList state and TodoForm state without also declaring how I'll eventually render them?

I wonder if anyone's come up with a really great abstraction for this yet that checks all the boxes. I like the philosophy behind how Redux manages state, but React provides clearer encapsulation of state and doesn't make parent components think about the events that their children are handling.

Redux is even crazy younger than React, though, so there's still plenty of room to grow there, too!

Reply on news.ycombinator.com