[storage] When default value is null/undefined, storage is typed and the value is an object, it's not correctly serializing the value

[Jonathazn]

Steps to Reproduce

1. Initialize a class property with storage<MyObject | null>(null)
2. Set said class property with a value of type MyObject: this.myObject.set({foo: "bar"});
3. Browser storage will show value as [object Object] and value wont be able to deserialized on page refresh

Expected Behavior

Not only default value but also typed reference is used to check which Serializer should be used to write and read from storage.

Actual Behavior

Incorrect Serializer is used to write and read from storage.

Signality version

0.5.0

Angular version

21.2.6

Browser

Mozilla Firefox

Operating system

macOS

Additional Context

No response

[vs-borodin]

Hi, @Glimpse5153
Two readings of "typed reference" - the generic argument, or the runtime value at write time?

Neither survives the read path: generics are erased, and write-time inference doesn't mirror,
since on read there's only a raw string and a nullish default (a Date and its ISO string both
store as 2026-01-01T00:00:00.000Z). Which did you have in mind?

[Jonathazn]

Hi,

Am I understanding you correctly that the type between <> cannot be used at runtime to define the needed Serializer? So in case of storage<MyObject | null>(null), the fact that storage is typed as MyObject cannot be used to define the Serializer?

In that case, maybe Serializer.object should be the last resort if no Serializer has been manually defined and no 'correct' interpretation of the type can be made?

I'll see if I can test it out myself.

Edit: after checking it myself, it's this line that is the culprit in my case:

if (value === null || value === undefined) { return 'any'; }

It runs before any type checking, because typeof null is object so it would be correct without this case check.

I see two options for this:

1. Remove the check (but you probably have a reason for this check)
2. Run inferSerializerType at runtime so it always has the new value to check against. (This might also cause an 'any' typed storage to always serialize correctly.)

[vs-borodin]

Thanks for digging into the source @Jonathazn. Your diagnosis is spot on: that early return in inferSerializerType is exactly it.

To answer your question about the check first. It isn't there to guard against typeof null === 'object'. It's there because a nullish default carries no information about the shape that will be stored later, so 'any' is the honest "I don't know" answer.

Dropping it would make null fall through to 'object', but undefined would still land on 'any', so the two would start behaving differently for no visible reason. It would also silently change the stored format for every existing storage<string | null>(key, null), from a raw string to a JSON-quoted one, including values already sitting in users' localStorage.

[vs-borodin]

On your second option, inferring at write time: it would fix the write path, but not the read path. Producing {"foo":"bar"} is easy once we have the value in hand. On the next page load all we have is a raw string and a nullish default, and there is nothing left to infer from. A Date and its ISO string are indistinguishable once stored, and so are 123 and "123". The signal would come back holding the string '{"foo":"bar"}' while typed as MyObject. So the bug would move from the write path to the read path, where it is harder to notice, rather than disappear. The only way to make runtime inference symmetric is to store a type tag alongside the value, which breaks interop with anything else writing to the same key.

In the meantime, this works today and should unblock you:

readonly myObject = storage<MyObject | null>('key', null, {
  serializer: Serializers.object,
});

[vs-borodin]

This is what we could plan:

v0.5.1: ngDevMode warning when the initial value is nullish and no serializer was passed, naming the key and pointing at Serializers.object. Plus a line in the docs, where the list of inferred types currently says nothing about nullish defaults, and tests, since that case isn't covered at all right now.

Does that sound reasonable to you? And thanks again for the detailed investigation.

[Jonathazn]

I understand the reason why it's hard to implement. I have currently implemented it like you said.

The only thing to do here, is indeed specify to the developer they should specify the Serializer if default value is null or undefined.

This issue can be closed for me. Thank you!