-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Returning normalised data #34
Comments
You can use https://github.com/klis87/normy/blob/master/packages/normy-react-query/src/create-query-normalizer.ts#L47C5-L47C22 to read normalized state at any time. But I am not sure it should be read actually. Please provide your use case, why you actually need that. Ideally please provide also some snippets, with useQuery example, and what response you would expect and what you try to achieve. Then we will think how to solve your problem. |
We have a DuckDB setup in our application with pre-normalized data, and an API that returns denormalized data. We want to use each data source independently based on different conditions, but need a common abstraction so that both sources return the same data structure. Since denormalizing the DuckDB data at runtime would require too many API calls to the server, we've decided to normalize the API data instead. The API returns deeply nested data like this: While DuckDB contains normalized data like this:
I attempted to use 'normy' to normalize the API data, but when querying through react-query, it still returned the denormalized structure." |
What normy does, is that it keeps normalized store separately, outside of useQuery. UseQuery will always return original server data, usually this is what we want. The biggest normy usecase is to normalize data in order to have features like:
Did you try to use |
I have a use case where I want the returned value from the useQuery hook should be the normalised data instead of the reconstructed denormalised data. Would it be possible to configure this kind of behaviour
The text was updated successfully, but these errors were encountered: