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

web components props converts "12345" to number. Does not respect the typeof. #671

Open
AlbertSabate opened this issue Dec 8, 2024 · 1 comment
Labels
bug Something isn't working

Comments

@AlbertSabate
Copy link
Collaborator

Describe the bug
web components props converts "12345" to number. Does not respect the typeof.

To Reproduce
inject a prop with a string 12345, the received prop will be a number 12345 instead of string.

Expected behavior
If I prop is string should be string, if prop is number should be a number. Same for other types. Maybe the serializer could handle props with number:... or string:... ??

@AlbertSabate AlbertSabate added the bug Something isn't working label Dec 8, 2024
@aralroca
Copy link
Collaborator

aralroca commented Dec 9, 2024

For now as a workaround you can force stringify this string:

<some-web-component foo={JSON.stringify(“12345”)} />

This translates to this HTML:

<some-web-component foo=“&quot12345&quot” />

And the Brisadeserialize it understands it as “12345”.

To solve it internally in Brisa, the current problem is that all attributes are being serialized, including in HTML elements such as <input value="12345" />, which is not deserialized because it expects a string always even if you put a number.

In order to solve it from Brisa, we would have to use a different serializer when consuming custom elements, which adds a layer of difficulty to make this distinction. Maybe in the client part we can use something like customElements.get(tagName)... And then in the server for SSR we already know the web components. Before implementing this, I want to investigate alternatives. Because this probably is going to increase the client build size, and we have to look for a solution that adds as little bytes as possible (if it can be reduced better, of course), and also does not increase the parse time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants