Using React to record JSON videos
35 0 3318
This is a demo of the Atom-React framework that we have been building at Stample.co for the last 6 months, against the real production app that you have seen here.
Code source here: https://github.com/stample/atom-react
Simply managing all your state outside of React, and always re-rendering from the top can leverage things like "state sourcing" and enables features like undo/redo and JSON state video records that can be replayed against a React component.
This is just the beginning.
Imagine how nice it would be to be able to:
- stream that video in real time for browser assistance or synchronization
- UX monitoring (or user spying)
- sending the video to the backend/developers for debugging incorrect React renderings...
- building a time-traveling debugger
This works out of the box, on a production app, not a simple TodoMVC demo :) Actually I was quite surprised that it worked so easily when I coded the 50 lines of code in the framework. It didn't even required adapting our application. Animations are working too, as they are triggered by state transitions.
However, some limitations are due to mutations that are not tracked in the global state of our app. This may happen for:
- Integration with external libraries that manipulates the DOM directly
- Tracking scroll position and things like that
Thanks to the teams behind React, Om and ELM for the inspiration :)
By anonymous 2017-09-20
Who does it
You will find a lot interesting things in the React and ELM communities, and in frontend functional programming communities in general.
Some recent full-stack platforms that are somehow trying to provide a development environment of this kind are:
A Andreessen Horowitz / Y-Combinator startup, 2.3 million funded, from Chris Granger, an influent Clojure programmer who already built LightTables.
Technologies: Rust (backend), TypeScript (frontend) with a home-made implementation of React concepts (what they call "microReact")
Not a company (yet?) but supported by a Patreon campaign, from Paul Chiusano (author of famous book "FP in Scala").
Technologies: Haskell (backend), ELM (frontend).
Note: you can see that the guys behind these tools are experienced functional programmers. Check "how it works" section.
How it works -> functional programming
Programs have state.
Why was Bret Victor's able to make that video?
- his architecture is explicit about state mutations
- he uses functional purity
- he record historical facts as state, rather than current UI state
One tool inspired by this talk is the ELM language.
ELM states that:
So at the root of the debugger is the design of Elm itself. If you do not start with the right design choices at the language level, creating a time-traveling debugger quickly becomes extremely complex. Even languages that partially fulfill the necessary design requirements will have serious challenges.
So what you really have to understand is that it is not the technology that is interesting, but the underlying software architecture. Once you have the architecture, it is not so hard to add such debugging features.
Many in the ReactJS/Flux communities have shown that we can achieve really great things with this kind of architecture. David Nolen of Om's ClojureScript hype is probably the trigger, and Dan Abramov has shown recently that we can achieve very similar things that compare to Bret Victor's debugging.
Myself I've been experimenting with recording user session videos in JSON, which is also a feature that is leveraged by this kind of architecture.
So, you have to understand that what he achieves is not done by clever code tricks or a super language, but really good architectural patterns.
These patterns are not even new, they are used by database creators and some backend developers for a very long time under different names, including command/event sourcing, journaling... If you want an introduction, the Confluent.IO blog is a very pedagogic source.
The problem is not even about reloading code, it is all about what to do with the state after the code has been reloaded.
What you really need to understand is that there's no unique answer to that question: it all depends on what you want to achieve.
For example in Bret Victor's example with Mario, when he modifies some parameter like the gravity, you can see that it can affect both the past (what he has recorded) and the future (the actions he'll do after the code change). This means that the user intent is reinterpreted in a different context, producing a new history of facts (often called command-sourcing).
While this is really interesting for video games like he has shown, this is absolutely useless for many other applications. Let's take an example of an accountability application, where the tax % can increase or decrease every year. Do you really think modifying the current year tax % should have any effect on the balance sheet of 10 years ago? Obviously not, but it may still have effects on the current year.
Also the Mario positions tray when adjusting the jump parameter, the tool can't know by himself that it has to display it for the Mario element. You have to be explicit about it otherwise it could do the same for the clouds or the turtle. And does it make sense to do the same for the accountability app?
What I mean here is that this is a cool demo, that has been well-produced. You can't get a similar dev environment that work so well out of the box. But you can learn the architectural patterns that permit to do it easily, and use tools like ELM / Om / Redux / Flux / ReactJS (and some Haskell / Scala / Erlang may be useful too!), that will help you greatly in implementing them correctly and provide you the most they can for hot reloading.