feat(reactive-on): extend usages of the reactive on utility

[JeanMeche]

You can now use it with computer & afterRenderEffect

[nx-cloud]

View your CI Pipeline Execution ↗ for commit bd62c38

Command	Status	Duration	Result
nx affected --target=build --parallel=3 --exclu...	✅ Succeeded	<1s	View ↗
nx affected --target=test --parallel=3 --exclud...	✅ Succeeded	4s	View ↗
nx affected --target=lint --parallel=3	✅ Succeeded	40s	View ↗
nx-cloud record -- nx format:check	✅ Succeeded	1s	View ↗

---

☁️ Nx Cloud last updated this comment at 2026-05-24 18:04:07 UTC

[gemini-code-assist]

Code Review

This pull request updates the on utility to support computed and afterRenderEffect by returning computation results and making the cleanup function optional. It also adds relevant tests. Feedback focuses on restoring JSDoc documentation and maintaining type safety by using unknown instead of any for internal variables.

[gemini-code-assist]

The previous JSDoc included a helpful example and an explanation of how on works (by using untracked internally). Removing these details makes the utility harder to understand for new users. It would be beneficial to keep the explanation and update the example to include the new supported use cases like computed.

/**
 * Makes dependencies of a computation explicit.
 *
 * Works with `effect`, `computed`, and `afterRenderEffect`.
 *
 * @example
 * ```typescript
 * effect(on(a, (v) => console.log(v, b())));
 *
 * // is equivalent to:
 * effect(() => {
 *   const v = a();
 *   untracked(() => console.log(v, b()));
 * });
 *
 * // also works with computed:
 * const doubled = computed(on(count, (val) => val * 2));
 * ```
 */

[gemini-code-assist]

Changing these variables from unknown to any reduces type safety within the implementation. Since fn is called with these values and its implementation signature accepts any, unknown is perfectly compatible and safer. It's recommended to stick with unknown as it was before.

	let prevInput: unknown;
	let prevValue: unknown;

[gemini-code-assist]

Using any for the input variable is less safe than unknown. Since input is assigned from various sources and then passed to fn, unknown is a better fit for internal type safety.

		let input: unknown;

[nartc]

gemini suggestion seems legit. JSDoc comment with examples is helpful.

didn't realize it was still draft

[JeanMeche]

Thinking more about it, I don't think we should implicitly invoke the signals.