How to have behavior like $bindable, but in javascript code?

[0x1618]

Hello. I want to automatically update the variable in A component if value in B component (bind:this) changes it. I feel like a playground example will explain it well: Playground

[brunnerh]

What is the point of duplicating the state? This is not something one would usually do.

If you add export { buttonState } in the button, it can be accessed more directly in the form via submitButton.buttonState (though the button will initially be undefined until mount).

If you explain what you are really trying to do here instead (i.e. what user interaction the form & button should enable), maybe a better approach could be suggested.

[0x1618]

I want to create a centralized form wrapper/context to handle all requests, errors, and related functionality. I’ve already created a dynamic input where i can programmatically set the value and error messages coming from the API, which are related to the input value. I’ve implemented various styles on the button and icons that change according to the buttonState (e.g., success, failure, or static).

Currently the code related to form requests is about 200 loc, so a centralized function or wrapper is needed. There is problem with synchronizing the buttonState with the form context buttonState. For example, after the button displays its new state (success/failed) for 2 seconds it always reverts to "static" style.

The reason I want this setup for the button is to avoid desynchronization between the form context and the button. It would be nonsense to create the same timeout logic for buttonState in the form context. But i'm thinking about not sharing the buttonState between these 2 components and just directly call buttonSubmit.setButtonState, which would be more easier and cleaner.

[brunnerh]

For changing styles, you could consider setting classes on a parent element and taking those into account in the button's <style> (the classes from the parent would need to be unscoped via :global).

If I were to handle a component instance, I would try to interact with its props directly (as suggested above, export the state and just use that). Having a local copy of the state just causes issues.

Though I would probably rather communicate via a context instead.
Here you can also use an actual binding by passing state via snippet arguments (though this currently causes an ownership warning):

<FormContext>
	{#snippet children(props)}
		<Button
			bind:buttonState={props.buttonState}
			onclick={props.handleSubmit}
		>
			Submit
		</Button>
	{/snippet}
</FormContext>

<!-- FormContext.svelte -->
<script>
	let { children } = $props();

	const childrenProps = $state({
		buttonState: 'static',
		handleSubmit,
	});

	function handleSubmit() {
		console.log('submitted!');
		childrenProps.buttonState = 'success';
	};
</script>

{@render children(childrenProps)}

Playground

[0x1618]

By context, do you mean getContext and setContext? I thought about that too. Your solution is nice, but if there are multiple buttons or other components that can possibly take props, they might end up with incorrect props. I guess I'll just interact with the props directly by using export { buttonState }, right? or just submitButton?.setButtonState("success"); export const setButtonState = (newButtonState: ButtonState) => {buttonState = newButtonState;};, because i have benefit of ?.

[brunnerh]

By context, do you mean getContext and setContext?

Yes.

Your solution is nice, but if there are multiple buttons or other components that can possibly take props, they might end up with incorrect props.

It is all manually wired up in the snippet, so I don't understand how things would end up in the wrong place.

Whether you use the exported prop or exported functions does not really matter, the former just gives you read and write access in one.

[0x1618]

It is all manually wired up in the snippet, so I don't understand how things would end up in the wrong place.

Nevermind, i realized you can use different names for snippets 😂 . However, i think the context solution is better.

Whether you use the exported prop or exported functions does not really matter, the former just gives you read and write access in one.

yes, i know. it's a matter of style. i just wanted to make sure it's okay to write code like that. thanks for the clarification.