Giters

aurelia / router

A powerful client-side router.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

detached is called after deactivate

tbnovaes opened this issue · comments

commented

I'm submitting a bug report

  • Library Version:
    1.5.0

Please tell us about your environment:

  • Operating System:
    OSX 10.13.3

  • Node Version:
    9.4.0

  • NPM Version:
    5.6.0

  • Browser:
    all

  • Language:
    ESNext

Current behavior:
When I change the route to a different one, the deactivate is called before the detached methods from the child components. So if your components have do some cleanup, like cancel http pending requests, it will also cancel pending requests done by the new route.

Expected/desired behavior:
I'm not sure if the current behavior is the one expected by the framework, but I was expecting to have all the child components destroyed before the parent route being deactivate.

  • What is the motivation / use case for changing the behavior?
    Not having actions of a component that is being detached, affecting things that are being created.
commented

Yeah.. I guess it is still right..
Sorry for misfire the 1st time.

activate() and deactivate() do come from The Route Screen Activation Lifecycle
http://aurelia.io/docs/fundamentals/cheat-sheet#routing

and detached() and attached() - from component lifecycle.

So there is a possibility, that deactivate() won't succeed and your app won't actually navigate away.
Hence the order, I guess.

@EisenbergEffect, if I'm right then can be closed this time for real (-:

commented

@Alexander-Taran yes your point make sense. But still maybe the lifecycle should be canDeactivate (router), detached (all components), deactivate(router).

commented

A man can dream (-:
can you elaborate your use case?
I'm pretty sure it won't happen in 1.x because it is a breaking change.
But maybe you see something that was overlooked.

commented

Both cases happened to me in the same application I was building, may be a special case, or a bad design from my side, but it worth listing.

  1. User navigate away from route A. The child component has a pending request, it try to cancel the request on detached. Suddenly the requests done by route B are also cancelled. Because the route B activate method is also called before the detached from the child component of route A.

  2. I had to use a lib named windy (windy.com) it is an overlay for leaflet. It offers great features, but the only way to use it, is by adding/removing the script programmatically every time you want to load it. I want my component to manage adding the script on attached, and removing it on detached. So when I'm in route A using this component, and move to Route B also using this component, I don't run into conflicts. However, route B loaded before the detached, therefore when Route B tries to load the component, it has an error that the script was already there.

commented

@tbnovaes so activate is a completely separate lifecycle from attached and detatched. In this case, I think you're going to want to use the attached and detatched lifecycle, as activate and deactivate is more for preparing and cleaning up data and state. For this reason, detatched, removing the view from the dom, will always be called after deactivate.