Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFC] Error Handling and Recovery #4

Open
tom95 opened this issue Sep 30, 2022 · 1 comment
Open

[RFC] Error Handling and Recovery #4

tom95 opened this issue Sep 30, 2022 · 1 comment

Comments

@tom95
Copy link
Collaborator

tom95 commented Sep 30, 2022

Mostly just collecting thoughts on error recovery and handling.

Errors during render methods
Most fundamentally: if an error occurs during a render method, correct recovery is currently difficult as we mutate the internal NodeTree as we go. Catching and aborting an error may thus yield missed or double updates. I believe ReactJS does not have that problem because their system around fibers is specifically designed to be incremental and resumable, only describing the pending changes and carrying them out at a later stage. A cheap solution for us could be to shallow copy the tree and update pointers only once the user code ran successfully.

Restoring state of hooks
ReactJS's (React-Refresh) approach here appears to be to create ad-hoc "keys" for each hook of a changed component. They do so via a BabelJS plugin that generates a signature of each hook invocation, e.g. const [a, setA] = useState(0) would become something like [a, setA], useState, 0. This system allows them to recognize re-orders, deletions, and additions. I assume modifying the signature of a hook may simply drop the state, even if not always required (didn't check that deeply).
For us, an implementation could also be quite simple and actually even more advanced than React's. In particular, React only has good support for built-in hooks and rudimentary support for custom hooks. One idea could be to Sandbox-simulate a component whose class was changed (i.e., make each externally visible state mutation a no-op) and have CMFCurrentReact provide custom implementations of each hook that fetch the source code statement from which they were invoked. Running this for both the old and the new code should yield "hook signatures" in the same way that ReactJS uses them.

@cmfcmf
Copy link
Owner

cmfcmf commented Oct 2, 2022

Most fundamentally: if an error occurs during a render method, correct recovery is currently difficult as we mutate the internal NodeTree as we go

Yea, ideally the tree would me immutable.

Restoring state of hooks

Interesting :) I always thought that React hot reloading would just drop all hook state of a component if something changes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants