Skip to content

Conversation

@ghost
Copy link

@ghost ghost commented Jan 31, 2025

Read-only bindings should have the SET value assigned to null, not the GET.

e.g. this:
<input type="checkbox" bind:indeterminate={null, () => true} />

...fails, while this:

<input type="checkbox" bind:indeterminate={() => true, null} />

...works as expected.
(note: ts doesn't love this, prefers: <input type="checkbox" bind:indeterminate={() => true, () => null} />)

Question: should I also add explicit wording for bind:indeterminate since it no longer works without explicitly defining a getter/setter:

let status = 'pending'
<input type="checkbox" bind:indeterminate={(staus === 'pending')} />`
// or
<input type="checkbox" bind:indeterminate={(satus === 'pending') ? true : false} />

Fail. Rather:

<input type="checkbox" bind:indeterminate={() => true, null} />

...appears to be the only way this binding currently works in Svelte5.

Alternatively, should support for indeterminate={true} be a feat: ticket?

Repl (duplicated below):
https://svelte.dev/playground/1e48fd6b1c8a46b8aba20a37545a0cd8?version=5.19.6

(edits:clarity and repl inclusion)

Before submitting the PR, please make sure you do the following

  • It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
  • Prefix your PR title with feat:, fix:, chore:, or docs:.
  • This message body should clearly illustrate what problems it solves.
  • Ideally, include a test that fails without this PR but passes with it.
  • If this PR changes code within packages/svelte/src, add a changeset (npx changeset).

Tests and linting

  • Run the tests with pnpm test and lint the project with pnpm lint

Read-only bindings should have the SET value assigned to null, not the get.

Question: should I add a line-item for bind:indeterminate since it no longer works without explicitly defining a getter/setter, e.g.

<input type="checkbox" bind:indeterminate={true, null} />

is the only way this binding currently works in Svelte5.
@changeset-bot
Copy link

changeset-bot bot commented Jan 31, 2025

⚠️ No Changeset found

Latest commit: 664b9fe

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

@ghost ghost changed the title Fixes swapped logic for readonly function bindings docs: Fixes swapped logic for readonly function bindings Jan 31, 2025
@Conduitry
Copy link
Member

The first bind function is for taking a value from elsewhere in your app and applying it to this element. The second bind function is for taking a value from this element and applying it elsewhere in your app. The latter is correct for things like width/height bindings.

The names get and set are a bit confusing, especially since set is what you should be using for what we're calling 'read-only bindings'. I'm not sure how to make this less confusing.

This would be separate from whatever you're experiencing with bind:indeterminate. Do you have complete REPLs of what you're trying to achieve? There could well be a bug or a valid feature request here.

@ghost
Copy link
Author

ghost commented Jan 31, 2025

Ah! I interpreted the get/set detail incorrectly...it just happened to play directly into how I was attempting it.

https://svelte.dev/playground/1e48fd6b1c8a46b8aba20a37545a0cd8?version=5.19.6

Un-commenting the first two will fail.

edit: The first example may be unintended behavior, but I believe the second and third examples might simply benefit from an additional line or two on function bindings docs.

Indeterminate would be a good counter-example to dimensions, to add that clarity you've given me w/r/t the direction get/set operates in.

@ghost ghost closed this Feb 1, 2025
This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant