openstatusHQ
Bring your own store: replacing nuqs with custom state management (zustand or other client-side libraries)
Hey there,
I love the look and feel of this DataTable and really want to use it in my app, however, is uses nuqs for managing a lot of the state it seems. While this is super clean and works great in a traditional page routed app, I am working on app that will ultimately have no routes (SPA).
I've come across a couple DTs now that use nuqs and I want to use them so bad but I my capabilities are just not quite up to scratch at the moment to translate these DTs into something that doesn't rely on nuqs! Has anyone modified this repo at all in such a way so nuqs isn't necessary?
Sorry I posted this in the issues section as it isn't really the fault of the repo but just hoping to open a discussion here.
Hey @Jopgood! Since nuqs v2, it supports React SPA - would that work for your use case? I really want to make it work with a Vite example (#14) but time is just too limited right now.
Hey @mxkaske - my apologies, I should've been more specific. I saw that there was support for SPA but I think my main issue is NUQS. I am building a web app that uses a browser-like in-app tab system and so page routing and URL params just aren't possible due to the nature of the app.
I ended up writing a sort of copy of https://github.com/sadmann7/shadcn-table (Dice UI) that made use of Zustand instead of Nuqs but it has taken a while and doesn't feel as "clean". I basically need to find a better way to manage table state not via the URL
Gotcha! Indeed, we are using URL as state manager and not any client-side libraries like zustand. I believe we can create adapters (and create extractions) to BYO state manager but that's too much out of scope currently. :(
If you or someone is interested into extracting the nuqs logic into a wrapper - I am here to help and guide you!
Yeah, that could be really cool! I'd be happy to try to find the time to work on something like this.
The main challenge is that nuqs manages state server-side (syncing with URL params) whereas most custom state libraries like Zustand are purely client-side, so there's a tricky sync problem to solve. Currently, persisting with Zustand is my best approach, but I'm not sure of other elegant solutions yet.
Would you be interested in collaborating on this? It might be worth exploring how to create an abstraction layer that could work with different state management solutions.
Hey @Jopgood!
Yes good catch, compared to the /default data-table that uses client-side filtering (and URL params for persistence), the /infinite data-table takes another approach as it uses the URL params on the server to be used as filter queries. The /infinite/api is a GET request. I can imagine we can simply extend it with a POST request and pass the search params as body params and don't have to change a lot on the server.
Happy to collaborate!
Hey both @mxkaske and @Icestonks
I have begun a very early test to eek in some changes and think out my ideas on how this could work
I'm still a little hazy at the moment on how to implement a BYOS system for this but I do have a rough idea.
You can find my latest commit here: https://github.com/openstatusHQ/data-table-filters/commit/501c809ff16732143e7da6c94e9d6a0bc8b2fcc4