Bug: fromObservable emits undefined as first value about xstate HOT 3 CLOSED

This is expected behavior because the actor needs to be in some initial state when it is started. In the observable actor's case, the initial state is that nothing was produced yet from the actor, which is represented by snapshot.context === undefined.

Also, if you were to read the snapshot of the actor before it produced anything, then you would expect undefined.

If you weren't using XState, this would be analogous to this:

let currentValue = undefined; // we don't know what the first value is!

interval$.subscribe(val => {
  currentValue = val;
});

currentValue; // undefined

from xstate.

The problem is that observables are conceptually async; even if the first value comes back immediately, you must treat it as async. If observables had a notion of a synchronous initial value, we could use that (e.g. some sort of obs$.getInitialValue(), but this is not a concept in observables.

A potential idea may be to add something like this to XState:

// PSEUDOCODE
const logic = fromObservable(() => interval$, { startWith: 0 });

I'll continue to think about this.

from xstate.

Thanks for the explanation.
So if I understand correctly, there is no way to have a different initial value given an approach with setup function.

setup({
  actors: {
    intervals: fromObservable(() => interval(1000)),
  },
}).createMachine({
  invoke: {
    src: 'intervals',
    onSnapshot: [], // undefined will always be initial value and there has to be a runtime check
  },
});

Can see the confirmation to this in type definitions:

export type ObservableSnapshot<TContext, TInput extends NonReducibleUnknown> = Snapshot<undefined> & {
    context: TContext | undefined;
    input: TInput | undefined;
    _subscription: Subscription | undefined;
};

I'm probably stating the obvious. Just thought I missed something in docs and there was a way to not have a runtime check for undefined in onSnapshot handlers.

from xstate.