DEV Community: Tomasz Ducin

There are no simply "hot" Observables in RxJS

Tomasz Ducin — Thu, 01 Feb 2024 12:47:13 +0000

So I caught your attention? 😈 Good! Because I want you to look at the "HOT and COLD" Observables concept from a different perspective... it's one of the most confusing oversimplifications I've had to deconstruct over and over again since quite a long time.

Okay, to be fair... it is quite useful when we introduce RxJS to a complete beginner. But as soon as they dive into real project usecases, e.g. late subscription of a newly rendered component that subscribes to a (behavior? replay?) subject which had already emitted something - then the "hot and cold" concept is... harmful.

The following aphorism illustrates it quite well:

All models are wrong, but some are useful.

However, I would add: useful, but until a certain point!

👉 read original post and find more interesting content on my website

Common ground

Before we move on let's make sure we're all on the same page. What is a hot observable? The Rxjs.dev official docs define it the following way:

An observable is "hot", when its producer was created outside of the context of the subscribe action. [...]

Some people

⚠️ BTW there seems to be some belief 😏 as if hot Observables are those Observables which "emit infinite amount of values". That's pure nonsense.

False dichotomy

The "problem" with the "hot and cold" concept is that it implicitly suggests that there are two types of Observables. Only two. And yes, when you read the explanations (like this legendary one by Thoughtram), you know that reality is more complex 🙂 but when I join a team in order to do some frontend consultancy services (or run a Angular/Rx training), developers most often think in either-or. Either hot or cold.

I hope you are one of those truly passionate devs who dig into things, dive really deep, seek for understanding. You might already know that there are dozens of completely different types of "hot". But the majority of the industry isn't like this. We're all responsible for the concepts and metaphors we introduce.

So it depends on how we count these things... but as much as we dive into Rx internals, we'd find out there are at least 32 different types of hot streams.

at least 32 different types of hot Observables? 😲

Yep, you heard it right. In very short, 32 is a Cartesian product of:

4 types of subjects (4)
reset on error, boolean (2)
reset on complete, boolean (2)
reset on ref count 0, boolean (2)

4*2*2*2 = 32

If we'd also take connectable streams into account (as in Understanding publish, refCount and connect), there'd be even more 😈.

Sh*t, what are all those things?! 😐

These are separate characteristics of Subjects that have existed for a very long time already - and most probably you experienced them in some rather unclear circumstances, and haven't become aware of what's going on. For example, you might have noticed that, even though the reference counter (number of active subscribers) have dropped to zero, share() used to recreate the underlying stream (e.g. a new HTTP request) whenever a new active subscription happened. But after replacing the share() operator with shareReplay(), it didn't!. Even though the circumstances were the same... And this is NOT a specificity of either Subject or ReplaySubject. This is what so called "hot" is underneath. One term is just so wrong, if you want to get your head around it!

What? Please, stop 😥

No worries, by the end you'd understand all of that. Stay with me. And I hope you'd see that, indeed, "hot and cold" is a seriously harmful oversimplification.

First things first

We need to remind a couple of facts.

Fact 1: Notification Types

Observable streams don't just emit values. Strictly speaking, there are 3 types of notifications:

next(value)
error(error)
complete() and all operators, subjects, etc - everything in Rx processes all of them. Sometimes they just pass the notification through down to the downstream, sometimes they do more interesting things - but all 3 notifications are always involved.

Fact 2: Unicasting and Multicasting

All streams can typically serve only one consumer - all operators, higher-order streams, etc. Being able to emit notifications only to one target is called Unicasting.

