Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Lifecycle order and same-route navigation problems #680

Open
UserGalileo opened this issue Sep 23, 2021 · 0 comments
Open

Lifecycle order and same-route navigation problems #680

UserGalileo opened this issue Sep 23, 2021 · 0 comments

Comments

@UserGalileo
Copy link

Hi guys,
I'm having troubles dealing with the lifecycle of the router, let me explain.
Since the order reflects what actually happens in the DOM, the leaving parts comes after the entering ones.

This is giving me troubles in the sense that, suppose I'm in /users/:id:
I want to populate some global state when I enter the route and clear it when I'm leaving.

Right now I'm stuck with this code:

  onBeforeEnter(location: RouterLocation) {
    // store.setActive(location.params.id);
  }

  onAfterEnter(location: RouterLocation) {
    // store.setActive(location.params.id);
  }

  onBeforeLeave() {
    // store.setActive(null);
  }
  • onAfterEnter is basically required because that's when I'm sure the component is loaded.
  • I cannot use onAfterLeave because it's the last one, so null would override the actual id on same-route navigation. So I have to use onBeforeLeave.
  • I have to write the same code in onBeforeEnter because otherwise, if I navigate to the same route (even with the same param), onBeforeLeave runs and sets my state to null.

This example works, but it's setting my state twice on each navigation and it needs duplicated code.

Is the problem solvable in any other way? This honestly seems counterintuitive, and even if that's the actual order of the DOM operations it performs, I think it'd be easier for devs if the order was something like this:

  • onBeforeEnter
  • onAfterEnter
  • onBeforeLeave
  • onAfterLeave

Which I think is what we see with other famous frameworks and libraries. What do you think? :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant