Event about stochastic HOT 10 CLOSED

I was thinking we could borrow the mixin trick from shapes here.

export class FlightCreated extends Event("FlightCreated", object(...)) {}

new FlightCreated({ ... })

from stochastic.

Let's discuss this item next time we meet. I'll try and provide a write up of the DX I'm thinking about

from stochastic.

This seems like too much boiler plate. Need helpers for defining and creating events. Not sure what the exact DX should be though. I guess it would be nice to have a create(type, {...}) helper for instances. Could not new Event() take the structure of payload and save a step?

const FlightCreated = 
    object({ 
      id: string(),
      time: string(),      
      type: literal("FlightCreated"), 
      payload: object({
        flightNo: string(),
        aircraftType: string(),
        origin: string(),
        destination: string()
      })
    })
const FlightCreatedEvent = new Event("FlightCreated", FlightCreated);

//... and then to return an actual event
{
  id: KSUID.randomSync().string,
  time: new Date().toISOString(),
  type: "FlightCreated",
  payload: {
    ...command,
  },
},

from stochastic.

Mixins could work, provided people understand they should not be further extended. I kinda wonder if we should just provide a function that returns the class without having to extend the mixin Function. Is there something special about class ... extends MixinFunc that couldn't be done with const FlightCreated = Event("FlightCreated", object(...))?

How do we avoid confusing the thing that is an Event (in the graph), with an instance of an Event (data), with a helper function for creating instances? The DX here is not obvious to me. I apologize if I'm not making a lot of sense here. I'm finding it difficult to express my instincts.

from stochastic.

The function returns a Class, whether the developer extends that or not is up to them. An instance of that class is an event value. I think extending it makes sense to extend it since then you have a type for the event data.

class MyEvent extends Event(..) {}

type MyEventSchema = typeof MyEvent // equiv. in Java would be MyEvent.class

type MyEventData = MyEvent

from stochastic.

Should we be using type or kind to discriminate at runtime?

from stochastic.

Maybe we should borrow from graphql, __typename.

from stochastic.

I'm not opposed to __typename I want whatever will be the least confusing and most obvious. Since GraphQL shares it could that complicate things for developers at some point if they bolt GraphQL onto the front of a stochastic app and begin passing Events around or fetching from Read Models?

🤔

from stochastic.

We made some significant progress in https://github.com/stochastic/stochastic/pull/31

Still some TODOS:

• Re-visit the payload boiler-plate in DomainEvent
• fields that are optional or defaulted are not reflected as optional in the constructor.

from stochastic.

• fields that are optional or defaulted are not reflected as optional in the constructor.

Created #37 Shapes: Shape fields that are optional or defaulted are not reflected as optional in the constructor to track this

from stochastic.