5 ms·

The purest form of function programming cannot have side effects. But to do anything useful you need them. So like many other functional programming langs/libs

The purest form of function programming cannot have side effects. But to do anything useful you need them. So like many other functional programming langs/libs/frameworks react had a controlled means to run side effects. That’s the escape hatch of useEffect. It’s not a bad thing. It’s thematically same as the unsafe block in Rust. It allows you to reach out of the main paradigm, when required.

marcosdumay 4y ago
React was the thing that convinced me that you can't have a non-pure reactive system. React is complex because views aren't pure; slow because it has to rerender things that didn't change, because it doesn't actually know what changed, because views are impure; hard to program because impure views create bugs that even that extra complexity can't fix; and has all those escape hatches to change execution time and memoize things because the execution time actually has semantic value. And that's react, that incredibly well designed thing with incredibly knowledgeable authors, that made a huge effort to think about every problem. Non-pure reactive systems just do not work.
- jeffreygoesto 4y ago
  Quite similar to build systems. Same arguments lead to Bazel...
- vanviegen 4y ago
  We've had great results from our custom built non-pure reactive system (which predates React by a couple of years). The idea is to have an Observable object that can store arbitrary trees of data (each itself an Observable). UI drawing is generally split into a function call for each DOM element that has children. These functions are executed such that they track the use of observables and will be rerun when they change. I've more recently, after having suffered React and friends, started creating an Open Source implementation of the pattern we used. Currently, it's mostly still lacking in documentation and marketing, and that's unlikely to change if I'm honest. But this should give you an impression if you're interested: https://github.com/vanviegen/aberdeen/blob/master/examples/tic-tac-toe/tic-tac-toe.js https://github.com/vanviegen/aberdeen/blob/master/examples/t... Curious to know your thoughts about this being an effective non-pure reactive system.
- illiarian 4y ago
  > because it doesn't actually know what changed, because views are impure Because in React, the smallest unit is the component. In Solid the smallest unit is the whatever reactive value you use, and only that changes. Components are there just to organize your code and do the initial render.
- branko_d 4y ago
  I fully agree that impure views are a path to madness, but you don’t have to abandon React to have pure views. React components can, and I would argue in vast majority of cases should, be pure functions. You just need to displace state management outside of React. This removes the need for class components and hooks and returns React to its roots as a view library. Most complications in React seem to stem from its desire to also be a state library. Case in point: we used MobX with React to build a UI for an entire document management system (essentially a file system with versioning, security and workflows) - I don’t think we have more than a handful of impure React components in the entire codebase.
  - marcosdumay 4y ago
    Interestingly, the optimal place I see to keep state is inside the reactive system. You just have to ensure that every single non-pure action is notated as an event. You can even have a lot of pure state interdependence. What React doesn't even try (because yes, it's a view library). Anyway, one can certainly keep all views pure. It's a bit hard in Javascript where a lot of things are hidden, but it's perfectly doable. It's even the recommended way to use React. But that doesn't save React from being way larger, slower, and harder to use than it could otherwise be.

marcosdumay 4y ago

React was the thing that convinced me that you can't have a non-pure reactive system. React is complex because views aren't pure; slow because it has to rerender things that didn't change, because it doesn't actually know what changed, because views are impure; hard to program because impure views create bugs that even that extra complexity can't fix; and has all those escape hatches to change execution time and memoize things because the execution time actually has semantic value. And that's react, that incredibly well designed thing with incredibly knowledgeable authors, that made a huge effort to think about every problem. Non-pure reactive systems just do not work.

jeffreygoesto 4y ago
Quite similar to build systems. Same arguments lead to Bazel...
vanviegen 4y ago
We've had great results from our custom built non-pure reactive system (which predates React by a couple of years). The idea is to have an Observable object that can store arbitrary trees of data (each itself an Observable). UI drawing is generally split into a function call for each DOM element that has children. These functions are executed such that they track the use of observables and will be rerun when they change. I've more recently, after having suffered React and friends, started creating an Open Source implementation of the pattern we used. Currently, it's mostly still lacking in documentation and marketing, and that's unlikely to change if I'm honest. But this should give you an impression if you're interested: https://github.com/vanviegen/aberdeen/blob/master/examples/tic-tac-toe/tic-tac-toe.js https://github.com/vanviegen/aberdeen/blob/master/examples/t... Curious to know your thoughts about this being an effective non-pure reactive system.
illiarian 4y ago
> because it doesn't actually know what changed, because views are impure Because in React, the smallest unit is the component. In Solid the smallest unit is the whatever reactive value you use, and only that changes. Components are there just to organize your code and do the initial render.
branko_d 4y ago
I fully agree that impure views are a path to madness, but you don’t have to abandon React to have pure views. React components can, and I would argue in vast majority of cases should, be pure functions. You just need to displace state management outside of React. This removes the need for class components and hooks and returns React to its roots as a view library. Most complications in React seem to stem from its desire to also be a state library. Case in point: we used MobX with React to build a UI for an entire document management system (essentially a file system with versioning, security and workflows) - I don’t think we have more than a handful of impure React components in the entire codebase.
- marcosdumay 4y ago
  Interestingly, the optimal place I see to keep state is inside the reactive system. You just have to ensure that every single non-pure action is notated as an event. You can even have a lot of pure state interdependence. What React doesn't even try (because yes, it's a view library). Anyway, one can certainly keep all views pure. It's a bit hard in Javascript where a lot of things are hidden, but it's perfectly doable. It's even the recommended way to use React. But that doesn't save React from being way larger, slower, and harder to use than it could otherwise be.