[SerializerHtml] Remove renderToStaticMarkup from client code

[dimaanj]

Summary

Fixes #1123
Fixes #1047

Related issue on slate ianstormtaylor/slate#5012
See react APIs update for more details

• Removes renderToStaticMarkup from client code
• Since serialize will render client react apis, unwanted warnings wont ashore the console

[vercel]

@dimaanj is attempting to deploy a commit to the Udecode Team on Vercel.

A member of the Team first needs to authorize it.

[changeset-bot]

🦋 Changeset detected

Latest commit: e634e69

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 2 packages

Name	Type
@udecode/plate-serializer-html	Patch
@udecode/plate	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[12joan]

How does this change affect the ability for serializeHtml to work in non-browser environments?

[dimaanj]

How does this change affect the ability for serializeHtml to work in non-browser environments?

Do we really expose serialize-html to server environments? If so, we have make additional check for that and use renderToStaticMarkup.

serializeHtml invokes renderToStaticMarkup which is server api where we need to skip useLayoutEffect usage. Since we do it on the client, we always have window presented and can't make this check properly. https://gist.github.com/gaearon/e7d97cdf38a2907924ea12e4ebdf3c85

Now, since we use client react api to render, useLayoutEffect could be used inside components

[dimaanj]

I see, that jest env might need server context. I will check test failures

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
plate	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Apr 26, 2024 11:25am

[dimaanj]

How does this change affect the ability for serializeHtml to work in non-browser environments?

We don't have access to document object on the server. One difference I also noticed that react state changes applied on mount when using new approach

[12joan]

How does this change affect the ability for serializeHtml to work in non-browser environments?

We don't have access to document object on the server. One difference I also noticed that react state changes applied on mount when using new approach

Breaking support for non-browser environments is likely going to be a problem for many users. Do you think it would be possible to create separate client and server versions of the serialize HTML package?

@zbeyens attempted something like that for the Plate core package as part of an attempt to work around a Next.js bug. https://github.com/udecode/plate/pull/3125/files

[dimaanj]

Breaking support for non-browser environments is likely going to be a problem for many users. Do you think it would be possible to create separate client and server versions of the serialize HTML package?

@zbeyens attempted something like that for the Plate core package as part of an attempt to work around a Next.js bug. https://github.com/udecode/plate/pull/3125/files

It's actually hydrated client side code in the issue related to nextjs. We can't use state, hooks, react context and browser apis inside server components in nextjs. But in client components which hydrated in the browser it works like a normal react SPA app. See more here

So, both issues about incorrect usage of react.renderToStaticMarkup on client side (since window check for Layout effect gives the wrong outcome)

Even, if anyone will call serializeHtml on server side, we can make this package agnostic just by checking for a window. We won't get a warn by calling react.renderToStaticMarkup there, since in real server components we haven't window object