This makes it possible to batch effects, where we can "reopen" consumers during initial render and then finalize them after we are finally done adding all the effects to a batch:

// pseudo-code
function createBatch() {
  const effect = // ... create effect node
  resetConsumerBeforeComputation(effect);
  return effect;
}

function appendEffect(effectBatch, updater) {
  if (value is a signal) {
    const prevConsumer = setActiveConsumer(effectBatch.node);
    const output = value();
    setActiveConsumer(prevConsumer);
    effectBatch.push({ signal, updater });
    return output;
  }
}

function finalizeBatch(effectBatch) {
  if (effectBatch.length > 0) {
    consumerAfterComputationInternal(effectBatch.node);
  }
}

const effectBatch = createBatchEffectNode();
appendEffect(signal1, (newValue) => /* something */);
appendEffect(signal2, (newValue) => /* something different */);
finalizeBatch(effectBatch);

I didn't know what to call the new function, so I just called it consumerAfterComputationInternal, which I think should discourage its usage, but I'm definitely open to a better name.

PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our guidelines: https://github.com/angular/angular/blob/main/contributing-docs/commit-message-guidelines.md
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

• Bugfix
• Feature
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Build related changes
• CI related changes
• Documentation content changes
• angular.dev application / infrastructure changes
• Other... Please describe:

What is the current behavior?

consumerAfterComputation resets the active consumer to the previous consumer and finalizes the current consumer.

It is currently impossible to finalize the current consumer without resetting the previous consumer.

Issue Number: N/A

What is the new behavior?

Split out the finalization code so that you can finalize a consumer separately from resetting the consumer. This is useful for batching APIs where we subscribe multiple signals to a consumer in different code paths before finalizing it.

Does this PR introduce a breaking change?

• Yes
• No

Other information

This is a refactor of consumerAfterComputation which splits it into two functions to allow a batching API. It is technically an API change though, since it's introducing a new function. Does that still count as refactor?