... all, except for Subjects - these are the only ones which can serve multiple consumers (and it's actually the main point why they exist...). This "ability" is called Multicasting.

Fact 3: observables are lazy by default

It's a quite well known fact that, until an observable gets subscribed to, it doesn't emit a value. That's fair, since why producing items, if there'd be no one to consume them? Only when they're is some subscriber interested in the data, it makes sense to produce and emit the notifications.

Yep, produce...

Fact 4: producer-consumer pattern

Let's take a look at the following stream:

second$ = interval(1000).pipe(
  map(x => x+1)
);

With no subscribers, the observable emits no events. But once the first subscriber arrives, a new interval (native setInterval) gets created. However, when another subscriber arrives, there'd be a separate, competing interval.

Certainly, observables are clearly lazy in this case. But what I also want to highlight is that a stream like this one:

second$ = interval(1000).pipe(
  map(x => x+1)
);

isn't actually something which is capable of emitting anything. NOT YET...

Now, be cautious. The difference is not only with naming, but also with semantics.

An observable - is something we can observe (subscribe to). Clear.

However, a stream is something that emits values. Now let's get back to the point in time when we had no subscribers: any interval hasn't been created YET. So we've got composition, we've got a stream - but it's dead. There's nothing live that could actually turn the stream on.

Streams do implement the producer-consumer model. Depending on the scenario, there might be either 1 producer per 1 subscriber (cold), or 1 producer per multiple subscribers (at least 32 types of hot). There could be even more complex, though very rare scenarios, where multiple producers use a common subject (sink, proxy) which then passed all notifications through to all subscribers (many-to-many).

A producer could be anything that is the source that start emitting anything: or could be an interval or a timer, but also HTTP request, event listener, or a websocket connection.

Fact Summary

So a subject is multicasting events down to multiple subscribers. In a typical scenario there's one shared producer underneath (could be more, but that's rare).

Without any subject, the stream will unicast. For each subscriber, a new producer would be created instantly.

Back to 🔥 hot 32 🔥

So far so good, we've got the knowledge to champion all the possibilities.

All these apply to situations where we do have a subject ("hot", after all).

reset on error

If any of the producers emits an ERROR notification down to the subject - should it reset? Reconnect? Or - in our terminology - should a new producer be recreated?

reset on complete

Similar as above, but applies to COMPLETE notification.

reset on ref count zero

Imagine the subject initially had no subscribers. Then first subscriber came, then the second one. The subject counts all active subscribers all the time. Now, the subscribers go away, and as they unsubscribe, the counter (ref count) goes down.

And the question arises: if the refCount drops to zero (no active subscribers), should we keep the connection to the producer active? In other words - shall we keep the producer live?

Remember, of the producer is live, it will keep on emitting items according to its nature (e.g. interval will keep on doing its job).

Where did you get these from?

Now comes my favorite part 😁 - source code: let's dive into RxJS ShareReplay sources. This one is especially good to look at, add it specifies config parameters exposed by the share operator:

shareReplay is just a specialized version of share. Apart from accepting config (as input parameters) and preparing the new config (to be passed to share) - apart from that, shareReplay() just calls share().

connector is a function that returns a subject - with whatever type, potentially even having some subscribers already (not common, though possible).

And the resetOnError, resetOnComplete and resetOnCountZero are things we've already gone through 🙃All in all, we can determine all these.

How important is reading the source code?

Sometimes not that much. But this time - extremely important! Imagine all these situations where you use share()/shareReplay() and you hope it should be ok. NO! Think about all these usecases, such as switching routes (navigation), potentially causing refCount zero for a short while. Or receiving complete which might unintentionally break your app logic.

How hot 🔥 are your streams?

Being hot is about multicasting (sharing the connection with the producer or, in practice, sharing the producer). But I hope your agree with me that the following scenarios:

sharing the same producer no matter what
and/or sharing the producer unless RESET emitted
and/or sharing the producer unless COMPLETE emitted
and/or sharing unless all subscribers are gone

... all have completely different runtime behavior. Failing to acknowledge the difference might lead to serious bugs and/or unintentional behavior.

One more case

As previously said, there are more than 32 different types of "hotness". How come? We already mentioned connectable observables. But there's one more, slightly exotic, though technically doable. And that is: an observable that gets the values from a producer who has been created totally outside of the context of any observables whatsoever. Imagine just a producer which, whenever creating a new thing, it calls a function - it will keep on doing that no matter if any observables and/or subscribers are there or not. If a new subscriber arrives, the void function just gets replaced (or added, depending on the implementation) to feed the subscriber. Anyway, the lifespan of the producer doesn't depend on subscribers and, especially, producer is not created within the subscription context.

