Another example where encapsulated (defualt flow-around) approach makes sense is to behave like React's <Context.Provider>. That API is designed to avoid "prop drilling", where an outer JSX component needs to pass data to an inner JSX component, but due to JSX's design, this ends up requiring every component in between to accept and pass along that same data. The generally accepted solution is to put a <Context> element around the outside, and then it can be accessed directly by any descendent without adding arguments everywhere in between. If, for some reason, there were an additional provider for the same context variable, it would override the previous one, but only for the current scope - so it's clean. It would be very susprising if changes to this context in a child scope ended up affecting other sibling subcomponents.

In general, this use case of "implicit parameter propagation without needing to virally change the signatures in between" is relevant both in JSX but also in ordinary JS, and it basically always wants the bind-around approach.

littledan:
Yeah, I remembered this issue have been discussed in the earlier stage of zone.js development, the policy of Zone.js is the callback should run in the same context(zone) when the task is scheduled.

1. for macrotask, such as setTimeout(callback), the setTimeout call schedule the async operation, so the callback should be in the same context(zone) with the setTimeout call

zone1.run(() => {
  setTimeout(() => {
    console.log(Zone.current.name); // should be zone1
  }, 0);
});

2. about eventTask such as button.addEventListener('click', handler);, we considered the schedule process is the addEventListener call instead of the dispatchEvent call.

zone1.run(() => {
  button.addEventListener('click', () => {
     console.log(Zone.current.name) // should be zone1;
  });

  zone2.run(() => {
    button.dispatchEvent(clickEvent);
  });
});

3. for microtask such as Promise, the schedule process is when promise.then is called.

let p = null;
zone1.run(() => {
  p = new Promise(...);
});
zone2.run(() => {
  p.then(() => {
    console.log(Zone.current); // will be zone2
  })
});

About eventTask, some people asks the question why the zone is not the zone when the event triggered which is confuse in some cases, but in Angular, event task basically always run in the same zone, so there are no big difference about using the register zone or the trigger zone(they are the same in the 99% of the use cases).

And I think the event trigger such as dispatchEvent is a synchronized operation, so depends on should we consider eventTask as an async operation, if it is , I think using the register zone is reasonable, if not, zone.js should leave the eventTask alone and not wrap it at all.

The exit is the end of the scope function. It applies scopes in exactly the same way. It just does it implicitly at the runtime level. And yes, there most certainly is a way to know when execution ends: any time the runtime would become idle and/or transition to microtask processing it knows it has reached the end of the current selection of synchronous code. At that point you end that context.

However, you don't actually need to know when an end occurs if all execution descends from a root at the beginning of execution as then the start of any execution would be propagating and therefore swapping out the context value anyway, so clearing it at the end actually becomes unnecessary as it would be immediately followed by a change anyway. There's actually been mathematical proofs of this for the .NET implementation.

The exit is the end of the scope function

And yes, there most certainly is a way to know when execution ends: any time the runtime would become idle and/or transition to microtask processing it knows it has reached the end of the current selection of synchronous code.

However, you don't actually need to know when an end occurs if all execution descends from a root at the beginning of execution as then the start of any execution would be propagating and therefore swapping out the context value anyway

So there are two cases.

1. User registered the click event handler in zone1, and user click the button with mouse, the click behavior happens in a noop zone (the default zone), and the handler should run in the registered zone.
2. User registered the click event handler in zone1, and user trigger the zone programmatically with something like dispatchEvent in zone2, so in this case, it is confusing that which zone should the handler run into, from the zone.js unified policy perspective, it should be zone1, otherwise in the 1st usecase, the handler should run in the noop zone, but some user may want to see zone2 in some scenario.

I still belive the current policy (run callback in the register zone) make more senses, and maybe in some cases let use can also access both the register zone and the trigger zone will be better.

zone.js unified policy perspective