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

Two-Way Binding With Native Components Not In Sync With Attribute #5705

Closed
munawarb opened this issue Nov 21, 2020 · 6 comments · Fixed by #8457
Closed

Two-Way Binding With Native Components Not In Sync With Attribute #5705

munawarb opened this issue Nov 21, 2020 · 6 comments · Fixed by #8457

Comments

@munawarb
Copy link

munawarb commented Nov 21, 2020

I'm writing a native web component using Svelte which is a wrapper around an edit field:

<script>
export let value = "Default Value";
</script>
<main>
<input type="text" bind:value={value} />
</main>

I can set the value, which properly updates the textbox.

I then type stuff into the textbox, which updates value, which I can verify by using document.getElementById("my-component").value.

However, when I get the value of my component using document.getElementById("my-component").getAttribute("value"), it returns the last value that I set using setAttribute("value", "Some other value").

It doesn't return the actual value property on the component that got updated when I typed stuff into the textbox.

How can I keep the attribute and property in sync, or is there not a way to do this?

This is when I compile my component as a native web component.

@munawarb munawarb changed the title Two-Way Binding With Native Components How To Update Attribute? Two-Way Binding With Native Components Not In Sync With Attribute Nov 21, 2020
@richnew10
Copy link

I see this more generally: any change to a prop of a web component (e.g., adding value = 'foo'; at the bottom of your script) does not propagate to the component, either as a property or an attribute.

Did you make any progress on this, @munawarb?

@munawarb
Copy link
Author

Hi @richnew10, No, I haven't looked further into this. We ended up just using the property names instead of attributes since it's consistent and we don't get the out-of-sync problem.

@geoffrich
Copy link
Member

Svelte won't reflect property changes to the corresponding attribute automatically. You have to do that yourself, which is a little tricky since there isn't a defined way to get the current custom element instance (see #3091). You can work around it using the get_current_component internal API, but this could change behavior without warning because it's not intended for external use.

Here's an example of updating the element's name attribute when the property changes. Clicking the button will set the <my-el> name property to true as well as the attribute.

<script>
	export let name;

	import { get_current_component } from 'svelte/internal';

	$: get_current_component().setAttribute('name', name);
</script>

<svelte:options tag="my-el"></svelte:options>

<p>Hello {name}</p>
<button on:click={() => name = 'test'}>Update name</button>

This would be a nice feature to have built in for those authoring custom elements in Svelte. Other frameworks like Lit make it easy.

I see this more generally: any change to a prop of a web component (e.g., adding value = 'foo'; at the bottom of your script) does not propagate to the component, either as a property or an attribute.

@richnew10 I do see the property being updated on the custom element in my example, i.e. document.querySelector('my-el').name returns test after clicking the button. Are you seeing something different?

@richnew10
Copy link

Are you seeing something different?

I was, but I think it was an order of execution thing: Svelte seems to bind props after the contents of a component's <script> tag runs, and so my testing approach was flawed. I can reproduce the expected behavior that you described, thanks.

@stale
Copy link

stale bot commented Dec 15, 2021

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale-bot label Dec 15, 2021
@baseballyama baseballyama added this to the 4.x milestone Feb 26, 2023
dummdidumm added a commit that referenced this issue May 2, 2023
This is an overhaul of custom elements in Svelte. Instead of compiling to a custom element class, the Svelte component class is mostly preserved as-is. Instead a wrapper is introduced which wraps a Svelte component constructor and returns a HTML element constructor. This has a couple of advantages:

- component can be used both as a custom element as well as a regular component. This allows creating one wrapper custom element and using regular Svelte components inside. Fixes #3594, fixes #3128, fixes #4274, fixes #5486, fixes #3422, fixes #2969, helps with sveltejs/kit#4502
- all components are compiled with injected styles (inlined through Javascript), fixes #4274
- the wrapper instantiates the component in `connectedCallback` and disconnects it in `disconnectedCallback` (but only after one tick, because this could be a element move). Mount/destroy works as expected inside, fixes #5989, fixes #8191
- the wrapper forwards `addEventListener` calls to `component.$on`, which allows to listen to custom events, fixes #3119, closes #4142 
- some things are hard to auto-configure, like attribute hyphen preferences or whether or not setting a property should reflect back to the attribute. This is why `<svelte:options customElement={..}>` can also take an object to modify such aspects. This option allows to specify whether setting a prop should be reflected back to the attribute (default `false`), what to use when converting the property to the attribute value and vice versa (through `type`, default `String`, or when `export let prop = false` then `Boolean`), and what the corresponding attribute for the property is (`attribute`, default lowercased prop name). These options are heavily inspired by lit: https://lit.dev/docs/components/properties. Closes #7638, fixes #5705
- adds a `shadowdom` option to control whether or not encapsulate the custom element. Closes #4330, closes #1748 

Breaking changes:
- Wrapped Svelte component now stays as a regular Svelte component (invokeing it like before with `new Component({ target: ..})` won't create a custom element). Its custom element constructor is now a static property named `element` on the class (`Component.element`) and should be regularly invoked through setting it in the html.
- The timing of mount/destroy/update is different. Mount/destroy/updating a prop all happen after a tick, so `shadowRoot.innerHTML` won't immediately reflect the change (Lit does this too). If you rely on it, you need to await a promise
@dummdidumm
Copy link
Member

Closed via #8457 via the new reflect capability, to be released in Svelte 4

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants