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
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
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!
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 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