Should I avoid writing systems with many parameters? If so, what approaches can I use to reduce the number of parameters.

[ghost]

I have noticed a tendency for my systems to accumulate more and more parameters as a project grows. Most of the time, it is not too hard to refactor a system into two or more systems and distribute the parameters between them. This seems like a good thing since it makes the design of the app cleaner.

However, I have come across a situation where I don't know how refactor my system. I have a system that uses bevy_egui to make a window with a bunch of buttons that modify the state of my application in various ways for testing purposes. I use events to dispatch button clicks to other systems that do actual work, the GUI system just draws the window and the buttons and sends out events. Every button fires a different event type and I end up with an EventWriter parameter for each of them. Clippy is complaining and it's hard to disagree.

I have considered some alternatives such as packing my event types into an enum or using a global resource with change detection instead of events to hook up the buttons to corresponding systems. But these seem like workarounds that just introduce different types of problems instead. Ideally, I think I would like EventWriter to be a non-generic type that instead has a generic send method since then I could have just one writer for all my event types (EventReader would still be generic). But that's not how bevy events are designed and I'm out of ideas.

I would welcome any suggestions.

[alice-i-cecile]

I've seen this difficulty come up before in input, UI and external integrations before: both of them tend to push first-pass designs towards massive monolithic systems that, like you point out, are hard to reason about or refactor.

In a fully ECS-integrated design, I would:

1. Make a generic system, that takes an EventType: Component type parameter. When a button with that marker component is pressed, send an event of the appropriate type.
2. Spawn buttons with those marker components.
3. Extend the App::add_event method to also add this system with that same type.

Because you're only reading from the resource that contains egui's state (Res<EguiContext>), you should be able to do the same flavor of thing, and read from the buttons in parallel (in stark contrast to the other "easy" solution to this problem, exclusive systems).

It looks like the "which button did I press" .button method in egui is stringly-typed, so you'll probably need to pass in a string to your App method, and then store it in a Local, but I think otherwise the approach should still transfer over fine.

[ghost]

Thanks for you reply. Let me see if I correctly understand what you suggest. Instead of having a system with an EventReader parameter waiting for an event dispatched by a button click, I should take Res<EguiContext> as a parameter and use egui::Context::output to inspect egui events and check if the button I'm waiting for has been clicked. Is that what you are saying?

[alice-i-cecile]

No, not quite what I had in mind, although that would actually work as well.

Instead, my proposal was something like this:

trait EguiExtension {};

// This allows us to add new methods to App
// On 0.5, this would be an `AppBuilder` method instead
impl EguiExtension for App{
  fn add_egui_event<E: Default>(&mut self, label: String){
     // Initializes the event resource and adds a cleanup system
      app.add_event::<E>();
      app.add_system(egui_event_parser_factory::<E>(label))  
  }
  
  // This function returns a function that can be used as a system
  fn egui_event_parser_factory::<E: Default>(label: String) -> impl IntoSystem{
    // This is the final system that will get inserted
    fn egui_event_parser::<E: Default>(egui_ctx: Res<EguiContext>, event_writer: EventWriter<E>){
       let ui = egui_ctx.ctx();
       // `label` is captured here, and stored in the system's definition
       if ui.button(label).clicked(){
         event_writer.send(T::default());
       }
    }
  }
}

[ghost]

OK, I see. That doesn't work unfortunately. egui widgets are not "stringly typed" (I wasn't entirely sure what you meant by this at first). Instead, they are identified by an integer Id so the button created inside egui_event_parser is unrelated to the one I put in my GUI system.

[alice-i-cecile]

Ah, I haven't used egui directly, so this was based off the examples. Can you pass that Id in, instead of the label field?

[ghost]

No, I don't think so. The Id is generated on the fly by Ui::button, it returns a Response which contains the Id so I can inspect it, but I don't see a way of choosing it myself.

More broadly, I guess there is just a fundamental clash of philosophies in trying to use events in immediate mode GUI. Still, it would be good to have some workaround until bevy gets a proper ECS based GUI.