Computed values

[davidkpiano]

This RFC proposes adding a computed values feature to XState models via createModel(...):

const model = createModel({
  firstName: 'David',
  lastName: 'K'
}, {
  events: {/* ... */},
  computed: {
    fullName: (ctx) => ctx.firstName + ' ' + ctx.lastName,
    nameLength: (ctx, computed) => computed.fullName.length
  }
});

// Usage
const machine = model.createMachine({
  // ...
  on: {
    SUBMIT: {
      target: 'submitting',
      cond: (ctx) => model.computed(ctx).nameLength < 1000
    }
  }
});

Thoughts? Suggestions?

---

Prior art:

• Computed Properties (Vue)
• Derived values (Mobx-State-Tree)
• Computed values (Mobx)
• Computed values (Easy Peasy)

[johtso]

Is there any way we could achieve the syntactic simplicity of cond: (ctx) => ctx.nameLength < 1000? It's great to be able to not care whether data is "real core data" or something computed. I'm guessing this is impossible / would break everything? Context is just the actual context data structure I suppose so we couldn't do property magic even if we wanted to..

[davidkpiano]

There is a potential for naming conflict with that, and it becomes unclear downstream that you can/can't assign certain properties (not to mention it is much more difficult to strongly type), so I don't think combining computed values with context is worth the effort for a minor DX improvement. Also, compare the two:

-cond: (ctx) => ctx.nameLength < 1000
+cond: (ctx) => computed(ctx).nameLength < 1000

The extra computed(...) makes things more explicit, and isn't much more typing.

[Andarist]

Shouldnt then the nameLength example be written like this?

-    nameLength: (ctx, computed) => computed.fullName.length
+    nameLength: (ctx, computed) => computed(ctx).fullName.length

Using a different access flavor depending on the access location could come up confusing 🤔

[devanshj]

