SlateContext not found in Component on initial render about react-page HOT 9 CLOSED

you cannot use the useSlate hook inside the Component of the plugin, since this also renders in readonly mode where we don't want to load the whole slate library.

Is there a reason why you want to this hook in the component?

from react-page.

Thanks for the quick answer.

We want to implement a collapsible block element, which can host other slate nodes and collapse/expand them via header element onclick.

To achieve this we use the slate editor in the onclick handler to get the slate node from the dom node and set the collapsed state as data attribute of the block element. This in turn gets passed via props, so we can render the correct state.

in edit mode this would allow us to persist this state and allow the user to control if one block element renders collapsed or expanded. In readonly mode it does not get persisted and therefor is only a local state update.

Maybe this is not the best solution for these requirements. Is there a best practice to tackle this kind of problem?

from react-page.

its probably better to implement a collapsilbe block element as a normal reactPage cellplugin. That way it can contain anything.

But also with a slate plugin, that sounds a bit adventurous.

You can use a slate plugin with a schema: https://github.com/react-page/react-page/blob/master/examples/plugins/customSlatePlugin.tsx

where you can define a boolean "startCollapsed" or so. You'll get that property in the Component of your custom slate plugin.

we could hower also inject slate (or useSlate) into the component which would be (or return) null in readonly.

There are already such injections, so should be possible to add it

from react-page.

It is probably not the usual use case for a rich text editor, but slate is really versatile and I was hoping, that there should be a way to do it :)

I also thought about creating a reactPage cellplugin first, but came to the conclusion that the user experience is better when having one slate editor and write all the text at once. So I wanted to achieve it that way.

Using a schema is maybe the better way and clearer for the user to define, which blocks are collapsed and which are not. Also, persisting the collapsed state is maybe not even a hard requirement, but I wanted to see, how far we can push it.

So, I want to say thanks for the insights and how it is supposed to work. For now, I would not suggest to inject useSlate in such a way as it will probably be confusing, when the editor is available and when not and not allow to write good code.

As I understand, if we want to persist state on a component, we should use a schema to have clear separation between edit and readonly mode.

from react-page.

As I understand, if we want to persist state on a component, we should use a schema to have clear separation between edit and readonly mode.

the schema approch works for both cellplugins and slate plugin. In slate it shows a popup and the cell plugin shows it in that bottom toolbar.

In both cases you can also have type: "custom" controls, where its your responsibility to render the right ui elements. But also in that case it renders in the popup or the bottom toolbar.

So, I want to say thanks for the insights and how it is supposed to work. For now, I would not suggest to inject useSlate in such a way as it will probably be confusing, when the editor is available and when not and not allow to write good code.

you're welcome. If you want to do write operations, you will always have some api that is not working in readonly mode ;-) We could also inject an onChangePluginData into the slate-plugin's Component that could update the slate-node's data. That callback would also be not working of course in readonly mode

from react-page.

Hi @macrozone ,

the schema approch works for both cellplugins and slate plugin. In slate it shows a popup and the cell plugin shows it in that bottom toolbar.

Yeah, I guess it is more clear to the user, that in this case something can be configured. So I am fine to give this a try.

If you want to do write operations, you will always have some api that is not working in readonly mode ;-) We could also inject an onChangePluginData into the slate-plugin's Component that could update the slate-node's data. That callback would also be not working of course in readonly mode

Yeah, I like the idea of such an interface. Definitely clerarer than messing around with the low level slate APIs. For now we should wait, if there are real use cases for such a feature.

Currently we struggle with another problem regarding our neat collapsible component :)

GIven, we have created this data structure with Slate

                           {
                              "type": "Collapsible/Wrapper",
                              "data": {},
                              "children": [
                                {
                                  "type": "PARAGRAPH/PARAGRAPH",
                                  "children": [
                                    {
                                      "text": "Überschrift",
                                      "EMPHASIZE/EM": true
                                    }
                                  ]
                                },
                                {
                                  "type": "PARAGRAPH/PARAGRAPH",
                                  "children": [{ "text": "rv" }]
                                }
                              ]
                            }

A wrapper component as block with 2 paragraphs. Now while rendering, we want to take the first element and render it in the collapsible container with a toggle and the other paragraphs (in this case only the second one), in a container, which can be collapsed.

In edit mode, it works as expected. We get the 2 children as react node and can create the markup. However in readonly mode, it seems, that rendering works differently. We do not get the 2 expected children, but 1 element, which seems to wrap the children. Is this intended functionality? We are not sure, what to expect and how to handle this. Maybe you can shed some light on this, aswell?

from react-page.

@phal0r in order to reduce bundle size, we use a simplified renderer to render slate content

its basically just this https://github.com/rockettomatooo/slate-react-presentation/blob/master/src/index.js

its wrapped in a Fragment, which is totally fine, I advice to not rely directly on the number of childrens, i also don't see why this should be relevant (if the resulting html markup would be different, i would understand the problem)

Having said that, i recommend to use A cellplugin that could contain anyhting in a collapseable section (not only text).

I advice to not do too much inside slate as it is more complicated and can reduce flexibilty

from react-page.

There are patterns in React like slotted components, which define, where children are put according to their layout and therefor granular control of the components are needed. So in general this is not an anti-pattern. It's the same in our case, where the first child needs to be put at a different place in the layout of the component.

Why do we stick to implementing this in slate? Our use case is to provide blocks of texts, that can be collapsed. The collapsible title and the paragraphs within should be numbered like so:

1. Title 1
   1.1 Paragraph 1
   1.2 Paragraph 2
2. Title 2
   2.1 Paragraph 3

and so on.
It's only about text and it would be annoying for the author to add a new component for each new block. From a developer perspective it would be hard to maintain correct numbering, especially with the flexibility of react-page. It would also couple plugins semantically to each other, which breaks the semantic idea of isolated plugins, not to mention, what should happen, if a author rearranges plugins with drag and drop :)

So, I hope now it becomes clearer, why we want to stick to the decision.

I had a look at the react-slate-presentation. Is it necessary to have this fragment at this point? Currently we work around this by accessing the children through the fragment. That is of course more than ugly.

I think there is no reason to disallow harnessing the full power of react components in slate components including such patterns. Maybe there is a technical reason for this deviation.

from react-page.

This issue has been automatically marked as stale because it has not had recent activity 😏. It will be closed if no further activity occurs. Thank you for your contributions! ❤️

from react-page.