Please sign in to comment.
fix(activation): Deactivate child viewModels when replacing a parent
The `findDeactivatable` was looking for child viewModels to deactivate on `viewPortPlan.childNavigationInstruction` when present. This made sense in the case where you were replacing one child route with another, as the `BuildNavigationPlanStep` would properly identify which child route was being replaced and all the correct lifecycle methods would be invoked. However, this failed the not-so-edge case, seen here #411, where you were replacing a parent with an activated child. `BuildNavigationPlanStep` would not populate enough information on the child components to correctly deactivate them. The `LoadRouteStep` was inadvertently populating the missing information, and so the issue was only being seen on the `CanDeactivatePreviousStep`, which falls between the two. The `DeactivatePreviousStep` would proceed normally. @jagonzalez opened #496 which does seem to solve the issue. However, the solution identified when the problem was taking place, specifically on canDeactivate and when certain other conditions are met, and wrote a solution around that. His original solution was closer to solving the underlying problem, but failed a unit test which I found to be erroneous. This fix builds upon the ideas of the earlier pull request but attempts to better identify the underlying problem and solve it.
- Loading branch information...