Drop entity detail cache

[TeodoraPavlova]

Related to #191

Maybe you wonder why this is all about? The things I tried before doing the proposed implementation:

• I could've just call deactivated() hook in ReferencedEntitySelect and clear the selected. However, then the same problem (described in Showing package catalog details does not properly show the data set #191) occurred after selecting another entity, listed as FK in the current detail view.
• Why I didn't exclude the component from keep alive rather than binding key to <router-view>? I tried that also, but then the excluded component had no access to the router state.. I also tried to switch <router-view> and <keep-alive> places, but then we get a warning in the console.
• Why I didn't just did <router-view :key="$route.fullPath">? Because it will trigger an instance replacement every time when the route changes.

With the proposed implementation we will be able to easily include/exclude any page which we want or not want to cache.

I'm open for ideas/suggestions.

[jonas-brr]

@TeodoraPavlova I don't understand why the 2nd point doesn't work. Excluding a component from keep-alive shouldn't cause any problems with accessing the router - at least in my experience, maybe something specific to AIMAAS does this (?) For a quick fix I'd really prefer the 2nd bullet point -if it worked - as this solution feels a bit hacky to my taste.

THE proper way imho though would be to do state management the right way - decoupled from the components. A standardized solution could be something like https://pinia.vuejs.org/ - but other ways are ofc possible. Once we'll free the data/state and API interactions from the component hierarchy we'll have no such problems and we will be able to use keep-alive everywhere without issues.

But I admit it'd be a substantially larger time investment.

[TeodoraPavlova]

@jonas-brr I totally agree with you, that the solution is a little bit hacky and if we want to do this the 'proper way' (for example using state management library) will take more time..

Regarding why the 2nd point is not working, I'm not sure either.

[TeodoraPavlova]

@jonas-brr thanks a lot for confirming my thoughts, I will dive deeper and see what I can do in order to achieve the 2nd approach

[TeodoraPavlova]

@jonas-brr just FYI, I was able to make it via excluding components from keep alive.

Regarding the router, strangely this part of the code was not working, but now rewritten it works.

[crazyscientist]

Hey, sorry for being late to the discussion...

This might be a rather fundamental question: Have you considered in your experiments that the <keep-alive> in App.vue does not serve an intentional purpose? Maybe it could be removed?

As we have a second <keep-alive> in Tabbing.vue: Would it make sense to clear/destroy this cache, when the parent component Tabbing gets unmounted?

[TeodoraPavlova]

TBH, I was not aware that we have more than 1 <keep-alive> ...

[TeodoraPavlova]

Have you considered in your experiments that the in App.vue does not serve an intentional purpose? Maybe it could be removed?

Yes, you're right, it can be removed. The removal even resolves the issue. Unpleasantly, I've found that the same problem occurs if you are in entity detail and click on a reference link (the page gets filled with the new entity detail data, but the old references are still there along with the new ones). So, we will still need something like this.

[crazyscientist]

The removal even resolves the issue.

That is good news 👍

So, we will still need something like this.

I take it, my idea of clearing the Keep-Alive's cache was not viable. And "this" looks simple enough 🙂 👍