If at all I needed computed properties on my context, I need no xstate for that (hit on run and it's typesafe (duh)) ;)

- context: model.initialContext
+ context: withComputed(model.initialContext, { fullName: c => c.firstName + " " + c.lastName })

much more difficult to strongly type

Oh is it? :P

- (ctx: TContext, event: TEvent) => TContext
+ (ctx: TContext, event: TEvent) => Assignable<TContext>

- { [K in keyof TContext]: (v: TContext[K], e: TEvent) => TContext[K] }
+ { [K in keyof Assignable<TContext>]: (v: TContext[K], e: TEvent) => TContext[K] }

Needless to say this is not productive comment (unless? :P) I'm just messing around

And btw xstate should preferably already have Assignable<TContext> at places so as to respect the readonly modifier (failure of which might even result into runtime errors like say if someone passed context: Object.freeze({ z: 1 }) and wrote assign(() => ({ z: 2 }))) (But actually that's not great as even with Assignable, assign(() => ({ z: undefined })) would pass and it shouldn't, so will have to write Self-Reconstructing types to disallow even the key)

Edit - omg wait "Jul 5"? lmao well didn't realise I'd be resuscitating this discussion haha

[ChrisShank]

Its very cool to see what createModel has enabled!

1. Do you have any concern about overriding actions, guards, ect and potentially not having access to those computed properties?
2. Would there be any caching happening for computed properties based on dependencies?

[johtso]

1. Do you have any concern about overriding actions, guards, ect and potentially not having access to those computed properties?

Why would an overridden action not have access to the computed properties? As long a you import the model you can use the property right? (I may be misunderstanding)

2. Would there be any caching happening for computed properties based on dependencies?

Yeah, without caching, what are we getting here by defining these properties on the model that couldn't be done with simple functions that take a context? fullName(ctx)

[a-y-u-s-h]

Really excited for this. Just curious but can computed properties also be added to Machine itself in the options object along with actions, services, guards, activities like so:

import * as X from "xstate"

export default {
  actions: {},
  computed: {},
  activities: {},
  services: {},
  guards: {}
}

An extra computed property could hold all the key value pairs whose values get recalculated everytime anything inside context changes. Also accessible from the outside as a read-only value. This will look very similar to the pattern that Vue uses. They have data instead of context:

var vm = new Vue({
  el: '#example',
  data: {
    message: 'Hello'
  },
  computed: {
    // a computed getter
    reversedMessage: function () {
      // `this` points to the vm instance
      return this.message.split('').reverse().join('')
    }
  }
})

[davidkpiano]

I think that's an interesting idea 🤔 what do others think?

[johtso]

How does this differ from your initial proposal? Using this? Defining in machine options?

[a-y-u-s-h]

@johtso Right, should have clarified. That's just what Vue does - I just copy pasted their example to demonstrate the similarity between data and computed of Vue with what could be the relationship of context and computed in Xstate. I'm not really a fan of using this here, I like this -

import * as X from "xstate"

export default {
  actions: {},
  computed: {
    fullName: (ctx) => ctx.firstName + ' ' + ctx.lastName,
    nameLength: (ctx, computed) => computed.fullName.length
  },
  activities: {},
  services: {},
  guards: {}
}

where computed is previous value of computed object (not with function values, but the calculated computed object - with returned values).

[K3TH3R]

I really like this format of the computed property on the options object. It has the familiarity of Vue for me, but I think it also nicely groups it within a mental framework for understanding XState. It puts all of the things that can read/modify the context together.

[johtso]

Tangentially related thought..

Might be nice to have a valueGuard or something that could take a string pointing at a context value or a computed value, and use that as the predicate.. for nice visualization.

In some cases that could end up a lot neater than having to have a bunch parallel states for simple things like "has the user selected anything" etc. just to control the behavior of a single action. It would instead be cond: valueGuard('userSelections'), userSelections being a computed property. The visualizer would then be able to display that as if: userSelections.

[davidkpiano]

Seems like this can be done in userland, especially if/when we provide the ability to customize how guards are visualized.

[johtso]

Would it be a good idea for computed(ctx).prop to pass through to the context if a computed property with that name isn't defined?

Then you could just do const comp = computed(ctx) at the top of your action and use it consistently regardless of whether your values are computed or raw.

[davidkpiano]

That's a possibility; we'd just have to type it properly to avoid potential naming conflicts (even if unlikely) and combine the types

[jamesopstad]

Glad to see this being discussed. It prompted me to put down some ideas I had. I've created a new discussion so as not to divert this one - #2399

[parker-codes]

I was looking at the concept of computed values in #2384. I love it - have plenty of use cases for that to further clean up code.

I'm curious if there are any ways to "return" data from a machine. This would make machines more capable of being data stores (in my use cases). Instead of sending an event and then using the context value, I may want to have computed/getter methods to pick what I want. This is different from a selector because it involves additional data and might be used in multiple places at once.

I'll use a contrived example because I can't share business specifics. Let's say I have a store of user profiles. Then I have a comments machine. If I want to display the user's name and profile image next to each of their comments, I need to create a function like:

export function getUser(context, userId) {
  return context.list.find(user => user.id === userId);
}

and then use it:

<Comment :user="getUser(userState.context, comment.userId)" />

My hope would be able to do:

export function getUser(context, userId) {
  return context.list.find(user => user.id === userId);
}
export const usersMachine = createMachine({
  id: 'users',
  // ...
},
{
  computed: {
    byId: (context, /* args */ { userId }) => context.list.find(user => user.id === userId),
  },
});

and then use it like:

<Comment :user="userState.computed.byId(comment.userId)" />

I know an overarching goal of this project (and many others) is to stay lean and not include unnecessary features. This is just what seems like a nice thing to have if this proposal was implemented.

[barbados-clemens]

I wanted to add my two cents as I love the idea of computed properties and how I've been operating at work with the idea of ViewModel and leveraging NgRx ComponentStore

ComponentStore is based around the idea of a Subject in a service, where you'd have a Subject to contain your state for a component and .next() into the state and any subscribers to that state would get notified and do what they need to do with that state. Difference being that ComponentStore provides a "cleaner" API surface, standardize way to work with this data stream, and take away boiler plate.

All of this to say it's really easy to create computed views of your data with the ComponentStore selectors.

For example

interface MyState {
  firstName: string,
  lastName: string,
}

export class MyStore extends ComponentStore<MyState> {
// select "slices" from the stores state
readonly firstName$ = this.select(state => state.firstName)
readonly lastName$ = this.select(state => state.lastName)

// create a computed view model by selecting from streams and projecting it into a new object
readonly viewModel$ = this.select(
                                 this.firstName$,
                                 this.lastName$,
                                 (first, last) => {
                                        return {
                                          fullName: `${first} ${last}`,
                                          username: `${first}.${last}`
                                       }
                              }, {debouce: true}) // let changes "settle" to not emit too frequently helps when you have a "large" view model
  

  constructor() {
    super({firstName: 'barbados', lastName: 'clemens'}) // this is your initial state. 
  }

  readonly setFirstName = this.update<string>((state, value) => ({...state, firstName: value})) // this is like a normal reducer function!

// run side effect like contacting the API or calling other effects
// you can also update the state in an effect with this.patchState({})
  readonly saveChanges = this.effect(trigger$ => trigger$
        .pipe(
            withLatestFrom(this.firstName, this.lastName), // grab from our selectors above
            exhaustMap(([, first, last]) => this.someService.callMyApi({first,last}) // run a side effect
))

The most important part is the selectors here which allow you to grab a slice of your internal state (as an Observable). these selectors will reemit every time the state is updated (note state has to be updated immutably or the streams/angular bindings won't emit/behave as expected)

the state is frozen in the component store so in order to update it you have to run through updaters/effects to patch or replace the entire state object. these updaters/effects can take in a single value like myStore.setFirstName('Caleb') or they can take a stream myStore.saveChanges(someStreamThatEmitsOverTime) and every time that inner stream emits it'll run those methods. I don't think this is important for this conversation, just for completeness.

All of this to say I think

computed: {
 fullName: state => state.context.firstName +  state.context.lastName
}

makes the most sense to me, but if you're only going to use the context to create the computed values, then

context: {
 fullName: createComputed(context => context.firstName + ' ' + context.lastName),
}

could make sense.

@nartc might have more opinions on it as he has worked with ComponentStore and just started toying with XState, and I generally just want to know what they'd think of how using computed properties might look in state.

A walk-through of ComponentStore and its usage patterns can be found from this youtube series.
https://www.youtube.com/watch?v=QFjKdVq7dfo
some demo code here
https://github.com/nartc/panng-stream-demo/tree/main/libs/demo/post/data-access/src/lib/stores

[barbados-clemens]

another thing to consider here is maybe the idea of having "lazy" computed properties that only compute when read.

I've run into cases where I only want this expensive function to run when I need it to at the very end of some operation that modified internal state. i.e. normalizing/de-normalizing large tree structures.
this would prevent an extra step of needing to send some event to say "please run this function now and place in context"
and I wouldn't want to run every time context changes for those properties, only when needed

[nartc]

@barbados-clemens wouldn't "lazy" be the same as a getter? Assuming createComputed has some form of memoization built-in, a "getter" would serve the purpose.

context: {
   get fullName() {
      return createComputed(context => context.firstName + ' ' + context.lastName
   }
}

Back to ComponentStore interoperability with xstate, I'd love to experiment with it. Like a MachineComponentStore that accepts a machine instead of initialState. Would be really interesting to play with.

---

I mean, normally we would wrap a machine with a Service to interpret it already. Why not wrap it with a ComponentStore, right?