router: [BUG] lifecycle callbacks called in wrong sequence for top level route.

I’m submitting a bug report

Library Version: all It is a regression caused by aurelia-templating v1.8.2. But I am pretty sure this is a router bug (whether the buggy code is in this repo, I am not sure), the new aurelia-templating fix just made this router bug appears even worse.
Operating System: OSX 10.13
Node Version: 8.11.3
NPM Version: 6.2.0
JSPM OR Webpack AND Version NA
Browser: all
Language: all

Current behavior: https://github.com/huochunpeng/router-bug2

app.js has one level router config with two pages (page-one.js and page-two.js), here is the log of lifecycle callbacks

with aurelia-templating 1.8.1 (with or without bluebird) note bind() is in right order, ~~but attached() is not (page-one should be attached before app)~~

[Log] app configureRouter (app-bundle.js, line 22)
[Log] app bind (app-bundle.js, line 34)
[Log] page-one bind (app-bundle.js, line 105)
[Log] app attached (app-bundle.js, line 38)
[Log] page-one attached (app-bundle.js, line 109)

with aurelia-templating 1.8.2 (with or without bluebird) bind() is in wrong order, ~~plus wrong attached() order~~

[Log] app configureRouter (app-bundle.js, line 22)
[Log] page-one bind (app-bundle.js, line 105)
[Log] app bind (app-bundle.js, line 34)
[Log] app attached (app-bundle.js, line 38)
[Log] page-one attached (app-bundle.js, line 109)

Due to the wrong bind() call sequence, the page-one now doesn’t get correct inherit overrideContext from app.

User has reported missing variable (defined in top app.js) in router loaded component view template. https://discourse.aurelia.io/t/using-require-breaks-router/1411/31?u=huochunpeng

This bug is related to #548, which can be fixed by #571. But that fix only fix lifecycle callbacks for nested route, not the top route (as top route is not delayed).

Expected/desired behavior:

~~No matter what aurelia-templating version in use, our sequence is NOT right.~~ ~~aurelia-templating v1.8.2 made this bug even worse, and more noticeable to end user.~~

What is the expected behavior?
What is the motivation / use case for changing the behavior?

The user experienced missing variable (due to missing overrideContext) is not the bug we want to fix. The wrong lifecycle callback sequence is the bug to be solved.

cc @bigopon @davismj @EisenbergEffect

aurelia-templating v1.8.2 just killed off everyone (intentionally or unintentionally) rely on the default inheritBindingContext behaviour of router loaded component.

About this issue

Original URL
State: open
Created 6 years ago
Reactions: 1
Comments: 19 (16 by maintainers)

Most upvoted comments

For completeness sake I should point out I’ve done some digging into a potentially related issue a couple months back: https://github.com/aurelia/templating-router/issues/26

The most relevant bit from that topic is this visualization of the lifecycle steps when there is a 300ms promise delay between the activates of 4 nested child routers:

Pay attention to the arrows:

35.298 [-view-model 1] activate
35.337 [-view-model 1] configureRouter
35.346 [-router-view 1] created
35.353 [-view-model 1] created
35.362 [-view-model 1] bind
35.377 [-router-view 1] bind <-------------
35.400 [--view-model 2] configureRouter
35.407 [---view-model 3] configureRouter
35.414 [----view-model 4] configureRouter
35.422 [--view-model 2] activate
35.726 [---view-model 3] activate
36.030 [----view-model 4] activate
36.335 [-router-view 1] process
36.351 [--router-view 2] created
36.359 [--router-view 2] process
36.366 [---router-view 3] created
36.371 [---router-view 3] process
36.377 [----router-view 4] created
36.381 [----router-view 4] process
36.393 [----router-view 4] swap
36.397 [---router-view 3] swap
36.401 [----view-model 4] created
36.404 [----view-model 4] bind
36.409 [----router-view 4] bind <-------------
36.413 [--router-view 2] swap
36.418 [---view-model 3] created
36.422 [---view-model 3] bind
36.426 [---router-view 3] bind <-------------
36.431 [-router-view 1] swap
36.435 [--view-model 2] created
36.439 [--view-model 2] bind
36.444 [--router-view 2] bind <-------------
36.451 [----router-view 4] _notify
36.454 [---router-view 3] _notify
36.455 [--router-view 2] _notify
36.455 [-router-view 1] _notify
36.458 [-view-model 1] attached
36.469 [--view-model 2] attached
36.471 [---view-model 3] attached
36.472 [----view-model 4] attached

Now the router-view 1 being first isn’t necessarily weird or wrong, because that’s the root. The App always gets a special treatment in the lifecycle.

What I see as a problem (as @StrahilKazlachev eluded on Discord, and others may have said this as well) is first of all that binding happens inside-out, and secondly that process happens before bind.

I have a feeling this is rooted in the router pipeline, but it’s hard to know for sure. Time to put vCurrent in a monorepo and write some integration tests… x)

fkleuver on Jul 22, 2018

Man, on aurelia home page 😃 https://discourse.aurelia.io

3cp on Sep 21, 2018

@bigopon for nested child routes, if you bring #571, it might just works.

3cp on Jul 29, 2018

note bind() is in right order, but attached() is not (page-one should be attached before app)

This is not correct. Child element cannot have attached called before parent’s attached gets called.

bigopon on Jul 22, 2018