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 Jul 28, 2023. It is now read-only.
When we asked plugin developers what we should include in our experiments, they answered React Context support.
Context provides a way to pass data through the component tree without having to pass props down manually at every level, this means easy data communication between different components.
The problem
In this experiment, we are taking the Island's architecture as the main approach. We use custom elements so we hydrate the block automatically when joins the tree (you can copy-paste a block, and will be hydrated), and also allow us cool things like defining the way we want to hydrate it.
The problem with this approach is, that, usually when you use React, you only have one application where you just add Providers components in the tree at the highest level possible, so that way any child component can access the Context data.
In our case, we have multiple React Apps, so we have to find a process to share that context between different apps while reusing the React Context API as much as possible. We don't want the developer to learn anything new if they already know how to work with React Context.
On the block registration, we should be able to import the Context, create a wrapper with that Context so our Child Component (the block itself) could access it, and then set a Consumer that can sync the value with the parent Provider, so the Context is updated when needed in each parent.
We thought about the idea of creating a subscriber to a Context, but, in this case, if we have more than one context, is really difficult to select the Context to subscribe to. Instead, we want to try the default behavior of the Context of subscribing to the closest parent Provider, by using a custom event, similar to what we do for the UsesContext and ProvidesContext in default blocks.
We created a video to try to explain everything, recommended playback speed is 1.5x, as I talked toooo slow 😓
video2535897202.mp4
The text was updated successfully, but these errors were encountered:
luisherranz
changed the title
Support for the Context API between different blocks.
Support for the Context API between different blocks
Jun 30, 2022
luisherranz
changed the title
Support for the Context API between different blocks
Support React's Context API between different blocks
Jun 30, 2022
What
When we asked plugin developers what we should include in our experiments, they answered React Context support.
Context provides a way to pass data through the component tree without having to pass props down manually at every level, this means easy data communication between different components.
The problem
In this experiment, we are taking the Island's architecture as the main approach. We use custom elements so we hydrate the block automatically when joins the tree (you can copy-paste a block, and will be hydrated), and also allow us cool things like defining the way we want to hydrate it.
The problem with this approach is, that, usually when you use React, you only have one application where you just add Providers components in the tree at the highest level possible, so that way any child component can access the Context data.
In our case, we have multiple React Apps, so we have to find a process to share that context between different apps while reusing the React Context API as much as possible. We don't want the developer to learn anything new if they already know how to work with React Context.
One possible exploration
https://excalidraw.com/#json=x8cpUygy5LrBMMzhDmS8E,s5RQCGHTZXZStvCFPDPfwA
On the block registration, we should be able to import the Context, create a wrapper with that Context so our Child Component (the block itself) could access it, and then set a Consumer that can sync the value with the parent Provider, so the Context is updated when needed in each parent.
We thought about the idea of creating a subscriber to a Context, but, in this case, if we have more than one context, is really difficult to select the Context to subscribe to. Instead, we want to try the default behavior of the Context of subscribing to the closest parent Provider, by using a custom event, similar to what we do for the UsesContext and ProvidesContext in default blocks.
We created a video to try to explain everything, recommended playback speed is 1.5x, as I talked toooo slow 😓
video2535897202.mp4
The text was updated successfully, but these errors were encountered: