NEXT: NavTile - manual selection handling

[SIMULATAN]

NavTile.svelte uses the value of the NavBar in its context to compare its ID to this value to determine whether the tile is selected or not.

skeleton/packages/skeleton-svelte/src/lib/components/Navigation/NavTile.svelte

Line 52 in 9eb7881

const rxBackground = $derived(selected || ctx.value === id ? active : `${background} ${hover}`);

However, this results in tiles that have manual selection handling incorrectly assuming this state even when explicitly set not to.

In 863c9cf, Navigation.Tile's id prop was made generated by default.

Instead, I propose to add an explicit | null to the id prop.

skeleton/packages/skeleton-svelte/src/lib/components/Navigation/types.ts

Line 102 in 863c9cf

id?: string;

The existing useId will run when the property is undefined (unspecified) as it is right now. When it is set to null explicitly however, the new logic should only respect the selected property.

Here's a video demonstrating the current issue (not embedded for some reason, simply open the link in your browser):
https://github.com/user-attachments/assets/5cde5442-bb71-4d92-9ec2-2c02101c4c78

I would love to contribute this change myself after confirming the logic.

Original post on Discord: https://discord.com/channels/1003691521280856084/1191790107867488316/1340676288838373510

[phamduylong]

I understand the logic and reasoning behind this change, but I don't really like the proposed solution of using null. I think it's better to write an else if of some sort for the $derived rune call here. Something like:

if(selected !== undefined) {
  // set explicitly by user, takes priority
} else {
  // context value check
}

I haven't tested the solution properly, but I believe selected can be undefined. This requires removing false as the default value for selected.

[SIMULATAN]

Oh, true, that's indeed a better solution. I already considered doing it this way but somehow didn't proceed to check it. Will open a PR in a minute.

[phamduylong]

NOTE: This might be the solution to #3198 as well. I can test it once again after the PR for this issue is merged.

FYI @endigo9740

[endigo9740]

@phamduylong feel free to restest #3198 please sir!