Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implementing Custom Renderers triggers a misleading log message about the renderer not being recognized, while it actually is (and works) #12463

Open
1 task done
kyr0 opened this issue Nov 18, 2024 · 1 comment · May be fixed by #12461
Assignees
Labels
- P3: minor bug An edge case that only affects very specific usage (priority) feat: rendering Related to prop serialization, html escaping, and framework components (scope)

Comments

@kyr0
Copy link

kyr0 commented Nov 18, 2024

Astro Info

Astro                    v4.16.13
Node                     v23.2.0
System                   macOS (arm64)
Package Manager          npm
Output                   hybrid
Adapter                  @astrojs/cloudflare
Integrations             springtype

If this issue only occurs in one browser, which browser is a problem?

No response

Describe the Bug

Currently, when writing Astro integrations that use the addRenderer API of 'astro:config:setup', a quite misleading log message is printed with every re-render of any component that uses the custom renderer.

In my reproduction example you will find the log messages (after opening the console) despite the rendering working:
Bildschirmfoto 2024-11-18 um 03 44 02

This is, because the "recognized" renderers are hardcoded:

const clientOnlyValues = new Set(['solid-js', 'react', 'preact', 'vue', 'svelte', 'lit']);

The actual functionality however, works flawlessly, questioning the point of the log message warning.

Why is the log message misleading?
When Astro welcomes third party developers to use the addRenderer API to add custom renderers, and custom renderers work well, both in SSR and client mode, because they are very well recognized by their custom name,
then why would a log warning message like this make sense anymore?

I fixed this in the following PR:
#12461

Please don't be confused: In the reproduction example on CodeSandbox the issue still occurs because the dependency is pinned on the latest released astro version. When you check out my PR locally and run it with the command pnpm --filter @example/framework-custom run dev as developers are supposed to do, pnpm actually makes sure that my changed code with the fix is used and the misleading log message is already gone.

What's the expected result?

No warning log messages for custom renderers that clearly work and are recognized :)

Bildschirmfoto 2024-11-18 um 02 35 02

Link to Minimal Reproducible Example

https://codesandbox.io/p/devbox/github/kyr0/astro/tree/fix/custom-renderer-warning/examples/framework-custom

Participation

  • I am willing to submit a pull request for this issue.
@github-actions github-actions bot added the needs triage Issue needs to be triaged label Nov 18, 2024
@kyr0 kyr0 linked a pull request Nov 18, 2024 that will close this issue
@ematipico ematipico added - P3: minor bug An edge case that only affects very specific usage (priority) feat: rendering Related to prop serialization, html escaping, and framework components (scope) labels Nov 18, 2024
@github-actions github-actions bot removed the needs triage Issue needs to be triaged label Nov 18, 2024
@kyr0
Copy link
Author

kyr0 commented Nov 19, 2024

Note for people arriving late to the show (people from the future): Moved the example code for a custom renderer / custom frontend framework integration over here: https://github.com/kyr0/astro-custom-renderer

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
- P3: minor bug An edge case that only affects very specific usage (priority) feat: rendering Related to prop serialization, html escaping, and framework components (scope)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants