4 ms·
I dont think you need FRP to do that. In ReactJS, view code is pure, dom event callbacks just return new states[0], and all IO (ajax data access), async pipelin
by dustingetz 12y ago
I dont think you need FRP to do that. In ReactJS, view code is pure, dom event callbacks just return new states[0], and all IO (ajax data access), async pipelines etc stay at the very top of your application at the root of the view hierarchy. Business logic is just functions of data values and/or appstate values. Which is exactly how I imagine the idiomatic haskell solution would look.
[0] dom callbacks actually swap! the nextState value so there are effects down there at the bottom of the view hierarchy, but that's react's fault for not letting you return the next state. e.g.
<input
value={this.state.a.b.c}
onChange={_.partial(mori.assoc_in, this.state, ['a', 'b', 'c'])} />
- seanmcdirmid 12y agoInteresting. ReactJS sounds like an immediate-mode UI that avoids states and reconstructs the UI by re-rendering. This is as opposed to a retained-mode UI that is based on a mutable scene graph.
- mattgreenrocks 12y agoExactly: https://twitter.com/ibdknox/status/413363120862535680 https://twitter.com/ibdknox/status/413363120862535680 It's amazing that we're back to immediate mode!
- seanmcdirmid 12y agoThat makes sense (can't read Chris's comment right now because I'm behind the GFW). Immediate mode is quite workable and can even be efficient with the appropriate amount of memoization. State can even be injected in a way that is very FRP like (re-render over values that changed). Seems like I have more related work to talk about :)