@ngrx/data - Allow getWithQuery() to replace the whole state instead of merging into it

[JustDoItSascha]

When using getWithQuery() there are situations where I want to replace the whole state instead of extending it. For example if I have a table with filters or pagination and I use getWithQuery to send the new query params to the server. Then the response should replace the whole state, otherwise I can't filter which entries belong to the currently activated filters.

Describe any alternatives/workarounds you're currently using

I couldn't find any good workaround for this. At first I thought the option readonly mergeStrategy?: MergeStrategy; does what I wanted to do, but no. This is just confusing because of the naming.

If accepted, I would be willing to submit a PR for this feature

[x] Yes (Assistance is provided if you need help submitting a pull request)
[ ] No

[Nvveen]

I would like to second this. In a more general sense, it's pretty hard to figure out how to replace the cache, or even not use it entirely in the store (the latter I still haven't figured out yet). I'm using @ngrx/data for its removing boilerplate concerning actions, reducers, and selectors, not necessarily client-side caching.

[timdeschryver]

I'm no ngrx/data expert but have you tried the following?
https://ngrx.io/guide/data/entity-actions#entitycache-level-actions

If that's not the case, I think you could (should?) write custom reducers https://ngrx.io/guide/data/entity-reducer#customizing-entity-reducer-behavior

[JustDoItSascha]

@timdeschryver Yeah, it's possible to write own reducers, but I also have to write own effects and if I write everything by myself there is no point in using ngrx/data at all. Especially for a feature which is very common and adds only one option and maybe 2-3 lines of code in the sources of ngrx/data. Because the actions are already there. I only have no possibility to tell the getWithQuery method what it should do.

[timdeschryver]

If it can be added to ngrx/data, I think you can create a PR for it and we can discuss there (or here).

[Nvveen]

Another possible solution is to inject a custom EntityChangeTracker that just overwrites the state. What would be nice to have in that case is to derive EntityChangeTrackerBase, but there's a possible obstacle with the merging query upserts, because they use the private function mergeServerUpserts, whereas the rest of the functions are part of the interface and are public. Were this function to be made protected, one can overwrite any caching behaviour in that change tracker without redefining the rest, and it all it would require is changing the keyword from private to protected.

[mattbodman]

I would also love to see this feature added. I can't think of a use case for the default behaviour. I always want to replace the cache with the query results, but maybe that's just me. In the meantime, as a quick and dirty way around it, I call clearCache() on the EntityService, right before call getWithQuery.

[brandonroberts]

If someone wants to create a PR for this that provides some flexibility, that would be good.

[tr1stan]

I have just tested out setting the options param to { mergeStrategy: MergeStrategy.OverwriteChanges } and it replaces any of the existing items in the store that also exist in the data returned by the query:

this.someService.getWithQuery(
                `filter=${someFilter}`,
                { mergeStrategy: MergeStrategy.OverwriteChanges }
            )

So I feel like this is doing what the OP is asking for.

[JustDoItSascha]

@tr1stan As the OP i can say it's not what I meant. There should be an option to replace ALL data, not only the entries that exist in the returned data.

[tr1stan]

Gotcha, sorry for the misunderstand. In that case using clearCache() is an option (as stated by @mattbodman) but that could leave your cache empty for longer than you'd like should the API call take a a while.

[JustDoItSascha]

This is exactly the problem ;-) And I think it would be easy to add another option for that inside the library or easier than hack something from the outside. But the lib is so complicated with all the auto generating stuff that it's not easy to contribute something...

[CoranH]

I'm surprised this issue hasn't had more interest. Two issues arise from not having a load with query type function:

• Querying potentially vastly more data than is needed (if using load method and then querying the data locally)
• Triggering a spurious observable emission of an empty collection (if using the clearCache workaround), which can trigger unpleasant flickering in an Angular UI that is subscribed to the collections observable.

If there's no workaround other than clearCache (which is causing the second issue for me currently), is there a good idea of how best to tackle this problem? I'm willing to try myself, if I could get some pointers. I'm guessing a loadWithQuery method, that combines the functionality from load and getWithQuery.

[matijhs]

I just ran into the same problem, has anyone found a proper workaround since?

[aimanicose]

@t-mish I'm facing the same issue, I can't seem to see any difference between getWithQuery and loadWithQuery unless I'm missing something as well. I'm clearing the cache before any request and use getWithQuery or loadWithQuery interchangeably to bypass the issue.
Did you figure out anything for this ?

[t-mish]

@aimanicose Hi. Yes, I found the solution. But I didn't go with loadWithQuery because it replaces the whole cache while I need to keep some changes intact.

In my case I have for example 50 items which firstly I got without any filters applied. Then I sent some filters via queryParams and received 20 filtered items. So, how can I show these filtered items if cache still contains all of them? Answer: no way. Why? Because it's cache.

The purpose of cache in ngrx data is to cache your requested results and allow you to run another actions like get, delete, update, etc. optimistically

I think you try to load all items first and then you want to get only a part of them. For this you constantly clearing your cache. Instead, you can use items which you get immediately when you call getWithQuery method. The response of this call has only those items you need (filtered ones). Ngrx will save these items to the cache too but it's useful only if you decide to use another operations optimistically.

Hope you find it useful.

[aimanicose]

@t-mish Thanks for the tip, using the items I get from getWithQuery worked. Using the items from loadWithQuery also worked ...

So I still can't see the difference between the two. The entity cache when peeking at entities$ is always the same. and loadWithQuery never seem to clear it.

[t-mish]

@aimanicose As I understand it, the difference is that if you make some changes to your items via update function and do it without sending a request to remote server then these changes will stay only in your local cache. If you then call getWithQuery the data you receive will be merged with these local changes. If you call the loadWithQuery all these changes will be lost.

[aimanicose]

@t-mish Makes more sense now, thank you.