It always amazes me how simple ideas can transfer from one domain to another.
A while ago I was looking at Azure Durable Functions. In this domain you want to write a function that can call out to another service, but for scalability reasons we’d like to avoid waiting for the result. Instead we’d like to stop the current execution and then reinstate the context when the value is available. Of course the difficulty is that this sounds like special compiler logic (like the type of transform used to implement generators in many languages). Instead, in the case of Azure Durable Functions, the designers demand that the functions are deterministic, and the trick is to store the previous results in an event log. We can then get to the same execution point by replaying the function – instead of making real outgoing calls, the system returns the previously logged return value at each point where the code tries to call out of the context, knowing that this will lead us down the same path that we executed the first time. This lets us wind forward to the same place and then execute the next step.
React has always had two ways of defining a component. You can use a class and override the various lifecycle methods (like componentDidMount) or you can write more functional (Pure) components that just return the mark up that they want to render. These functional components can be a lot easier to read, and it can be easier to share logic as it is easy for functions to call other functions. Adding state into such functional components is harder though, and the React team have introduced a concept called Hooks to do this. This again requires the idea of a function where outgoing calls are made in a deterministic order, and this lets the system use this order to return different values.
There’s a good post that explains Hooks here, but the quickest introduction is a talk at React Conf with an informative excerpt here. In the example that they show in the talks, the functional approach makes the code much easier to understand than the class based approach – the latter can lead to related logic being spread across the class’s methods whereas the functional approach puts the code together.
While we are on the subject of React, there’s a post here talking about Flutter as an alternative to React Native.