That's just an exotic example, but all in all, don't stick to the 32 number. Remember that there are dozens of different flavors of "hotness".

Conclusion

The terms unicasting/multicasting precisely define whether a subject is being used or not. Only this is already way more precise than "cold and hot" distinction.

A cold stream is a lazy, unicasted stream which creates a new producer per each subscriber.

But when it comes to hot streams, they could be lazy or not (remember Connectable), they could share the producer unless some circumstances happen. Last but not least, different subject types apply completely different emission strategies. It's all so damn different that it's pure madness to throw it all into one bag. One bag that discourages many people from diving deeper.

So now, whenever you need to introduce a Subject, don't just choose between share() and shareReplay (also trying to figure out why is there no shareBehavior() one?!). Think about all 32 conditions - one of those is the one you're looking for, e.g

stream$.pipe(
  share({
    connector: new BehaviorSubject("INITIAL"),
    resetOnError: true,
    resetOnComplete: false,
    resetOnRefCountZero: false,
  })
)

And when we revisit the official definition of a "hot observable":

An observable is "hot", when its producer was created outside of the context of the subscribe action. [...]

the definition determines neither the behavior nor the lifespan of the producer, which make a huge difference.

My strong recommendation: as soon as one has grasped the idea of Observables, use more precise terms and stop using the ambiguous "hot" (and cold) streams metaphor. It introduces false dichotomy and pretends that things are simple.

The more we know, the more we understand they aren't.

I want to give special thanks to Jan-Niklas Wortmann and Bartosz Cytrowski for proof reading this article 💪

Follow me on twitter for more frontend (js, ts, react, angular etc.) deep dives!

Should .ng component authoring format get dropped? 😱

Tomasz Ducin — Fri, 26 Jan 2024 10:12:48 +0000

There's been quite some fire around the .ng component authoring format, introduced as experimental in AnalogJS meta-framework. You can listen more about it here:

// Detect dark theme var iframe = document.getElementById('tweet-1750239037737304205-768'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1750239037737304205&theme=dark" }

TL;DR; the community seems pretty divided. I don't want to state my opinion here, and I'm last to judge. But the fact is: a lot of hard work has been put into the experiment and, due to some controversies, the AnalogJS team is planning to drop the support entirely.

Do you think it's a good idea?

Vote in the poll

// Detect dark theme var iframe = document.getElementById('tweet-1750816798109220975-790'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1750816798109220975&theme=dark" }

and leave a comment under the PR. Thanks!

Signals are VALUES, not EVENTS

Tomasz Ducin — Thu, 18 Jan 2024 22:35:00 +0000

Recent release of Angular 17.1 (yesterday, 18th January 2024), introduces Signal Inputs (read more about Angular Signal Input API here):

// Detect dark theme var iframe = document.getElementById('tweet-1740305588280574153-559'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1740305588280574153&theme=dark" }

It's a good opportunity to rethink migrating from RxJS to Signals, as more and more APIs are signal-based: the framework (signals, computeds, effects and the rxjs-interop) and ecosystem (NGRX signal store), as well as tons of experiments (such as this one).

Photo by Alina Grubnyak on Unsplash

// Detect dark theme var iframe = document.getElementById('tweet-1747952979326423309-352'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1747952979326423309&theme=dark" }

The amount of positive reception of above tweet made me realize this topic needs more attention among the Angular community.

On one hand, we've all heard that signals won't entirely replace RxJS (especially that Angular is on the road to make RxJS optional in the future). On the other hand, the new reactive primitive is taking the ecosystem by storm and, no wonder, it's easy to lose touch with the design principles and start overusing signals everywhere. Just like redux used to be abused at some point. Or like Observable Streams used to be abused. Are we gonna share Georg Hegel's view, that:

"We learn from history that we don't learn from history."

// Detect dark theme var iframe = document.getElementById('tweet-1748083824238485544-508'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1748083824238485544&theme=dark" }

okay no more my tweets 😇

Micro disclaimer

