fix(component-store): use asapScheduler to schedule lifecycle hooks check

[amakhrov]

Switch from asyncScheduler to asapScheduler to prevent the "1 periodic timer(s) still in the queue" error.

PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our guidelines: https://github.com/ngrx/platform/blob/master/CONTRIBUTING.md#commit
• Tests for the changes have been added (for bug fixes / features)
  there are existing tests for this that still pass
• Documentation has been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

[x] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Documentation content changes
[ ] Other... Please describe:

What is the current behavior?

Closes #3573

What is the new behavior?

Does this PR introduce a breaking change?

[ ] Yes
[x] No

Other information

[netlify]

✅ Deploy Preview for ngrx-io canceled.

Built without sensitive environment variables

Name	Link
🔨 Latest commit	46357a3
🔍 Latest deploy log	https://app.netlify.com/sites/ngrx-io/deploys/6325009d6f3cdc00085b33dc

[amakhrov]

Additionally, I'm wondering whether the isDevMode() check should be performed at the very beginning, guarding the whole asapScheduler.schedule call, instead of just scheduled callback body

[brandonroberts]

I tried using isDevMode() outside the callback body, and it doesn't work as intended.

[markostanimirovic]

I renamed the PR title to avoid potential confusion because we can use ComponentStore within the fakeAsync, but we need to add at least one tick that will flush scheduled macrotasks:

it('works before changes from this PR', fakeAsync(() => {
  new ComponentStore();
  tick(0);
}); // no error

[markostanimirovic]

Thanks for the PR, @amakhrov! Can you add a unit test that verifies that there is no error?

[amakhrov]

what if I just change tick(0) to flushMicrotasks() in the existing tests (there are 2 of them for the hooks feature).

[markostanimirovic]

sounds good 👍

[timdeschryver]

I would still prefer a unit test though, the reproduction in the issue would be great.
This verifies that it solves that issue, and it also guard us against our future selves if we would change it back to another scheduler.

[aokrushk]

@timdeschryver It's hard to test for that. I'd say the flushMicrotasks(); change in unit tests is the one that "reproduces" the issue.

[aokrushk]

@timdeschryver It's hard to test for that. I'd say the flushMicrotasks(); change in unit tests is the one that "reproduces" the issue.