feat(create-notifier): add createNotifier

[joshuamorony]

This is an initial implementation for the createNotifier feature discussed here: #276

This incorporates some of the feedback in the discussion and we can continue to iterate on the exact API (personally I am happy with it as is but happy to change as well)

Once the exact implementation is settled I will add some docs to this PR (along with some more tests too)

[nx-cloud]

☁️ Nx Cloud Report

CI is running/has finished running commands for commit 8052943. As they complete they will appear below. Click to see the status, the terminal output, and the build insights.

📂 See all runs for this CI Pipeline Execution

---

✅ Successfully ran 3 targets

• nx affected --target=lint --parallel=3
• nx affected --target=test --parallel=3 --ci --code-coverage
• nx affected --target=build --parallel=3 --exclude=docs

---

Sent with 💌 from NxCloud.

[renatoaraujoc]

createNotifier() is fine, but I'd give more context to the name like I mentioned on the discussion, like:

createManualSignalNotifier() or just createSignalNotifier().

Just a matter of preference though, createNotifier() is also fine.

[joshuamorony]

Happy to see what more people think but personally I find createManualSignalNotifier() too verbose - and I suppose if you do prefer being more explicit in the code you could still make the notifier names themselves more verbose e.g: myManualSignalNotifier = createNotifier()

[renatoaraujoc]

Could think about something like, maybe:

const sourceSignal = signal<'FIRST_EMISSION' | number>('FIRST_EMISSION'); // or 'INIT'?

// Then on the notify() updater
return {
  notify: () => {
	  sourceSignal.update((v) => v === 'FIRST_EMISSION' ? 0 : (v+1)); // narrowing ftw :D
  },
  listen: sourceSignal.asReadonly(),
}

// In the effect, if we want to skip the first emission, the code is more readable this way and tells exactly what happened
effect(() => {
  if(myTrigger.listen() === 'FIRST_EMISSION') {
    return;
  }
});

[joshuamorony]

I also prefer the less verbose option here but it's a closer call for me here, in this case if(myTrigger.listen()) is a bit more mysterious. Again happy to wait and see what the general consensus is on this one, I don't mind it but I would probably prefer a slightly different approach. Maybe even having a separate computed signal e.g:

if(myTrigger.listenAfterInit()){
  // do stuff
}

^on second thought, downside of above is that it might seem like you can use it without the if e.g. just using myTrigger.listenAfterInit() - maybe doing an explicit check is the better option if we are going for more verbosity here

[eneajaho]

Love it!