4 ms·

Is there a way to use the React hook stuff without having to put the backend logic _inside_ of your UI generation code? It really feels like if there was some

by rtpg 8y ago

Is there a way to use the React hook stuff without having to put the backend logic _inside_ of your UI generation code? It really feels like if there was some way to put this really dirt-simple counter code into a plain-Jane Javascript object then a lot of this hand-wringing about state management in React goes away (contexts are an interesting little solution to things though)

foota 8y ago
The issue if I understand your comment correctly is that you want to keep the ui state in sync with the logical state, so you can't just keep it in an object somewhere, since that wouldn't keep up with react's rendering? I do think you can have a hook return a javascript object though for the normal reasons of encapsulation and such.
gedy 8y ago
Sounds like you are looking for something like MobX? http://mobx.js.org http://mobx.js.org
- crooked-v 8y ago
  There's also Redux, which is harder to wrap your head around starting out, but has great edge case debugging capabilities (you can "time travel" forward and back with changes) and really efficient-and-seamless cached derived data with selectors.
  - dangoor 8y ago
    You can time travel with MobX as well. https://github.com/zalmoxisus/mobx-remotedev https://github.com/zalmoxisus/mobx-remotedev https://github.com/BrascoJS/delorean https://github.com/BrascoJS/delorean
  - fastball 8y ago
    Rematch[1] makes it really easy to get started with Redux. 1: https://github.com/rematch/rematch https://github.com/rematch/rematch
  - chrisweekly 8y ago
    Mobx supports "time travel" as easily as Redux. It also works with redux devtools, and requires less boilerplate.
ng12 8y ago
This article is almost four years old but I still refer to it all the time: https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0 https://medium.com/@dan_abramov/smart-and-dumb-components-7c... What I tell my students is that you want to think of your app in three layers -- the data layer (Redux/data fetching), the glue layer (@connected components, useEffect hooks), and the presentational layer. The representational layer should be just your rendering logic and the data layer should deal with fetching/storing/updating data. The two should never interface directly, only through your container "glue" components.
WorldMaker 8y ago
I've been thinking about it some. The pattern seems easy enough to entirely split view functions from hook logic. Using the usual counter example: export function counterView (count) { return <span>{ count }</span> } export function Counter () { const [count, setCount] = useState(0) // … useEffect to setInterval count or whatever return counterView(count) } At this point, though the question becomes is this pattern buying you anything? Pure view functions should be easier to test, but React testing library's act() tool looks like it isn't that much more painful to just test the full component. Similarly, pure view functions are potentially easier to reuse with different "component logic", but I'm unsure how often that would be the case. It's maybe a bit clearer as a pattern where the "stateful" and "stateless" stuff may be than mixing the two, and certainly seems like it might help make it easier to follow the "Hook rules" (most of your loops and conditionals should be inside the "pure" function). But it's potentially also just a source for extra noise/boilerplate. Like I said, I'm still thinking about it, and something I expect to explore in an actual codebase at some point.
miklosbertalan 8y ago
I think this TodoMVC might be structured the way you described: https://codesandbox.io/s/github/solkimicreb/react-easy-state/tree/master/examples/todo-mvc?module=%2Fsrc%2FtodosStore.js https://codesandbox.io/s/github/solkimicreb/react-easy-state... It has a separate, clean JS store object. (Note: I am the author of the underlying state management lib.)

by rtpg 8y ago

foota 8y ago

The issue if I understand your comment correctly is that you want to keep the ui state in sync with the logical state, so you can't just keep it in an object somewhere, since that wouldn't keep up with react's rendering? I do think you can have a hook return a javascript object though for the normal reasons of encapsulation and such.

gedy 8y ago

Sounds like you are looking for something like MobX? http://mobx.js.org http://mobx.js.org

crooked-v 8y ago
There's also Redux, which is harder to wrap your head around starting out, but has great edge case debugging capabilities (you can "time travel" forward and back with changes) and really efficient-and-seamless cached derived data with selectors.
- dangoor 8y ago
  You can time travel with MobX as well. https://github.com/zalmoxisus/mobx-remotedev https://github.com/zalmoxisus/mobx-remotedev https://github.com/BrascoJS/delorean https://github.com/BrascoJS/delorean
- fastball 8y ago
  Rematch[1] makes it really easy to get started with Redux. 1: https://github.com/rematch/rematch https://github.com/rematch/rematch
- chrisweekly 8y ago
  Mobx supports "time travel" as easily as Redux. It also works with redux devtools, and requires less boilerplate.

ng12 8y ago

This article is almost four years old but I still refer to it all the time: https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0 https://medium.com/@dan_abramov/smart-and-dumb-components-7c... What I tell my students is that you want to think of your app in three layers -- the data layer (Redux/data fetching), the glue layer (@connected components, useEffect hooks), and the presentational layer. The representational layer should be just your rendering logic and the data layer should deal with fetching/storing/updating data. The two should never interface directly, only through your container "glue" components.

WorldMaker 8y ago

I've been thinking about it some. The pattern seems easy enough to entirely split view functions from hook logic. Using the usual counter example: export function counterView (count) { return <span>{ count }</span> } export function Counter () { const [count, setCount] = useState(0) // … useEffect to setInterval count or whatever return counterView(count) } At this point, though the question becomes is this pattern buying you anything? Pure view functions should be easier to test, but React testing library's act() tool looks like it isn't that much more painful to just test the full component. Similarly, pure view functions are potentially easier to reuse with different "component logic", but I'm unsure how often that would be the case. It's maybe a bit clearer as a pattern where the "stateful" and "stateless" stuff may be than mixing the two, and certainly seems like it might help make it easier to follow the "Hook rules" (most of your loops and conditionals should be inside the "pure" function). But it's potentially also just a source for extra noise/boilerplate. Like I said, I'm still thinking about it, and something I expect to explore in an actual codebase at some point.

miklosbertalan 8y ago

I think this TodoMVC might be structured the way you described: https://codesandbox.io/s/github/solkimicreb/react-easy-state/tree/master/examples/todo-mvc?module=%2Fsrc%2FtodosStore.js https://codesandbox.io/s/github/solkimicreb/react-easy-state... It has a separate, clean JS store object. (Note: I am the author of the underlying state management lib.)