You can control the table from wherever you can put the `useTable` hook. 99% of the time this will be in your table component, but nothing is stopping you from hoisting this higher or decorating it with whatever other logic you want. Even if you chose not to hoist the hook, there is also nothing stopping you from listening to props and using callbacks to update this state. This is not a constraint of the API and more a constraint of how you choose to model your component-hook composition points.

Tell me if I'm wrong, but skimming the docs I understand that the table's filter state is in the local state of the table (state defined in the hook).

If it's the case, it does mean that the table component isn't controlled (as in "controlled input component"). What you describe (if I understand correctly) is _synchronising_ the local state of the table with my own global state, instead of controlling the table (giving my global state as param of the hook). This is breaking the one-way data flow that makes React so good.

The API I would expect would look more like:

    useTable(
        useFilter({value: myValue, onChange: myHandler})
    )

But I might be misunderstanding something, in which case please correct me! I am very interested in your library, the pattern has been around for a while but tables in React are always a PITA as they combine the problems of forms + lists + crazy interactivity

It's one-way control. There is no reasonable way to implement narrative "now my filter resides in global state. Whenever component changes, it's reflected in the state. Whenever state changes it's reflected in component". I asked this question in spectrum community https://spectrum.chat/react-table/general/how-to-control-fil...

There's definitely a difference between taking table state and storing it somewhere globally for use later and 100% controlling the table state from outside of the table. Doing the latter involves listening to the table state for changes in an effect, shipping the new state up to your higher-than-component storage location, detecting in that same component a change in the global storage location (usually just a memoized prop or hook of sorts) and updating the table state with your updated global state using either a table method like instance.setFilter or even a state reducer if you want total control. The tools are in place and the API is flexible enough to do what you are referring to. I'm sorry your comment in Spectrum got lost in the noise and that you had to resort to posting your question on here.

Thanks for detailed explanation and your time. I do understand that things I want to achieve are achievable. But I'm not happy with the complexity price I have to pay.

I believe that moving in the implementation between local and global state should be a snap. It's a matter of time when need to move local state to global will arise. And hooks have nothing to propose for that.

Good luck with your project.

There's nothing wrong with having useStore() next to useTable() and using a few effects to keep them in sync.

This would be acceptableway to go. But I did not manage to get it working. Saw your comment how to fix, but don't have code to validate that everything would work as expected.

Thanks.

FWIW that code snippet is broken -- you need to memorize your effect with [store.filter] to avoid the infinite loop.