I enjoy using signals, I enjoy using rxjs observables - so I'm no pro/against in any way. Also I enjoy using MobX (doesn't MobX API look familiar to you? 🙃), I enjoy bacon... I enjoy pretty much all the tools that help me get my job done. My intention in this post to emphasize, again, that every tool has it's certain usecases. And that excitement is the worst factor that could drive decision making in software development. Cool down 🥶

Facts

Let's start with revisiting the fundamental characteristics of signals and observable streams (they're mostly well known, so I'll just list them down):

sync/async
- observables can do both sync and async processing
- current signals implementation is capable of sync processing only
- as a consequence, signals are unaware of the passage of time
some APIs will always be async no matter what we prefer or believe in ¯\_(ツ)_/¯, such as HTTP or browser events
- replacing decorated @Output() with signal-based output() (not yet in v17.1) will be purely syntactic sugar, as events will be emitted underneath nevertheless
- squashing async processing into sync signals generates some non-trivial questions
subscriptions
- RxJS requires manual (un)subscription handling
- signals handle (un)subscription 100% automatically
late subscriptions
- both APIs handle late subscriptions
values/emissions
- signal always has a value (like in BehaviorSubject)
- observable streams might have values, but streams with no emissions whatsoever are absolutely valid(-------> - no next, no error, no complete, nothing)
re-implementing RxJS features as signals one by one (like operators, subjects etc.) makes barely any sense
API
- RxJS has ~100 operators, 4 subject types, 32 types of hot observables (expect a blogpost soon! 🔥), all unicasting/multicasting concepts, etc.
- signals have barely ~10 functions (signal, set, update, computed, effect, untracked, asReadonly, toSignal, toObservable, perhaps something more). Order of magnitude difference...

Readability

I'll be honest - when people say they find something readable or not... or easy... or simple... I tell you: I don't care much 😉 people often forget that we have different background and experience. That readability has no way to be measured, and is purely 100% subjective. Like, my mother tongue is Polish and, surprise surprise, I can understand quite a lot from other Slavic languages. So what? So nothing. It would be strange if I didn't 🤷.

And same here. I love signals from the first day. But that's mainly because I have commercial experience in MobX which is, conceptually, 1:1. For every person, a thing being readable or not is ultimately subjective and - my tiny recommendation here: don't pay too much attention to readability. Unless you like bikeshedding.

Missing piece of understanding

Alex has once described signals the following way:

A signal is a source of value.

That makes perfect sense. However, if I asked you the following question:

What a signal is NOT? What shall NOT be represented as a signal?

What would be your answer?

Coding itself is rather simple, but software design is not. If we pick a wrong abstraction and keep on implementing things on top of it, then despite that our code might work as expected, we'd see things are unnecessarily harder than they should be. Within time we'd start fighting our code and design, more and more, and feel the need to refactor/rewrite some piece of an app.

So what a signal is NOT? I suggest one of the following:

something that doesn't have a current value, e.g. user events, browser events
something that has a current value, but it's completely irrelevant, an action that a user wants to reload a data-table

So I want to draw a boundary between VALUES and EVENTS.

All in all, I would rephrase the definition to:

A signal is a source of value, but NOT a source of events.

Values are some DETAILS, characteristics that a thing can have

We can always ask (pull-based) what the value is. We can also be notified about a value which has changed (push-based). That's why RxJS is a valid abstraction around pretty much everything that exists 😉. But still, if something has a value, you can always ask for it.

Events describe what has already HAPPENED or what will happen

The events, on the other hand, are meant to notify (push-based) others about something that happened. There is an important distinction between events (something has happened already) and commands (something will happen and we pass a command to be executed) but it's a topic for another post.

The distinction between VALUES and EVENTS is very clearly expressed in the original redux store API:

store.getState(): STATE // pull-based value accessor
store.subscribe(FN): void // push-based value accessor
store.dispatch(ACTION): void // push-based event notification

Couldn't events be values or vice versa?

Someone might deny:

Hey, but events are objects, they might have payloads, and what is a payload if not a value?! (object, primitive, whatever)

Sure. Technically - yes, absolutely. But, taken to extreme, everything is a value. Even your mouse cursor's coordinate is a value. But when we do design, we want to create mental models that are pragmatic, help us put things in order, and make other devs comfortable within the design that we leave. Taking things to extreme doesn't help.

