Allow for unimplemented actions/services/guards about liblucy HOT 13 CLOSED

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.

from liblucy.

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

from liblucy.

@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'.

from liblucy.

@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.

from liblucy.

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

from liblucy.

@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 {}

from liblucy.

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

from liblucy.

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

from liblucy.

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

from liblucy.

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.

from liblucy.

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

from liblucy.

Perfeito

from liblucy.

Closed by #41 41

from liblucy.