Allow for unimplemented actions/services/guards

[mattpocock]

Sometimes, actions/services/guards are best implemented not in the initial definition of the machine. Sometimes, it's best to leave them unimplemented until you use the machine in your frontend/backend code.

This means that Lucy would need to compile action definitions that aren't imported via use.

[matthewp]

Is there an example of what this would compile to? I haven't seen a XState machine like this I don't think.

[mattpocock]

const machine = createMachine({
  entry: ['helloWorld'],
});

In normal XState, you don't need to define every action that the machine describes. This is an important tool for leaving the implementation up to the 'consumer' of the machine, and I use it all the time

[matthewp]

Ah and then you define those by extending? Makes sense, think I can add this.

[mattpocock]

Yeah you can define these when you interpret the machine or run useMachine/useInterpret on it

[matthewp]

I really like this idea. It overcomes one of the awkward things about Lucy at the moment, the interface between Lucy and JavaScript. This idea sidesteps the issue by making Lucy files purely descriptive. I'm wondering if we should maybe even encourage this pattern over importing JS. Will see how it looks once it's done.

[mattpocock]

@matthewp I 100% agree. I also think Lucy would benefit from not exporting a machine, but exporting a createMachine function. I.e:

import createToggleMachine from './toggle.lucy';

interface Context {}

type Event = { type: "EVENT" }

const machine = createToggleMachine<Context, Event>({ actions: {}, services: {} });

This is both more flexible in terms of Typescript (allows for generics) and provides first-class typings for actions/services/guards etc.

EDIT:

And also could make Lucy's syntax a lot simpler by removing/discouraging the use of 'use'.

[matthewp]

@oliverturner curious to hear your thoughts on this, if you have any.

[matthewp]

@mattpocock Can you open a separate issue to discuss your idea for changing what gets exported? I'm intrigued by the idea but want to keep this one focused on allowing unimplemented named guards and actions.

[matthewp]

For this issue I'm going to allow you to define a named guard or action without assigning a value like so:

action log
guard isValidCard

state idle {
  purchase => isValidCard => log => purchasing
}

state purchasing {}

In #34 we can talk about what an inline form would look like.

[mattpocock]

Perfeito

[reaktivo]

For this issue I'm going to allow you to define a named guard or action without assigning a value like so:

action log
guard isValidCard

state idle {
  purchase => isValidCard => log => purchasing
}

state purchasing {}

In #34 we can talk about what an inline form would look like.

This is great, I was just about to open an issue for a feature request allowing actions and guards to be injected, instead of imported and this solves the issue neatly

[matthewp]

@reaktivo you might want to look at #34 where this is better explained. Essentially we are changing machine signatures to be a function that takes in actions/guards, etc. and returns a StateMachine. The :name syntax signifies something that needs to be passed in. So the above example could be either:

action log = :log
guard isValidCard = :isValidCard

state idle {
  purchase => isValidCard => log => purchasing
}

state purchasing {}

Or with an inline form:

state idle {
  purchase => guard(:isValidCard) => action(:log) => purchasing
}

state purchasing {}

[matthewp]

Closed by #41 41