How to write a React code component that wraps Plasmic content?

I have this pretty hacky code component that wraps our accordion components and generates some ld+json for SEO purposes. It has been working fine until now. When I run our website locally or look at the live site, node.props.faqAccordions (highlighted in pic#1) is a React element object with props (and therefore props.children), but in the Plasmic Studio it is an array of React elements, causing the accordion to throw an error (pic #2.

If I check in the API explorer, it works correctly (pic#3).

Our content editors can’t edit the accordions due to this issue. For now I’ll try not running this function inside plasmic Studio, but I’d rather avoid such workarounds so the environments wouldn’t have too many differences

Hi! When snooping at a ReactNode, it is more robust to assume that it can be anything that a ReactNode can be (an array of things, a single element, etc). Things like React.Children.toArray() can help you smooth over the difference as well

I’ll try it out, thanks.

The thing I was mainly wondering about was that why is it different in the Studio compared to API explorer or when it’s in our codebase :thinking_face:

We render things a bit differently in the studio artboards to do the instrumentations we need for working with these components. We’re do strive to make the difference small though, to avoid inconsistencies like the one you ran into!

That’s how I am handling this kind of issue: https://plasmiccommunity.slack.com/archives/C013DHGMJTA/p1660298168436719

Thanks for the input! I changed my typings to be React.ReactNode instead of React.ReactElement and then use React.isValidaElement(node) to check that it has props - ReactNode is after all quite a vague type. Then I’m doing

        const faqAccordions = Array.isArray(node.props.faqAccordions)
          ? node.props.faqAccordions
          : node.props.faqAccordions.props.children;

Which is still a bit iffy since there’s some any’s in the inferred types but TBH since I’m mapping through the children it would be quite verbose to handle each case and narrowing down ReactNode types is not that simple :sweat_smile: React.Children.toArray didn’t really help in this case since it’s not the same property that’s sometimes an array and sometimes not.

Anyways, I was kinda expecting this piece of code to not be the most robust, but at least the current issue is solved :smile: