Closed winston0410 closed 1 year ago
Yeah, the idea for the store part was to reflect the state and provide the reactivity for the component to make the appropriate render changes based on user interaction.
Going the other way would probably work best using custom methods on them as you suggest, off the top of my head the only example I can think of that currently does that are the ones that allow opening and closing the dialog programatically.
So it would probably be case of exposing some of the existing methods used internally onto the returned custom store.
Yeah, the idea for the store part was to reflect the state and provide the reactivity for the component to make the appropriate render changes based on user interaction.
Going the other way would probably work best using custom methods on them as you suggest, off the top of my head the only example I can think of that currently does that are the ones that allow opening and closing the dialog programatically.
So it would probably be case of exposing some of the existing methods used internally onto the returned custom store.
Maybe ultimately we might consider exporting set
? If we do that, it will be possible to not only restore the data, but also the state of the component programatically(for example, the component was opened before user closed the page, we save the state to storage, read from it when the user is back)
Currently I can see that stores in this project are
derived
stores, and only exporting the essential methods:https://github.com/CaptainCodeman/svelte-headlessui/blob/6232b53ef365b8f8f04f085dd6fd100b2b18e13a/packages/lib/src/lib/listbox.ts#L164-L176
This is fine for setting values with user interaction, but impossible for setting values programmatically. A practical use case would be injecting previously selected values from local storage. This is impossible right now. Is exporting the setter function something you would consider to unblock that usecase?