5 ms·

Why react specifically? My general experience tells me that mixing presentation and logic ends badly If you’re talking about the `todos` list in the tweeted ex

Why react specifically? My general experience tells me that mixing presentation and logic ends badly If you’re talking about the `todos` list in the tweeted example, I’m afraid you’ve been successfully trolled. In non-toy code, you’d typically hold the underlying state in a separate part of your system rather than the rendering React component, as with any other sanely designed UI. That data would be passed into the React component via `props` so it knew what to render, and the callback function to handle a form submission would also be passed in via `props`, and the React component would have no dependencies on anything else in your system. It’s actually one of the simplest, cleanest and most completely specified interfaces of any modern JS UI library or framework, in my experience. It is true that a React component can also hold its own state and can use that data in addition to the supplied props when rendering. However, that state is normally reserved for UI-related data that isn’t part of the underlying data model, such as keeping track of a selected item or which page is currently active on a paginated table view. Toy examples like to-do lists sometimes use React component state to hold more general data, because that is simpler in a trivial demonstration than writing separate MVC components or the equivalent, but that’s not how you write idiomatic React code in production systems, and it never has been.

flukus 10y ago
Do you know of an example that does things properly? There are a lot of people here defending the code as written.
- Chris_Newton 10y ago
  What sort of thing did you have in mind? If you look at some of the other tools widely used in conjunction with React, the entire Redux ecosystem is about maintaining application state and systematically updating it in response to whatever events might be interesting in your system. There are libraries like Immutable.js, which like React itself is provided by Facebook, to help manage an immutable underlying data store. I imagine any decent tutorial material about using those together would provide some better examples than the contrived to-do list example from the tweet. I’d like to repeat here that React doesn’t require that you use that particular style of architecture, and there are plenty of reasonable alternatives. However, hopefully those examples should suffice to demonstrate that separation of underlying state from UI rendering and responding to interactions makes as much sense with React as in other contexts and is widely employed in practice.
91bananas 10y ago
Your point here is one of my biggest struggles in trying to adopt react. I have looked at many of the toy examples and haven't seen a clean implementation of a non-toy. I've built a couple small things with it and haven't seen a clear path to how I'd implement something in my day job that I currently do in a Backbone app. I don't really feel like I need something like redux, so what am I to do? Continue building components that hold their own data? What is the way in react?
- Chris_Newton 10y ago
  Those are all fair questions. If you want to experiment, my advice would be to start by just using React as a template-rendering system that lets you conveniently build larger and more complex components by composing smaller and simpler ones and that can automatically change whatever is already in your DOM to whatever new DOM content you come up with when rerendering. At this stage, you can take advantage of React’s greatest strengths, but you don't need any bells and whistles like Redux or Immutable or MobX or whatever other state management libraries you’ve come across. One thing I would recommend right from the start is storing your application state somewhere outside your React components, even if it’s just in plain JavaScript objects. When you’re ready to render a DOM tree, pass that data into the top-level React component via props. Have that top-level component in turn pass any relevant part(s) of its input data to any child component(s) that need that data for their own rendering. Likewise, I would recommend defining the functions to handle any interesting events outside your React components. You can then pass any callbacks you might need in via props on your components as well. If you try that sort of design out a few times with non-trivial apps, you’ll soon start to see common patterns where introducing other tools might be helpful, and at that point you’ll have a better understanding of what some of those other libraries do and which combinations of related libraries might be useful for your particular needs.
  - 91bananas 10y ago
    I appreciate this answer, I will give this a go.

flukus 10y ago

Do you know of an example that does things properly? There are a lot of people here defending the code as written.

Chris_Newton 10y ago
What sort of thing did you have in mind? If you look at some of the other tools widely used in conjunction with React, the entire Redux ecosystem is about maintaining application state and systematically updating it in response to whatever events might be interesting in your system. There are libraries like Immutable.js, which like React itself is provided by Facebook, to help manage an immutable underlying data store. I imagine any decent tutorial material about using those together would provide some better examples than the contrived to-do list example from the tweet. I’d like to repeat here that React doesn’t require that you use that particular style of architecture, and there are plenty of reasonable alternatives. However, hopefully those examples should suffice to demonstrate that separation of underlying state from UI rendering and responding to interactions makes as much sense with React as in other contexts and is widely employed in practice.

91bananas 10y ago

Your point here is one of my biggest struggles in trying to adopt react. I have looked at many of the toy examples and haven't seen a clean implementation of a non-toy. I've built a couple small things with it and haven't seen a clear path to how I'd implement something in my day job that I currently do in a Backbone app. I don't really feel like I need something like redux, so what am I to do? Continue building components that hold their own data? What is the way in react?

Chris_Newton 10y ago
Those are all fair questions. If you want to experiment, my advice would be to start by just using React as a template-rendering system that lets you conveniently build larger and more complex components by composing smaller and simpler ones and that can automatically change whatever is already in your DOM to whatever new DOM content you come up with when rerendering. At this stage, you can take advantage of React’s greatest strengths, but you don't need any bells and whistles like Redux or Immutable or MobX or whatever other state management libraries you’ve come across. One thing I would recommend right from the start is storing your application state somewhere outside your React components, even if it’s just in plain JavaScript objects. When you’re ready to render a DOM tree, pass that data into the top-level React component via props. Have that top-level component in turn pass any relevant part(s) of its input data to any child component(s) that need that data for their own rendering. Likewise, I would recommend defining the functions to handle any interesting events outside your React components. You can then pass any callbacks you might need in via props on your components as well. If you try that sort of design out a few times with non-trivial apps, you’ll soon start to see common patterns where introducing other tools might be helpful, and at that point you’ll have a better understanding of what some of those other libraries do and which combinations of related libraries might be useful for your particular needs.
- 91bananas 10y ago
  I appreciate this answer, I will give this a go.