These are chat archives for jdubray/sam

24th
Jan 2018
Jean-Jacques Dubray
@jdubray
Jan 24 2018 16:54
Really interesting to see all these FSM articles poping up in the React community... Visual-based Automata Programming with React.
devin ivy
@devinivy
Jan 24 2018 16:56
sometimes UI components have a small enough number of states that you can get away with an FSM, but it doesn't work for applications.
i have also found it useful at times to name which "mode" a specific component is in
Jean-Jacques Dubray
@jdubray
Jan 24 2018 16:58
sure, a behavior is a sequence of states after all.
Another interesting post discussion between Michel Weststrate and Dan Abramov
Conceptually, React behaves as if it had a single update queue per component. This is why the discussion makes sense at all: we discuss whether to apply updates to this.state immediately or not because we have no doubts the updates will be applied in that exact order.
One way we’ve been explaining “async rendering” is that React could assign different priorities to setState() calls depending on where they’re coming from: an event handler, a network response, an animation, etc. For example, if you are typing a message, setState() calls in the TextBox component need to be flushed immediately.
SAM would shed a lot of light on that aspect of React, if only they care to look...
But what do I know?
Jean-Jacques Dubray
@jdubray
Jan 24 2018 17:25

It looks like the React team is implementing a version of SAM afterall

Wouldn’t it be nice if when you do a simple setState() that renders a different view, we could “start” rendering the updated view “in background”? Imagine that without any writing any coordination code yourself, you could choose to show a spinner if the update took more than a certain threshold (e.g. a second), and otherwise let React perform a seamless transition when the async dependencies of the whole new subtree are satisfied. Moreover, while we’re “waiting”, the “old screen” stays interactive (e.g. so you can choose a different item to transition to), and React enforces that if it takes too long, you have to show a spinner.
It turns out that, with current React model and some adjustments to lifecycles, we actually can implement this! @acdlite has been working on this feature for the past few weeks, and will post an RFC for it soon.

I doubt that the "threshold" would work since you could still be rendering within one second of the threshold, but it's ok. I think they'll start building some adaptive features in React, is this path on average takes more than N ms, it will trigger a specific behavior