4 ms·

>it sometimes seems like a minor change to the UI can require a major change to the source, cascading through multiple components. >in React I'm finding result

by zxcvcxz 10y ago

>it sometimes seems like a minor change to the UI can require a major change to the source, cascading through multiple components. >in React I'm finding result in needing to change where state is kept (or what things are state and what things are props), requiring cascading changes to many components. It sounds like you don't have a good understanding of state vs props. You should use state as little as possible and try to do as much as possible through props, passing them down from the parent components as necessary. When I create a react app I use the flux architecture, define a state on the top parent component and then add most of the other components as children to this parent component, passing down state as props, and adding listeners to update the components when the state of the parent changes. As far as moving elements around I mostly do that through CSS and wasn't aware react had much to do with positioning elements >taking a UI widget/component that previously was only one one page and realizing it had to be re-used on another(s) Import it into the component that renders the other page and use different props. If you define a lot of stuff in the state of the component then the component isn't as portable. >moving a UI widget from one part of the page to another; This just sounds like CSS and possibly markup to me. >taking a UI widget that previously just displayed something and realizing it needs to have an 'edit' capability too Not sure what you mean by this. Sounds like you could use more practice. https://github.com/uberVU/react-guide/blob/master/props-vs-state.md https://github.com/uberVU/react-guide/blob/master/props-vs-s...

jrochkind1 10y ago
> It sounds like you don't have a good understanding of state vs props. I think I've got a decent understanding, but I'm sure it could be better, and am heartened to think as it gets better these problems will go away. > You should use state as little as possible and try to do as much as possible through props, passing them down from the parent components as necessary. But yes, I've arrived at as little state and as many props as possible. The challenge for me here is that this ends up resulting in components that look to me (based on previous OO experience) like they have TERRIBLE API's, requiring way too many props. My instinct from OO is that a _smaller_ exposed API makes things more portable, but you suggest that "If you define a lot of stuff in the state of the component then the component isn't as portable." Nonetheless, I have moved toward more-props less-state, but.... ALSO this has meant for me that when I need to move or re-use a component from one part of the hieararchy to another, I often end up needing to completely rework the props of a BUNCH of other components, so the right prop can be passed down to my now-moved component -- that's what I mean by 'requiring cascading changes'.
- glenjamin 10y ago
  I think it sounds like your data model is a bit too coupled to your component tree. Try and figure out what the minimal information you need to store is, and keep that higher up. You can then derive a richer model by applying functions during render(). There's a balance to be found here, if you design your data model without considering the needs of the UI it can be a pain to work with. The goal is to create a data layer and associated functions which make it easy to extract the appropriate information for rendering a user interface. Often pain points in React can be alleviated by modelling your data more independently of your component tree.
- TheCoelacanth 10y ago
  > ALSO this has meant for me that when I need to move or re-use a component from one part of the hieararchy to another, I often end up needing to completely rework the props of a BUNCH of other components, so the right prop can be passed down to my now-moved component -- that's what I mean by 'requiring cascading changes'. This sounds like the problem that is solved by redux et al. Instead of passing props into a component just so that it can pass those props down to its children, the child components can just connect to redux and get the data. That way you are accessing the data at the point in the component hierarchy where it makes sense for the component to know about that data, instead of in whatever component happens to be the common ancestor of all of the places that need the data.
  - jrochkind1 10y ago
    Thanks for the feedback! I had somehow gotten the idea that the common advice was to not use redux/flux until you really need it, and even then only use connect to it in 'top level' components, and pass things down from 'top level' component to children view props. Rather than have every component get things from the reactor itself, even deeply nested children. Have I gotten the wrong idea? Is the advice I thought was common not actually common?

by zxcvcxz 10y ago

jrochkind1 10y ago

> It sounds like you don't have a good understanding of state vs props. I think I've got a decent understanding, but I'm sure it could be better, and am heartened to think as it gets better these problems will go away. > You should use state as little as possible and try to do as much as possible through props, passing them down from the parent components as necessary. But yes, I've arrived at as little state and as many props as possible. The challenge for me here is that this ends up resulting in components that look to me (based on previous OO experience) like they have TERRIBLE API's, requiring way too many props. My instinct from OO is that a _smaller_ exposed API makes things more portable, but you suggest that "If you define a lot of stuff in the state of the component then the component isn't as portable." Nonetheless, I have moved toward more-props less-state, but.... ALSO this has meant for me that when I need to move or re-use a component from one part of the hieararchy to another, I often end up needing to completely rework the props of a BUNCH of other components, so the right prop can be passed down to my now-moved component -- that's what I mean by 'requiring cascading changes'.

glenjamin 10y ago
I think it sounds like your data model is a bit too coupled to your component tree. Try and figure out what the minimal information you need to store is, and keep that higher up. You can then derive a richer model by applying functions during render(). There's a balance to be found here, if you design your data model without considering the needs of the UI it can be a pain to work with. The goal is to create a data layer and associated functions which make it easy to extract the appropriate information for rendering a user interface. Often pain points in React can be alleviated by modelling your data more independently of your component tree.
TheCoelacanth 10y ago
> ALSO this has meant for me that when I need to move or re-use a component from one part of the hieararchy to another, I often end up needing to completely rework the props of a BUNCH of other components, so the right prop can be passed down to my now-moved component -- that's what I mean by 'requiring cascading changes'. This sounds like the problem that is solved by redux et al. Instead of passing props into a component just so that it can pass those props down to its children, the child components can just connect to redux and get the data. That way you are accessing the data at the point in the component hierarchy where it makes sense for the component to know about that data, instead of in whatever component happens to be the common ancestor of all of the places that need the data.
- jrochkind1 10y ago
  Thanks for the feedback! I had somehow gotten the idea that the common advice was to not use redux/flux until you really need it, and even then only use connect to it in 'top level' components, and pass things down from 'top level' component to children view props. Rather than have every component get things from the reactor itself, even deeply nested children. Have I gotten the wrong idea? Is the advice I thought was common not actually common?