Routing beyond forward and backward #73
Conversation
drafts/angular-navigation-concept.md
Outdated
| # Conclusion | ||
|
|
||
| Implementing this new navigation concept showed me how working with the available tools and APIs can significantly simplify the implementation. | ||
| I was able to reduce a lot of code, make the implementation easier, and even resolve some edge case bugs. |
There was a problem hiding this comment.
Minor point: most of the article uses 'we', and this use of 'I' feels odd.
drafts/angular-navigation-concept.md
Outdated
|
|
||
| ## 2. Reading Current State | ||
|
|
||
| I mentioned before that navigating back or forward (`popstate`) would restore the state from the newly activated page. |
There was a problem hiding this comment.
Most of the article uses 'we', and this section starts with 'I'. Suggest 'As mentioned before ' , to keep it neutral?
drafts/angular-navigation-concept.md
Outdated
| --- | ||
|
|
||
| The navigation in complex web applications quickly goes beyond forward and back navigation. | ||
| I recently rebuilt the navigation for a large project. |
There was a problem hiding this comment.
I vs We ? Most of the article is 'we'
|
Nice topic, narrow-focused and well written! I don't know Angular, and I wonder if there's a way to package this functionality so that other projects can more easily adopt the same navigational flow with minimal integration? |
implement small comments
| The `Angular Router` provides an observable for navigation events. | ||
| We can subscribe to `router.events` and listen for `NavigationEnd`. | ||
| At this point, we know the navigation has successfully finished, and we can update the state. | ||
| One important note is that we do not want to increase the offset if we navigate using `{ replaceUrl: true }`. |
There was a problem hiding this comment.
Idea: Explain why is replaceUrl used, what does it do, what are the implications.
|
|
||
| Detecting back navigation into a finished flow can be solved using a guard: `flow-page-activation.guard`. | ||
| The guard verifies if the origin URL belongs to the current flow. | ||
| If it does, the navigation is allowed; otherwise, the navigation is blocked. |
There was a problem hiding this comment.
That means that the "flow confirmation page" aka the page where the flow is finished, must not have the flowBasePath. Do I understand this correctly?
See: https://software-engineering-corner.zuehlke.com/preview/6756da1561d775bf7c893146