Why do I need to manually call refresh() after calling a setter? #631
Replies: 2 comments 1 reply
-
Thanks for the feedback @ethanresnick. When you call Note that a pattern that I'm starting to use now is to use a listener plugin that automatically refreshes the state when my apps needs a new UI: function createListenerPlugin() {
return {
subscribe({ onSelect }) {
onSelect(({ refresh }) => {
refresh();
});
},
};
}
const listenerPlugin = createListenerPlugin();
autocomplete({
// ...,
plugins: [listenerPlugin],
}); In your case, you could call So that we fully understand why this creates friction, can you share any code snippets where you feel this is cumbersome? Thanks! |
Beta Was this translation helpful? Give feedback.
-
This is sorta similar to the other thread I opened, in that there's nothing too cumbersome here, and I've been able to get it all working in my own project. It's more just another suggestion for something that it seems like the library should be able to handle automatically/internally, to save developers a bit of confusion (i.e., having to discover |
Beta Was this translation helpful? Give feedback.
-
Title pretty much says it all. It seems like just calling the setter should be an enough for the UI to update (though I can see an argument for maybe waiting a tick before re-rendering anything so that multiple setters can be called in sequence without each one triggering a full update). Making users call
refresh
themselves though seems weird and bug-prone.Beta Was this translation helpful? Give feedback.
All reactions