You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 21, 2022. It is now read-only.
After reading the Angular 2 google doc on rendering architecture
I got thinking about how this could be achieved with React. Wouldn't it be awesome if a web worker could be used for your application logic so the main thread can stay responsive to user interaction? Imagine if you could send a virtual dom diff from a worker to the main thread.
The current problem with this architecture is that a virtual element is not always serializable. This is because we want to be able to attach event handlers to respond to events triggered by a user. These event handlers are not always called with serializable arguments for example DOM elements. What if instead you could describe your event handler in terms of a function and that functions data dependencies? Perhaps something similar to GraphQL. Then just let the main thread send what is required when such an event is triggered. A virtual element could then be serialized and sent over a web worker message channel.
You could take this a step further and take advantage of the diffing process. Only send the diffs of the elements that have changed including the changes in data dependency. When a user triggers an event the Main thread figures out the event and the required data and sends it back to the UI thread.
You could potentially get multiple UI threads sending diffs to the main thread as long as each UI thread owned a given branch of the virtual tree.
Does this sound like something worth exploring? Am I missing something that would stop this from working?
The text was updated successfully, but these errors were encountered:
I noticed that for applications without too many DOM updates, the cost of postMessage which is used for communication between worker and the UI thread may actually make this solution slower than react-dom. I also noticed that like in ReactNative, batching should be used and selecting the batch size correctly would help.
After reading the Angular 2 google doc on rendering architecture
I got thinking about how this could be achieved with React. Wouldn't it be awesome if a web worker could be used for your application logic so the main thread can stay responsive to user interaction? Imagine if you could send a virtual dom diff from a worker to the main thread.
The current problem with this architecture is that a virtual element is not always serializable. This is because we want to be able to attach event handlers to respond to events triggered by a user. These event handlers are not always called with serializable arguments for example DOM elements. What if instead you could describe your event handler in terms of a function and that functions data dependencies? Perhaps something similar to GraphQL. Then just let the main thread send what is required when such an event is triggered. A virtual element could then be serialized and sent over a web worker message channel.
You could take this a step further and take advantage of the diffing process. Only send the diffs of the elements that have changed including the changes in data dependency. When a user triggers an event the Main thread figures out the event and the required data and sends it back to the UI thread.
You could potentially get multiple UI threads sending diffs to the main thread as long as each UI thread owned a given branch of the virtual tree.
Does this sound like something worth exploring? Am I missing something that would stop this from working?
The text was updated successfully, but these errors were encountered: