Skip to content

fix(admin): nav back on cached components clashing with entity storage service

Rastislav Kruták requested to merge rkrutak/STR-1392/fix_entity_service into main

Description

The recent changes to the entity-storage service, which made sure to always read the entity id from the url, would cause issues on cached components. I will try to illustrate the problem on groups-subgroups component.

  1. Let's have a parent group with id 1 and its subgroup with id 2 in whatever vo
  2. Navigate from the groups-subgroups component to its subgroup with id 2 , thus our cache-route-reuse-strategy service (the cache service) would save a groups-subgroups component with group id 1 to the path organizations/whatever/groups/1/subgroups.
  3. Now already in overview component of the subgroup navigate back
  4. On navigating back the component saved on path organizations/whatever/groups/1/subgroups would be retrieved, but now on the said path in the cache there is a component with group id 2, even though we saved there one with id 1 and nothing changed according to the logs
  5. The only way for the cached component to change its group id would be if it called ngOnInit as that is the only place where entity-storage.getEntity(), but according to logs and debugs no such call was performed
  6. So basically the cached component changes its entity even though there is no trace of where and why

My fix was to let the overview (group-overview and vo-overview) components of cached components behave in the old way, old way meaning that the getEntity() does not read the id from the url but just reads whatever was set in the top component (detail components). The propagating of the correct id from the root component is slow and thus in the old way there is a doCheck implemented that basically calls getEntity() until the proper id is provided 🙃. I have no idea why this fix works imo it should have had nothing in common.

This solution is not the best and very hacky, but I basically just gave up after few days of trying to understand this garbage behaviour. That is also the reason of the verbose description with details of my "investigation" as maybe someone on review might think of the reason it behaves the way it does and point me to a better solution. If not I guess we can keep this one.

How to test

Find an entity from which you can access different entity of the same type (e.g. group->subgroups and click on one of the subgroups) and see that on nav back the data are correct. This means that this will not display the data for the entity for which the nav back was performed. Do this for both cached and uncached component e.g.:

Author's checklist

  • I have followed the contribution guidelines
  • This MR has been tested or does not change functionality
  • I have added relevant merge request dependencies (if this MR has any)
  • I have added the correct labels
  • I have assigned reviewers (if any are relevant)
  • I have edited the documentation (if the changes require it) or I have noted the need for the change if I do not have access to the documentation
  • I have marked all introduced BREAKING CHANGES or necessary DEPLOYMENT NOTES in the commit message(s)

Reviewer's checklist

  • This MR has been tested or does not change functionality
  • This MR has correct commit message format

Related issues

Closes STR-1392

Merge request reports