Porting beet_flow to 0.17 Observer Overhaul

[mrchantey]

The Awesome

I've come round to the EntityEvent api in most parts of beet, thanks @Diddykonga i think you're right its best not to think of the Event type literally as a 'payload', reflecting on the lovely flat nature of html events helped with this as well.

My pattern for non-default types is getting new to return a FnOnce.

#[derive(EntityEvent)]
pub struct MyEvent {
  entity: Entity,
  pub value: String,
}

impl MyEvent {
  pub fn new(value: String) -> impl FnOnce(Entity) -> Self {
    move |entity| Self { entity, value }
  }
}

commands
  .entity(entity)
  .trigger(MyEvent::new("foo"));

The Tricky

There are some cases that EntityEvent just wasn't able to fit, for example the behavior tree Outcome type is beautifully simple and my attempts to shoehorn it in resulted in an obscure mess for triggers, consumers and cases where the event needs to be stored for later triggering (target not yet known).
I tried a generic EntityEvent container with an Outcome payload but that results in a mismatch between the trigger and consumer type, so instead ive implemented the discussed EntityTargetTrigger pattern.

#[derive(ActionEvent)]
enum Outcome{
  Pass,
  Fail
}

commands
  .entity(entity)
  .observe_any(|outcome: On<Outcome>|{..})
  .trigger_action(Outcome::Pass);

I'm a big fan of the Trigger api its super powerful, the challenge is that entity-specific usage requires extension methods for commands, world and anywhere EntityEvent is being handled which feels like going against the grain of the intended api.

Maybe too early to say at this point but the implementation got me wondering if this kind of custom entity-specific event could be more officially supported, ie commands.observe and commands.trigger could accept a more general IntoEntityTargetEvent<M> or something.

trait IntoEntityTargetEvent<M>{
  type Event: Event;
  type Trigger: Trigger;
  
  fn into_entity_target_event(self, entity: Entity) -> (Self::Event, Self::Trigger);
}

// what id like to do
commands
  .entity(entity)
  .observe(|outcome: On<Outcome>|{..})
  .trigger(Outcome::Pass);
``

[alice-i-cecile]

You might be interested in #21408

[alice-i-cecile]

Did you see the API added in #21284 at the last minute? This feels like it's very close to what you're asking for, but perhaps I'm missing something?

[mrchantey]

hmm closely related i think the difference is the pr allows EntityEvent to be more flexible in how it stores the event_target, and what im doing is storing the event_target in the Trigger, and the Event stores nothing at all.

[mrchantey]

lol whoops that response was to #21408 but yes similar in spirit, ergonomics around EntityEvent vs other approaches to storing the event_target