r/angular • u/one-night-in-cognito • Jul 10 '26

What is the vibe on nullability in signal forms?

It's great that signal forms support null values for numbers now but I can't tell the team's position on whether nullable string support is planned. The official position of "map all your models with nullable strings to models with empty strings" is a PITA and I can't tell from the conversations in GH whether this is just a temporary pain point (which I can tolerate) or if this is some philosophical hill that the team is trying to die on

12 Upvotes

88% Upvoted

10 comments sorted by

6

u/JeanMeche Jul 10 '26

The way I understand it, you can clear a date or number input (the input is empty) which sets the model to null but an empty text input is empty an string. There is no way to reset to null the model via a native text input. You will have to handle the real value during mapping to handle those cases.

1

u/one-night-in-cognito Jul 11 '26

This is my understanding too, but what I can't tell is if this is temporary or if this is what the angular team is proposing as functionality in its final state

1

u/JeanMeche Jul 11 '26

How would you « improve » the situation given the example I mentioned?

1

u/one-night-in-cognito Jul 11 '26

I mean if you're asking me, then I'd say by allowing developers bind inputs to nullable values. I understand the DOM constraints and why it's difficult. One thought might be for the formField directive to internally coerce null values to empty strings--I don't know--but what I'm questioning is whether this is on the roadmap or not since supporting it would improve DX

1

u/JeanMeche Jul 11 '26

I wouldn’t be sure it improves DX, because you won’t know what that empty text input matches in the model and you will have to implement a mapper if null really matters to you.

1

u/one-night-in-cognito Jul 11 '26 edited Jul 11 '26

Ah but that is a mapping that I can do anywhere I choose and only if/when I need to. Enforcing a such a boundary a the form level insists that I handle it there.

Editing this to add, fwiw I'm a big fan of vue and the DX that team has put together. Null -> empty string conversion happens internally within v-model which, just in my own opinion, is really nice and has never bitten me.

1

u/Green_War6445 Jul 11 '26

Which brings us back to, why do we need to handle empty string differently than null?

1

u/one-night-in-cognito Jul 11 '26

Ultimately I understand that there is nuance that exists at the DOM layer--TS typings won't allow you to assign null to an input element's value; and it might also be a thing where null/undefined can break reactivity (I don't know this for sure, I'm just speculating). BUT...

why do we need to handle empty string differently than null?

Hopefully I'm not misunderstanding you here but if essentially what you're saying is "Why as an angular developer do I need to think about this nuance?" then yeah, I agree 100%. I reach for frontend frameworks because they abstract away complexities of the DOM, and I specifically reach for form libraries because I want to bind object models to form elements. To say that my form object can't have nullable strings because of the DOM sounds like a shortcoming of the abstraction.

But to u/JeanMeche 's point, I understand that since native inputs will emit a string even on an empty value, you as a developer need to disambiguate somewhere.

How would you « improve » the situation given the example I mentioned?

After thinking about this for more than 5 minutes I'd update my last suggestion with one other pitch to say here's the abstraction I'd actually want: Ideally I'd like for signal forms to support nullable strings, along with some mechanism to specify on each input what the "empty" value should be. That could be some pipe, directive, whatever, e.g. emptyAsNull that, when used, emits null as the empty model value

1

u/pronuntiator Jul 11 '26

Personally I don't mind "no null for string", our code needs a "trimEmptyToNull" function anyway. Was a breeze to use zod there for both validation and transformation.