3 ms·

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

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.

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.