Introduce context provider in view component

[ksuess]

Fix #6394

---

📚 Documentation preview 📚: https://volto--6395.org.readthedocs.build/

[netlify]

✅ Deploy Preview for plone-components canceled.

Name	Link
🔨 Latest commit	24907c5
🔍 Latest deploy log	https://app.netlify.com/sites/plone-components/deploys/670923962521e60008ace36e

[sneridagh]

@ksuess Thanks for the PR. However, I have some doubts that I'd like to discuss this further in the Volto Team Meeting. Let me mention some of my concerns here:

• I might be wrong, but we are not using React.Context anywhere in Volto (yet).
• Whenever we needed something like React.Context, we used Redux (eg. recently, with the addition of the form reducer to keep track of the form changes. See Added global form state. #5721)
• We introduced (as experimental) jotai in Volto some time ago. For the use case that you are trying to achieve, maybe it's better to use something like that.

[ksuess]

I'm fine with using a different technique. And I am fine with talking about this during the next meeting.

Just a note why I don't use component state or global Redux state:

The view renders an array of blocks.
Each block checks successively for a match of a glossary term.
One block finds a term and updates the context.
The preceding blocks should NOT be re-rendered.
But a re-rendering is done if working with a state, be it component state or global state.
So I use context, update it in a block if a term matches. Every subsequent block knows about the updated context and does not check for a match of this term already found in a preceding block.

[sneridagh]

I'm fine with using a different technique. And I am fine with talking about this during the next meeting.

Just a note why I don't use component state or global Redux state:

The view renders an array of blocks. Each block checks successively for a match of a glossary term. One block finds a term and updates the context.

How do the blocks update the context? How do the blocks check for a match?

The preceding blocks should NOT be re-rendered.

Every time you do a useContext you are subscribing the component to changes to the context (like useSelect does, since it does use useContext too under the hood) Thus, the blocks will be re-rendered if you change the context value.

But a re-rendering is done if working with a state, be it component state or global state. So I use context, update it in a block if a term matches. Every subsequent block knows about the updated context and does not check for a match of this term already found in a preceding block.

Are you sure that they do not re-render?

[ksuess]

I'm fine with using a different technique. And I am fine with talking about this during the next meeting.
Just a note why I don't use component state or global Redux state:
The view renders an array of blocks. Each block checks successively for a match of a glossary term. One block finds a term and updates the context.

How do the blocks update the context? How do the blocks check for a match?

The preceding blocks should NOT be re-rendered.

Every time you do a useContext you are subscribing the component to changes to the context (like useSelect does, since it does use useContext too under the hood) Thus, the blocks will be re-rendered if you change the context value.

But a re-rendering is done if working with a state, be it component state or global state. So I use context, update it in a block if a term matches. Every subsequent block knows about the updated context and does not check for a match of this term already found in a preceding block.

Are you sure that they do not re-render?

I understand that the official documentation seams to say that all components under the provider that call 'useContext' gets re-rendered on context changes. https://react.dev/reference/react/useContext#caveats But this is not the case. They subscribe to the context, yes, but are touched only if they really change.
I did a small example, to show that React's diffing algorithm considers the previous blocks (in fact the previous slate text leafs) that are already handled, are unchanged Virtual DOM nodes.
https://codesandbox.io/p/sandbox/only-first-occurence-view-context-provider-h5p4fv

My solution with the context provider in 'View.jsx' plus the PR mentioned in the issue (rohberg/volto-slate-glossary#8) is fullfilling the request 'tooltips only on first occurrence on a page (over all blocks). It does it in a minimal invasive manner.

I am sorry that there seams to be no solution without a change in Volto and that I take up your time.

[ichim-david]

@ksuess as @sneridagh said let's discuss this at the Volto team meeting. Personally, I want to have the chance to test your add-on with these changes. Besides this, I am curious to see what would happen if for instance Jotai is used or even Redux.
Once I have these experiments and the full picture, I can better communicate my opinion. Right now, I am too uninformed to give a proper opinion on this change and its entitles.
What I have noticed is indeed our lack of usage of React context providers up to this point in Volto and what would this entail as opposed to using our current approaches.

This means that up to this point, we were able to develop without the need for Context Providers and this might still be the case going forward but it's good to have a use case where a potential React feature is needed and for us to see if we truly need it or not.

[ichim-david]

@ksuess I just installed collective.glossary and your branch from volto-slate-glossary

As soon as I try to edit the frontpage I get this error and what's strange is that the error counter continues to increase as I remain on the error page. In the screenshot you see 1 or 104 but every second it was increasing so after a few seconds it said 1 of 120.

Has this ever happened to you and if so what did you do to solve it?

[ksuess]

New concept for volto-slate-glossary: Instead of generating the tooltip enhanced markup in each Slate leaf,
we generate all tooltip enhanced leaf texts on route change, store them with jotai atom and use the appropriate ones in the leafs.
rohberg/volto-slate-glossary#10

The advantage of this is, that we do not write, but only read, in slate text leaves. This means we don't have to worry about re-rendering the leaves when the status changes.

BTW Global state management with Jotai is a pleasure!

[ksuess]

Closing in favor of a solution without the need of a change request in Volto core.
rohberg/volto-slate-glossary#10

[sneridagh]

BTW Global state management with Jotai is a pleasure!

I know! :) Glad you liked it!