Developer Experience: Time Travel #188
Description
One thing that got me really hooked on the Redux/React ecosystem was the idea of time-travel - via Dan's talk: https://www.youtube.com/watch?v=xsSnOQynTHs
It was a really impressive concept to me - treating state as just an axis independent of time. However, in practice, I've never actually been able to use it with much success - I've introduced it in multiple apps, and either there were side-effectful things happening in the redux store, or state was tracked in other places, or the app was too big so it was slow to remove/add actions.
However - I believe that, in a fully-functional world, we're better equipped to handle these challenges, and perhaps introduce a more robust 'time travel' concept into Revery (or reason-reactify).
A couple of key points:
- Reason/OCaml guide you towards a functional model - you have to go out of your way for mutability, refs, etc.
- Core State Management - Revery manages state in two places - one is in the component model (which has some really neat ideas happening in [WIP] BUG: 'Long-lived' setState function fails to persist updates reason-reactify#44), and the other is in the app's 'store' (which is like a redux store). And only those two places (maybe the global store can go away eventually, too!).
OCaml / js_of_ocaml also has a really powerful Marshal module - https://caml.inria.fr/pub/docs/manual-ocaml/libref/Marshal.html - which can serialize arbitrary data structures to disk / across network / etc. It's much more powerful than something like JSON serialization in JavaScript, because it can actually serializes closures too with the Closures flag.
I believe that this combination of characteristics could give us the ability to implement 'time travel' in a more robust and usable way, out-of-the-box for revery or more generally reason-reactify.
It'd be neat to have an integrated dev tool available for this that is available in debug mode.