-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
camelCased variable names are not reactive. #7381
Comments
@stanoychev is this specifically when used as web-components? Camel case variables definitely work fine in "normal" use: https://svelte.dev/repl/827e19b813e84e348b1bfb0c5d08e3dd?version=3.46.4 |
related #3919 |
Thank you for replaying. Unfortunately the online compiler doesn't work with custom elements / web-components 😐. So I transferred the code into local repository, got carried away and uploaded it here if anyone wants to check it To run it it`s the usual drill: git clone, npm i, npm run dev, click the buttons (once) |
There are a lot of issues around how svelte components behave when compiled to web-components and one of those issues is variable naming: #3852. There's a plugin that might help: https://github.com/roonie007/vite-plugin-svelte-kebab-props |
I think there should be a way to specify the attribute name for a variable. I'm not sure what the best way to do this is. Maybe a comment? // svelte:attribute "my-custom-attribute"
export let myCustomAttribute = 1; This leaves no ambiguity for casing. |
This isn't legal JS, so it won't fly, but we already have renamed exports.
This could be resolved with module level exports for renaming, but that feels super icky.
|
Closing as duplicate of #5184 |
Describe the bug
Hello.
This is my first bug report ever on github, so if I`m doing it wrong please excuse me.
It seems that svelte is not handling very well the camelCased variables.
but, when I use the element like
I expected "Hello test!", but it stays on "Hello world!" and on the console window we have a message
Another thing is, calling
document.getElementById('test-a').setAttribute('variableName', 'from attribute');
I expected < h1 > to change to "Hello from attribute!", but it stays on "Hello world!". If I type
document.getElementById('test-a').getAttribute('variableName');
it returns 'from attribute', and indeed on the html inspector window we can observe that the attribute is updated: < test-a id="test-a" variableName="from attribute" >, but inside the rendered element it stays on < h1 >Hello world!< /h1 >.
Another approach is if I call
document.getElementById('test-a').variableName = 'from attribute';
the h1 gets updated correctly to < h1 >Hello from attribute!< /h1 > (the asociated attribute value stays unupdated < test-a id="test-a" variableName="world" >).
In the above example if "variableName" is lowercased to "variablename" everithing works fine.
(Question 1) Is this expected behaviour? Am I using this right and how is the correct way to use it? In the documentation I didn`t find anything that says something like "variable names must be always lowercased".
For me it seems that the root cause is attaching the update logic of the variables to the attributes names, which are now automaticaly lowercased, causing mismatch between variable name string "variableName" and it`s subscribtion name string "variablename", resulting in not updating.
(Question 2) Is there any compiler option to set to handle this, npm package or any other magic we can use? The camelCase naming is important for our project
Reproduction
Expected h1: "Hello test!"
Actual result: "Hello world!"
document.getElementById('test-a').setAttribute('variableName', 'from attribute');
Expected h1: "Hello from attribute!"
Actual result: "Hello world!"
Logs
No response
System Info
Severity
annoyance
The text was updated successfully, but these errors were encountered: