3 ms·

A number of these guidelines reinforce my biggest complaint with React: it is architecturally difficult to avoid monolithic view files. In a traditional web ap

A number of these guidelines reinforce my biggest complaint with React: it is architecturally difficult to avoid monolithic view files. In a traditional web app, we have 4 layers: client views, client app, server app, database. React, described as a strict view layer, in reality is being used as much more. At this point, it is not just consuming the client app, but is also taking nibbles at the server app as well. To each their own of course, but i would ask people to hesitate about these decisions. The architectural issues with monolithic views is well known, and just because we have a shiny new tool does not mean we should throw that understanding by the wayside. Source: i work full-time on a React and Backbone app

smrq 11y ago
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.)
- matchu 11y ago
  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 :)
  - troybetz 11y ago
    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.html#stateless-functional-components http://facebook.github.io/react/blog/2015/10/07/react-v0.14....
    - matchu 11y ago
      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!
Offler 11y ago
It sounds to me like you are doing React development incorrectly. You should aim to break down your mockups into small components, preferably stateless components (introduced in React 0.14) and only have the higher level components act as wrappers that pass down data into the small stateless component leafs (which should be the majority of your UI).
tracker1 11y ago
What do you mean by monolithic view files? It's pretty easy to separate at logic boundaries into smaller components... As for universal rendering, using the same view engine on both the server and client makes sense. Not only that, but being able to use the same routing engine for client and server rendering, especially on a public facing application is a pretty nice thing as well.

smrq 11y ago

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.)

matchu 11y ago
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 :)
- troybetz 11y ago
  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.html#stateless-functional-components http://facebook.github.io/react/blog/2015/10/07/react-v0.14....
  - matchu 11y ago
    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!

Offler 11y ago

It sounds to me like you are doing React development incorrectly. You should aim to break down your mockups into small components, preferably stateless components (introduced in React 0.14) and only have the higher level components act as wrappers that pass down data into the small stateless component leafs (which should be the majority of your UI).

tracker1 11y ago

What do you mean by monolithic view files? It's pretty easy to separate at logic boundaries into smaller components... As for universal rendering, using the same view engine on both the server and client makes sense. Not only that, but being able to use the same routing engine for client and server rendering, especially on a public facing application is a pretty nice thing as well.