Skip to content

ECA Best Practices

This section collects recommendations and best practices for building, organizing, and maintaining ECA models.

Structuring your models

One common question when working with ECA is whether to create many small, individual models for each task or to combine related logic into fewer, larger models.

Individual vs. Combined Models

Recommendation: Group related functionality into a single model, but keep unrelated logic separate. Prioritize organization and maintainability over theoretical performance concerns.

If you have multiple reactions to the same event (e.g., "Presave content"), or a set of events that are logically part of the same workflow (e.g., a "New User Onboarding" process that involves account creation, role assignment, and a welcome email), it makes sense to keep them in one model. This keeps the "story" of that feature in one place, making it easier to understand and maintain.

Why separate unrelated logic?

If you have a model for "User Management" and another for "Article Publishing", keep them separate. This has two benefits:

  1. Organization: It is easier to find what you are looking for.
  2. Performance: ECA models are stored as configuration. When an event occurs, ECA loads the models that are listening for that event. By separating unrelated models, you ensure that ECA only loads the configuration necessary for the current context, avoiding unnecessary memory usage and processing overhead.

Performance Implications

While splitting models can have a performance benefit by reducing the configuration loaded for any given event, the difference is often negligible for typical sites. Do not sacrifice code readability or logical organization for the sake of micro-optimizations.

The primary driver for your decision should be: "Does this structure make it easier for me (and others) to understand and maintain this workflow?"