Open goce-cz opened 4 years ago
I'd definitely do 1 - 3 , but I'm not entirely sure about 4.
I'd also be in favor of 1-3. I feel like Javascript undefined
(i.e. no value assigned) is a better fit for the scenario than null
(i.e. "empty" value assigned).
In terms of 4, I'm not sure I'm qualified to comment... it would depend a fair bit on where useSnapshot
(and the other affected hooks) are used and how.
One argument for doing no. 4 as well: https://github.com/salsita/configurator-sdk/pull/247#discussion_r503827444
Similar to what @craig-bishell said, I'm not sure how 4
will affect other things, but I think it feels less smelly to do it that way.
In which case, I'm in favor of all of them (1
-4
)
Currently the
useSnapshot
hook returns[null, SnapshotState.WAITING, null]
while waiting for the first emit, unless a default value is specified. Usingnull
as a indicator of a missing value feels a bit weird in this case and has some technical implications as well:const [value = 5] = useSnapshot(observable)
asnull
will override the default. Because of that we need to acceptdefaultValue
as an argument touseSnapshot
.null
emission.undefined
would suffer from the same issue, but who does emitundefined
?Additionally we use
null
for indication of no error and also for a missing state (whenever the source observable is nullish). I feel that if we convert one, we should probably convert all of them.So what do we do?
null
withundefined
forvalue
(the first element of the tuple)null
withundefined
forstate
in case of a missing source observable (the middle element of the tuple)null
withundefined
forerror
(the last element of the tuple)const [value] = useSnapshot(observable, defaultValue)
overload in favor ofconst [value = defaultValue] = useSnapshot(observable)
Note that any of these changes will also affect
usePartialSnapshot
anduseAsyncMemo
.