It all depends on the terminology we use and the context of our reasoning, so - could events be values - both yes and both no.

My strong recommendation is to focus on what is the intention of how are we going to use a thing:

are we going to access details of something (value)? or
do we get notified that something has happened (or will happen)?

Community-driven signals APIs

There would certainly be more and more signal-based APIs. It's worthwhile to consider which of the make sense and which don't. Mike sums it up perfectly:

// Detect dark theme var iframe = document.getElementById('tweet-1748076923631059433-709'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1748076923631059433&theme=dark" }

Example: interval

I want to focus on just ONE example, but do it very deep. In the react world (where I come from 😜) one of the mindshifting blogposts is Dan Abramov's Making setInterval Declarative with React Hooks. I decided to pick setInterval as well.

So, could you make an async interval signal? Technically, yes, of course:

function intervalSignal(interval){
  const idx = signal(0)
  const id = setInterval(() => {
    idx.update(value => value + 1)
  }, interval)
  return idx
}

But should you? No. Totally No.

Why? Because, although technically we could easily make things work, we're mixing abstractions badly. Mixing abstractions will always have some shortcomings. What are these?

Missing support

We're also missing support for potentially important aspects. I hope many of you already thought: why aren't you cleaning up the signal?! Great, so here we go:

function intervalSignal(interval){
  const idx = signal(0)
  const id = setInterval(() => {
    idx.update(value => value + 1)
  }, interval)
  return {
    cleanup(){ clearInterval(id) },
    signal: idx
  }
}

but hey, our implementation more complex and, as a consequence, longer.

Fixes. Fixes everywhere.

Have you noticed, that if we expose a WritableSignal (signal still includes the .set) method, then we're leaking encapsulation - probably overwriting the current tick shouldn't be possible from outside of the signal. So, instead, it should be:

  ...
  return {
    cleanup(){ clearInterval(id) },
    signal: idx.asReadonly()
  }

But, trust me, we haven't exhausted all edge cases yet 😈

Signal Interval is pretending to be time-aware

In the last version of the signal (interval + cleanup + asReadonly) there's still no simple API that allows us to modify the interval (time) length. In RxJS we could simply use a switchMap which consumes the interval upstream:

intervalLength$.pipe(
  switchMap(timeLength => interval(timeLength))
)

