Closed silveltman closed 5 months ago
I have also run into this issue; when rendering a similar component in the component browser this exception occurs:
Uncaught (in promise) TypeError: Component is not a function
renderToStaticMarkup bookshop.js:40883
renderFrameworkComponent bookshop.js:43125
renderComponent2 bookshop.js:43300
Heading bookshop.js:44226
Heading bookshop.js:44238
fn bookshop.js:41783
callComponentAsTemplateResultOrResponse bookshop.js:40805
renderToString bookshop.js:40782
renderAstroComponent bookshop.js:40982
render bookshop.js:40933
The Component
variable passed to renderToStaticMarkup
is the tag to render as a string ("h1", "h2", ect.), but it calls it as if it is a function.
const reactNode = await Component(props);
Not ideal, but in the meantime this accomplishes the same thing:
{Element === "h1" && <h1>{heading}</h1>}
{Element === "h2" && <h2>{heading}</h2>}
{Element === "h3" && <h3>{heading}</h3>}
I can confirm I am having the same issue. It was not an issue a few months ago, but I'm not sure if my local codebase or Bookshop changed to cause this issue.
Any word on this? Is this an Astro or Bookshop issue? I didn't change my local Astro version and even tried to roll back to the CloudCannon legacy editor.
I have tried changing the version of Astro and other various packages, and there has been no change. Considering that this happened when no changes were made, this has something to do with an update to CC live preview editor.
This is the error as I see it in console:
Error rendering bookshop component page TypeError: Component is not a function
renderElement @ bookshop-live.js:33590
This is the function as it is shown in console:
async renderElement(componentName, scope, dom, logger) {
try {
logger?.log?.(`Rendering ${componentName}`);
await this.engines[0].render(dom, componentName, scope, { ...this.globalData }, logger?.nested?.());
logger?.log?.(`Rendered ${componentName}`);
} catch (e) {
logger?.log?.(`Error rendering ${componentName}`);
console.warn(`Error rendering bookshop component ${componentName}`, e.toString());
console.warn(`This is expected in certain cases, and may not be an issue, especially when deleting or re-ordering components.`);
}
}
Component is the name of the dynamic tag I am using. I followed the pattern used in sendit-astro, which has worked fine for months but only recently started throwing this error.
This is a roadblock for me to use Astro & CC as a CMS, I have a client site running on CC & 11ty, and hoped to start building in Astro with new projects.
This is my NPM dependencies list after updating to latest:
"@astrojs/check": "^0.5.0",
"@astrojs/mdx": "^2.0.0",
"@astrojs/sitemap": "^3.0.3",
"@bookshop/astro-bookshop": "^3.6.5",
"@bookshop/astro-engine": "^3.6.5",
"@bookshop/generate": "^3.6.5",
"astro": "^4.0.0",
"astro-auto-import": "^0.4.0",
"markdown-it": "^14.0.0",
"normalize.css": "^8.0.1",
"punycode": "^2.3.0",
"sass": "^1.66.1",
"typescript": "^5.2.2"
Hi @edmeehan, sorry but we haven't been able to prioritise looking into this issue yet!
But it certainly is suspicious that you've started encountering errors without changing anything on your end. If you could share some more information about your setup or provide a minimal reproduction that'd be really helpful in debugging!
I wouldn't have expected you to hit this issue just following the Sendit template, since that only uses dynamic tags to render other components, which would ultimately be built to actual functions. This should only happen if you have dynamic tags which are string literals, so it'd be good to have a look and make sure that there isn't anything else secretly behind your problem.
I also notice you're on a relatively old version of Bookshop, you might also want to try updating to 3.9.0
just to be safe, since some older versions of Bookshop had some issues with newer versions of Astro
@Tate-CC Thanks for responding to this issue. I can confirm I have the error on version 3.9.0, and upon deeper investigation, I can confirm that dynamic Tags using the pattern from the Sendit theme work. The pattern that seems to have recently broken is the same as the two previous commenters above me.
---
const Tag = 'div';
---
<Tag>I do not render in CC preview</Tag>
This was a pattern that I had set up for some time, but it only recently (2-3 months ago) stopped working.
I have at least isolated the exact pattern that is breaking for me, and when I remove these components in CC it will render as expected. I do have a workaround now, but since this issue appears to have started on a change to this library or something on the CC side, a fix or conclusion would be excellent.
I did update my Astro version to attempt to fix this, but if you want me to roll back to a previous version to find one that works, I can take those steps on my side if necessary.
As @silveltman and @oliverlynch have noted, the work around is conditional display of the tag, and Astro dynamic tags appear to be broken in the live preview. I was able to solve my issue, but luckily my dynamic tag currently only had two options.
Hi all 🙋 (@edmeehan @silveltman @oliverlynch) Just a heads up that this has been fixed in the latest release of Bookshop (3.10.0)! Thanks for you patience while we worked on this!
Bookshop 3.10.0 includes a number of smaller fixes that we don't have issues for, but were common pain points for Astro, so you might want to check out the changelog and see if there's anything else in there that applies to you
Great @Tate-CC !
Are there also fixes that prevent the live editor breaking when using destructred props? I reported quiet a lot of bugs like that via chat some time ago. They just kept coming so I gave up then.
If these sound familiar and are fixed I think I can give it another try!
Hi @silveltman!
I don't believe there were any fixes to destructured props included specifically in the release.
If I recall it was to do with destructuring the root frontmatter object, does that sound right? If you happen to still have a reproduction case around, you could put that into it's own issue thread and I could investigate whether or not it's something we can fix as a fast follow!
yes that sounds right, but I believe there were other places too causing problems, not only the root frontmatter.
If I bump into it will let you know!
This breaks live editing:
and this does not: