v19.0.0-next.7

Compare Source

Breaking Changes

core

• Changes to effect timing which generally has two implications:

  • effects which are triggered outside of change detection run as part of
    the change detection process instead of as a microtask. Depending on the
    specifics of application/test setup, this can result in them executing
    earlier or later (or requiring additional test steps to trigger; see below
    examples).

  • effects which are triggered during change detection (e.g. by input
    signals) run earlier, before the component's template.

  We've seen a few common failure cases:

  • Tests which used to rely on the Promise timing of effects now need to
    await whenStable() or call .detectChanges() in order for effects to
    run.

  • Tests which use faked clocks may need to fast-forward/flush the clock to
    cause effects to run.

  • effect()s triggered during CD could rely on the application being fully
    rendered (for example, they could easily read computed styles, etc). With
    the change, they run before the component's updates and can get incorrect
    answers. The recent afterRenderEffect() API is a natural replacement for
    this style of effect.

  • effect()s which synchronize with the forms system are particularly
    timing-sensitive and might need to adjust their initialization timing.

• ExperimentalPendingTasks has been renamed to
  PendingTasks.

core

language-service