Test Results

1 105 files  +2  1 105 suites  +2   1h 20m 43s ⏱️ - 1m 41s
7 020 tests +8  6 971 ✅ +8  49 💤 ±0  0 ❌ ±0 
7 390 runs  +1  7 331 ✅ +1  59 💤 ±0  0 ❌ ±0 

Results for commit 38af05a. ± Comparison against base commit 8b803ad.

♻️ This comment has been updated with latest results.

Draft for now - just wanted to see existing tests pass fine with the change. Still needs tests to be added for the refresh functionality.

Something to consider is @PreserveOnRefresh routes - what should we do with them? This PR basically bypasses them, so even if explicit reload API is called, the cached instance will still be used. We could recreate those as well if it seems appropriate.

Something to consider is @PreserveOnRefresh routes - what should we do with them? This PR basically bypasses them, so even if explicit reload API is called, the cached instance will still be used. We could recreate those as well if it seems appropriate.

My opinion is that the new API should recreate components even if the route is marked with @PreserveOnRefresh. The new method performs an action that is different from a normal page reload or navigation, so if a developer is explicitly calling it, I think it would expect route component(s) to be recreated, even if preserve on refresh is in use.

Logic in this PR recreates the whole layout chain, which might not be wanted in all cases. Working on a change to provide means to control this in the API.

Quality Gate passed

Issues
58 New issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarCloud