8000 Change Detection Not Working with Routing in Zone-Less Application · Issue #39296 · angular/angular · GitHub
[go: up one dir, main page]
Skip to content

Change Detection Not Working with Routing in Zone-Less Application #39296

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.

Sign up for GitHub

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

Jump to bottom
Closed
markostanimirovic opened this issue Oct 15, 2020 · 2 comments
Closed

Change Detection Not Working with Routing in Zone-Less Application #39296

markostanimirovic opened this issue Oct 15, 2020 · 2 comments
Assignees
@JiaLiPassion
Labels
area: core Issues related to the framework runtime area: zones Issues related to zone.js core: change detection P3 An issue that is relevant to core functions, but does not impede progress. Important, but not urgent state: confirmed state: has PR
Milestone
Backlog

Comments

@markostanimirovic
Copy link
Contributor

🐞 bug report

zoneless-routing-bug

Affected Package

The issue is caused by package @angular/core

Is this a regression?

No

Description

Issue happens in zone-less environment when routing is used. If you remove <router-outlet></router-outlet> from app component template and put <app-counter></app-counter>, everything works fine.

Problem makes ɵmarkDirty(this) that is called immediately in ngOnInit method of counter component (see bellow Workaround 1). Then, when you click on increment or decrement button, rootContext.flags is equal to 1 (DetectChanges) instead of 0 (Empty), and because of that, tick is never scheduled:

schedule-tick

🔬 Minimal Reproduction

  1. Clone https://github.com/markostanimirovic/zoneless-routing-bug repo
  2. Run npm install
  3. Run npm start
  4. Click on increment/decrement buttons, observe that count value is not changed
  5. Navigate to Counter 2, observe that count paragraph disappeared
  6. Navigate back to Counter, observe that count paragraph disappeared too

Workaround 1

  1. Open counter.component.ts file
  2. Comment out lines 24-29
  3. Uncomment lines 32-38

Workaround 2

  1. Open app.component.ts file
  2. Swap ɵmarkDirty(this) with ɵdetectChanges(this) on line 21

🌍 Your Environment

Angular Version: 10.1.6
@AndrewKushnir AndrewKushnir added area: core Issues related to the framework runtime core: change detection labels Oct 16, 2020
@ngbot ngbot bot modified the milestone: needsTriage Oct 16, 2020
@JiaLiPassion JiaLiPassion self-assigned this Oct 17, 2020
@JiaLiPassion
Copy link
Contributor

This seems to be a bug that when markDirty() is called during another markDirty and the rootContext.flags are not reset. I will create a PR to fix it.

@JiaLiPassion JiaLiPassion mentioned this issue Oct 17, 2020
Closed
@atscott atscott added area: zones Issues related to zone.js P3 An issue that is relevant to core functions, but does not impede progress. Important, but not urgent state: confirmed state: has PR labels Oct 19, 2020
@ngbot ngbot bot modified the milestones: needsTriage, Backlog Oct 19, 2020
JiaLiPassion added a commit to JiaLiPassion/angular that referenced this issue Oct 20, 2020
@JiaLiPassion
fix(core): markDirty() should only mark flags when really scheduling …
1a82495 
…tick.

Close angular#39296

Fix an issue that `markDirty()` will not trigger change detection.

The case is for example we have the following component.

```
export class AppComponent implements OnInit {
  constructor(private router: Router) {}

  ngOnInit() {
    this.router.events
      .pipe(filter((e) => e instanceof NavigationEnd))
      .subscribe(() => ɵmarkDirty(this));
  }
}

export class CounterComponent implements OnInit, OnDestroy {
  ngOnInit() {
    this.countSubject.pipe(takeUntil(this.destroy)).subscribe((count) => {
      this.count = count;
      ɵmarkDirty(this);
    });
  }
```

Then the app navigate from `AppComponent` to `CounterComponent`,
so there are 2 `markDirty()` call at in a row.

The `1st` call is from `AppComponent` when router changed, the
`2nd` call is from `CounterComponent.ngOnInit()`.

And the `markDirty()->scheduleTick()` code look like this

```
function scheduleTick(rootContext, flags) {
    const nothingScheduled = rootContext.flags === 0 /* Empty */;
    rootContext.flags |= flags;
    if (nothingScheduled && rootContext.clean == _CLEAN_PROMISE) {
      rootContext.schedule(() => {
	...
        if (rootContext.flags & RootContextFlags.DetectChanges)
          rootContext.flags &= ~RootContextFlags.DetectChanges;
          tickContext();

        rootContext.clean = _CLEAN_PROMISE;
        ...
      });
```

So in this case, the `1st` markDirty() will
1. set rootContext.flags = 1
2. before `tickContext()`, reset rootContext.flags = 0
3. inside `tickContext()`, it will call `CounterComponent.ngOnint()`,
   so the `2nd` markDirty() is called.
4. and the `2nd` scheduleTick is called, `nothingScheduled` is true,
   but rootContext.clean is not `_CLEAN_PROMISE` yet, since the `1st` markDirty tick
   is still running.
5. So nowhere will reset the `rootContext.flags`.
6. then in the future, any other `markDirty()` call will not trigger the tick, since
   `nothingScheduled` is always false.

So `nothingScheduled` means no tick is scheduled, `rootContext.clean === _CLEAN_PROMISE`
means no tick is running.
So we should set the flags to `rootContext` only when `no tick is scheudled or running`.
josephperrott pushed a commit that referenced this issue Oct 29, 2020
@JiaLiPassion @josephperrott
fix(core): markDirty() should only mark flags when really scheduling …
8c82106 
…tick. (#39316)

Close #39296

Fix an issue that `markDirty()` will not trigger change detection.

The case is for example we have the following component.

```
export class AppComponent implements OnInit {
  constructor(private router: Router) {}

  ngOnInit() {
    this.router.events
      .pipe(filter((e) => e instanceof NavigationEnd))
      .subscribe(() => ɵmarkDirty(this));
  }
}

export class CounterComponent implements OnInit, OnDestroy {
  ngOnInit() {
    this.countSubject.pipe(takeUntil(this.destroy)).subscribe((count) => {
      this.count = count;
      ɵmarkDirty(this);
    });
  }
```

Then the app navigate from `AppComponent` to `CounterComponent`,
so there are 2 `markDirty()` call at in a row.

The `1st` call is from `AppComponent` when router changed, the
`2nd` call is from `CounterComponent.ngOnInit()`.

And the `markDirty()->scheduleTick()` code look like this

```
function scheduleTick(rootContext, flags) {
    const nothingScheduled = rootContext.flags === 0 /* Empty */;
    rootContext.flags |= flags;
    if (nothingScheduled && rootContext.clean == _CLEAN_PROMISE) {
      rootContext.schedule(() => {
	...
        if (rootContext.flags & RootContextFlags.DetectChanges)
          rootContext.flags &= ~RootContextFlags.DetectChanges;
          tickContext();

        rootContext.clean = _CLEAN_PROMISE;
        ...
      });
```

So in this case, the `1st` markDirty() will
1. set rootContext.flags = 1
2. before `tickContext()`, reset rootContext.flags = 0
3. inside `tickContext()`, it will call `CounterComponent.ngOnint()`,
   so the `2nd` markDirty() is called.
4. and the `2nd` scheduleTick is called, `nothingScheduled` is true,
   but rootContext.clean is not `_CLEAN_PROMISE` yet, since the `1st` markDirty tick
   is still running.
5. So nowhere will reset the `rootContext.flags`.
6. then in the future, any other `markDirty()` call will not trigger the tick, since
   `nothingScheduled` is always false.

So `nothingScheduled` means no tick is scheduled, `rootContext.clean === _CLEAN_PROMISE`
means no tick is running.
So we should set the flags to `rootContext` only when `no tick is scheudled or running`.

PR Close #39316
josephperrott pushed a commit that referenced this issue Oct 29, 2020
@JiaLiPassion @josephperrott
fix(core): markDirty() should only mark flags when really scheduling …
3b6497b 
…tick. (#39316)

Close #39296

Fix an issue that `markDirty()` will not trigger change detection.

The case is for example we have the following component.

```
export class AppComponent implements OnInit {
  constructor(private router: Router) {}

  ngOnInit() {
    this.router.events
      .pipe(filter((e) => e instanceof NavigationEnd))
      .subscribe(() => ɵmarkDirty(this));
  }
}

export class CounterComponent implements OnInit, OnDestroy {
  ngOnInit() {
    this.countSubject.pipe(takeUntil(this.destroy)).subscribe((count) => {
      this.count = count;
      ɵmarkDirty(this);
    });
  }
```

Then the app navigate from `AppComponent` to `CounterComponent`,
so there are 2 `markDirty()` call at in a row.

The `1st` call is from `AppComponent` when router changed, the
`2nd` call is from `CounterComponent.ngOnInit()`.

And the `markDirty()->scheduleTick()` code look like this

```
function scheduleTick(rootContext, flags) {
    const nothingScheduled = rootContext.flags === 0 /* Empty */;
    rootContext.flags |= flags;
    if (nothingScheduled && rootContext.clean == _CLEAN_PROMISE) {
      rootContext.schedule(() => {
	...
        if (rootContext.flags & RootContextFlags.DetectChanges)
          rootContext.flags &= ~RootContextFlags.DetectChanges;
          tickContext();

        rootContext.clean = _CLEAN_PROMISE;
        ...
      });
```

So in this case, the `1st` markDirty() will
1. set rootContext.flags = 1
2. before `tickContext()`, reset rootContext.flags = 0
3. inside `tickContext()`, it will call `CounterComponent.ngOnint()`,
   so the `2nd` markDirty() is called.
4. and the `2nd` scheduleTick is called, `nothingScheduled` is true,
   but rootContext.clean is not `_CLEAN_PROMISE` yet, since the `1st` markDirty tick
   is still running.
5. So nowhere will reset the `rootContext.flags`.
6. then in the future, any other `markDirty()` call will not trigger the tick, since
   `nothingScheduled` is always false.

So `nothingScheduled` means no tick is scheduled, `rootContext.clean === _CLEAN_PROMISE`
means no tick is running.
So we should set the flags to `rootContext` only when `no tick is scheudled or running`.

PR Close #39316
@angular-automatic-lock-bot
Copy link

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Nov 29, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@JiaLiPassion JiaLiPassion

Labels
area: core Issues related to the framework runtime area: zones Issues related to zone.js core: change detection P3 An issue that is relevant to core functions, but does not impede progress. Important, but not urgent state: confirmed state: has PR
Projects
None yet
Milestone
Backlog
Development

Successfully merging a pull request may close this issue.

fix(core): markDirty() should only mark flags when really scheduling tick JiaLiPassion/angular
4 participants
@atscott @JiaLiPassion @markostanimirovic @AndrewKushnir
0