Are server components supported?

[franknoel]

I am trying to set up Craft.js with Next.js v14, but I'm unable to use server components without getting the following error:

Error: Invariant failed: The component type specified for this node (undefined) does not exist in the resolver

Did somebody managed to make it work or its just not supported yet?

[qu8n]

@franknoel Looks like SSR received support recently (see #637).

Just in case, could we confirm that all of your components have been passed into the Editor's resolver?
For example: <Editor resolver={{Card, Button, Text, Container}}> ... </Editor>

[prevwong]

So there's actually 2 parts to the error you're having:

The first part of the problem is you've defined a Linked node in your CraftContainer component:

export const ContainerCraft = ({ children, ...props }: Props) => {
  return (
    <Element is={ContainerCraftWrapper} id="container" {...props}>
      {children} // <-- not allowed
    </Element>
  );
};

// and this was the usage of ContainerCraft in your example code:
<ContainerCraft>
  <Container>hi</Container>
</ContainerCraft>

This detailed reason for this error is because Craft controls the rendering flow here, so it wraps all the children in an internal <NodeElement /> component (so that things like useNode works). But <Element /> over here needs to parse its own child contents to create it's corresponding Linked Node, in which case - it thinks NodeElement is a user component which of course, it isn't.

Keep in mind that <Element /> (in the case of defining a linked node) is to define the default placeholder value for that node; once that node has been created, it will be up to the user to edit it (otherwise, we would have difficulty maintaining a single source of truth). So you shouldn't be passing in an prop value as it's content anyway.

What you should do instead is:

export const ContainerCraft = ({ children, ...props }: Props) => {
  return (
    <Element is={ContainerCraftWrapper} id="container" {...props}>
      <Container>hi</Container> // basically directly move the contents of "children" 
    </Element>
  );
};

A quick side note, Linked Nodes are a bit of a mistake in hindsight, they were made to solve a really specific editing scenario, but I feel like it has caused a lot of confusion and it easily leads to bugs and maintenance issues. I would avoid it if you can (I should probably add a note in the docs)

---

The second part of the problem is SSR and React strict mode, which I have a fix here: #653

[franknoel]

Thank you very much for the detailed explanation @prevwong

I updated my CodeSandbox accordingly and will wait for the release of your latest fix.
I also changed the naming of the component to make it easier to understand.

https://codesandbox.io/p/devbox/jolly-hermann-6pqtxn

Unfortunately, I suspect something is still off. In your last code snippet, Container is rendered in ContainerCraft even though it is an unsupported pattern.

https://nextjs.org/docs/app/building-your-application/rendering/composition-patterns#unsupported-pattern-importing-server-components-into-client-components

The Next team recommends using children to pass a server component to a client component instead. Would wrapping children in a div work in our situation?

[franknoel]

I updated the CodeSandbox to the latest version of Craft.js (v0.2.7).
The error is still showing, is it possible that SSR is supported but not server components?

[prevwong]

There's still some issue in the sandbox:

1. ClientContainerWrapper is missing from the resolver
2. The editor page itself does not have the "use client" annotation at the top, thus the following doesn't run:

const EditorPage = async () => {
  return (
    <Editor>
      <div className="root">
        <div>
          <h4>page</h4>
          <ClientContainer /> 
        </div>
      </div>
    </Editor>
  );
};

I'm not exactly sure why, but I suspect the ClientContainer passed here on this page is different than if you specified the "use client" at the top (perhaps nextjs wraps the component if its being called from a server component or something).
3. Your Container component still uses a dynamic children prop inside a linked node.
Basically, you can't pass a dynamic prop value (ie: children) to a linked Node:

const ContainerWrapper = () => {
  return (
     <Element is={...} id="container">
       {children} // don't do this; the contents of this <Element> is used to set the default content of the linked node, so it won't work as you would typically expect
    </Element>
  )
};

But if you had a component that accepts some React component as a prop, you could pass it as usual (provided that it's not used inside a linked node like the above example):

const ContainerWrapper = () => {
  return (
     <div id="container">
       {props.someServerComponent} // ok
    </div>
  )
};

[franknoel]

Thank you for the review, here's the link to the updated CodeSandbox:
https://codesandbox.io/p/devbox/jolly-hermann-6pqtxn

I can confirm what you're saying in your second point.