Again, could we achieve the similar API with signals? Of course! (but I'm not falling down the rabbit hole 😏). Anyway, as the signal code gets more complex:

we should take potential edge cases into account, right? And most probably we're bikeshedding and it's far away from the business solutions we're expected to work on...

API design

We also need to carefully design APIs (again). Potential breaking changes come into play. Also, how much of your application code should re responsible for platform-related things, like intervals, events, HTTP, etc?

In case of changing the interval length, should we go one more setter callback?

function intervalSignal(interval): {
  signal: Signal<number>
  cleanup: () => void,
  setIntervalTime: (time: number) => void
}

This seems simple, but the signal API has become rather callback-based. Perhaps wrapping interval with a signal would look better to use signals more:

function intervalSignal(interval): {
  valueSignal: Signal<number>
  cleanup: () => void,
  intervalTimeSignal: Signal<number>
}

which one is better?

Wrong Abstractions, AGAIN

There's one important thing we will consider 😄 there might be situations, where we need to process values of the signals and a signal/computed fits here, since it can notify computeds further. But other times, it's fairly enough to make it an effect, as the consumption would be placed within the effect function and there would be no further dependencies (nobody would have to react to the effect taking place. Potentially that could have been a better choice from the beginning...

However, we can't guarantee that effects would be better than signals in all cases.

Conclusion

Can you see, how many problems we're solving, which don't relate to our commercial project? 😐

I hope we all clearly see that: if the problem-solution abstractions don't fit well, better not to implement the solution at all.

What's the conclusion? If a concept is beyond signals (doesn't fit there), like time, or events - don't make signals wrap it.

So, to sum it all up - what is the most important factor that differentiates VALUES from EVENTS? It's TIME. VALUES don't care about time. EVENTS do.

Pay attention to time. As time is running out. ☠️

Follow me on twitter for more frontend (js, ts, react, angular etc.) deep dives!

Angular @defer Interactive Examples

Tomasz Ducin — Thu, 04 Jan 2024 15:12:01 +0000

One of the Angular 17 awesome features shipped is the defer block which allows to lazy load components, directives and pipes, while configuring it on the template level via @defer.

If you already know the theory and want to get your hands dirty with @defer, here's an app you can see various usecases and combinations:

ducin.github.io/angular-defer

See how does application runtime and user interaction trigger @defer and what certain bundles get loaded into the browser.

It includes:

⚡️ components, directives, pipes
⚡️ multiple triggers and their combinations
⚡️ practical usecases (🪗 accordion, 📦 npm package and many more)
⚡️ analyze with devtools
⚡️ explanations included

Usecases implemented:
⚡️ when condition: @defer (when isVisible) {...}
⚡️ on idle: @defer (on idle) {...}
⚡️ on viewport: @defer (on viewport) {...}
⚡️ on interaction: @defer (on interaction) {...}
⚡️ on hover: @defer (on hover) {...}
⚡️ on immediate: @defer (on immediate) {...}
⚡️ on timer: @defer (on timer(2000ms)) {...}
🪗 accordion: @defer (on hover(accordion); on timer(5s)) {...} (before accordion section gets clicked)
👫 multiple deferrable
📦 npm package: <link rel="modulepreload" href="chunk-BYHJVGJ4.js">
🗃️ nested defer: @defer (on timer(2s)) { @defer (on interaction) {...} }
⏱️ prefetch: @defer (on interaction; prefetch on idle) {...}
🚚 loading vs placeholder: placeholder (minimum 500ms) {...} & @loading (minimum 1s; after 10ms) {...}
💥 defer error: @error {...}

So open your browser devtools Network tab and have a play with the interactive examples 💪

Follow me on twitter for more frontend (js, ts, react, angular etc.) deep dives!

Diving into Type System behind Angular Signal Inputs

Tomasz Ducin — Thu, 28 Dec 2023 22:20:41 +0000

Original version of this writing has been published as a twitter thread. However, I was convinced by @eneajaho to convert it into a blogpost 😎. I decided to leave the original form: quick, easy-going and concise.

As you may know, Signal Inputs are coming to Angular in mid January 2024 in version 17.1. But we can actually play with them already, or at least, take a look at their almost public API. In this post we'll take a deep dive into the type design of Signal Inputs internals, its consequences, and a lot of examples of Signal Inputs usage.

Demo code

We're gonna expose what the Angular Team has hidden from us...

🪄 the trick is:

import { ɵinput as input } from '@angular/core';

don't do this at home 😈!

Following stackblitz allows you to see Signal Input declarations. Note that there's no Signal Input implementation within angular as of now (v17.1.0-next.5), so we'll focus on declarations/public API only.

Examples

We'll start with lots of examples. Take a look at the first one:

🔍 initial value is used to infer the input's type, same as with ordinary signals:

⚠️ Input Signals are READONLY, which makes sense, since it's the parent component who can put new values (via templates) into the input signal, not us 😉

One of my favorite design decisions:
💪 taking advantage of (1) #typescript's possibilities and (2) applying best solutions from other frameworks. In this case: from React

💜🩷💜 love it 🩷💜🩷

Less exciting - and IMHO it should be avoided as much as possible (since it decreases readability and the understanding of how components exchange data) - aliasing is allowed:

📡 aliased name is used by parent to pass the data
🔐 the prop name is used internally (obviously)

Another logical design decision:
💪 since an input is REQUIRED, passing initial value makes no sense 😉 so it's removed from the signature

Here the initialValue parameter is removed from the function (overload) signature. Or to be more precise - it's never added (never allowed) to be there 😉

So, technically speaking, TypeScript would try to pass your initial as options object which obviously fails.

And one more example - transform is allowed only when passing both ReadT and WriteT type parameters. More on this later...

Internals

Now let's see 🍖 some internals 🥩

To get a broad overview of the direction, you might be interested in taking a look at the ➡️ Angular Team's Sub-RFC 3: Signal-based Components which deals with, more or less, how to make use of signals in Angular Components. Also, you can ➡️ take a look at the code itself. Anyway, let's dive into the internals!

We've got 2 new signal symbols:

it's the same usecase, as with the former unique Signal symbol - it allows to restrict compatibility across different (input) signals.

For instance:
✅ one can assign the InputSignal<number, number> to an ordinary Signal<number>

Proof:

need to make ordinary signal READONLY so that TS compares 2 readonly signals (input signals are READONLY)
where a string signal is expected, a string input signal is acceptable, since it has all required (needed) properties.
❌ but the other way round it fails, since an ordinary string signal doesn't have the brand read/write signals.

Reassigning signals, however, is not going to be anyhow common 😉. But the Angular compiler also makes use of the symbols internally.

Now, this is where we get the signals API from. There's a completely separate implementation for optional and required inputs. It's just exposed as a convenient API:

s1 = input()
s2 = input.required()

The sad thing, however, is that currently we cannot see its runtime.

(disclaimer: as mentioned above, ng v17.1 is expected very soon, this analysis uses v17.0.1-next.5).

Now let's take a look back at input transform:

However, you might be wondering what the heck is going on with this function overload and the strange declaration at the bottom:

First of all, if we pass <ReadT> only, we can't pass the input transform (that's the same as with current

@Input
({ transform: ... })

However, if we pass both <ReadT, WriteT>, we can additionally pass the transform. Note that:

ReadT is the expression type you want to use inside your component
WriteT is the expression type that is passed from outside

Another example:

Going back to our nice declaration 🥴 let's focus on inputFunction first:

It has 3 overloads on its own:

take no initial value and extend inner value with undefined
take the initial value with ReadT type param only (opts WITHOUT transform)
take the initial value with both ReadT, WriteT type params (opts WITH transform)

All usecases seen before 😎💪

All in all we've got 3 overloads for the prop = input() (optional)
... and 2 overloads for the prop = input.required() (required)

Phew 😅 that was quite a lot. Hope you enjoyed that.

Conclusion

We've seen quite a few examples on how certain usage of input signals affect underlying TypeScript types. Each usage depends on your specific needs in a specific situation. However, you should always pay attention to what types get declared/inferred in each case, as type-safety is one of the most important factors that form overall code quality.

Underlying Signal Input types are very well defined, but it's always your responsibility to verify, whether a given input should be optional or required in the long run. Types should only reflect your design.

Remember you can play with it on this stackblitz. It includes the code of all examples.

Follow me on twitter for more frontend (js, ts, react, angular etc.) deep dives!

DEV Community: Tomasz Ducin

There are no simply "hot" Observables in RxJS

👉 read original post and find more interesting content on my website

Common ground

False dichotomy

at least 32 different types of hot Observables? 😲

Sh*t, what are all those things?! 😐

What? Please, stop 😥

First things first

Fact 1: Notification Types

Fact 2: Unicasting and Multicasting

Fact 3: observables are lazy by default

Fact 4: producer-consumer pattern

Fact Summary

Back to 🔥 hot 32 🔥

reset on error

reset on complete

reset on ref count zero

Where did you get these from?

How important is reading the source code?

How hot 🔥 are your streams?

One more case

Conclusion

I want to give special thanks to Jan-Niklas Wortmann and Bartosz Cytrowski for proof reading this article 💪

Should .ng component authoring format get dropped? 😱

Signals are VALUES, not EVENTS

Micro disclaimer

Facts

Readability

Missing piece of understanding

Values are some DETAILS, characteristics that a thing can have

Events describe what has already HAPPENED or what will happen

Couldn't events be values or vice versa?

Community-driven signals APIs

Example: interval

Missing support

Fixes. Fixes everywhere.

Signal Interval is pretending to be time-aware

API design

Wrong Abstractions, AGAIN

Conclusion

Angular @defer Interactive Examples

ducin.github.io/angular-defer

Diving into Type System behind Angular Signal Inputs

Demo code

ToC

Examples

Internals

Conclusion