Optional Properties Should Not Be Required in Code
E
Elena Pellin
We're encountering a recurring issue when working with Avo in a large codebase with multiple developers contributing simultaneously.
Currently, when a property is marked as optional in the Avo UI, the generated tracking code still requires the property to be explicitly set, even if it's just set to undefined. While this may seem acceptable on the surface, it creates a major integration problem in practice.
Here’s a typical scenario:
- Developer A adds a new optional property to an existing event in Avo.
- Avo updates the event types accordingly and Developer A merges their Avo branch into main.
- The Avo-generated types now require this new property (even if just as undefined), and the entire codebase breaks unless all usages of that event are updated accordingly.
- However, the actual implementation of the new property might be in Developer B’s branch, which is still under review.
- Until Developer B's branch is merged, the Avo update in main breaks the build or throws runtime errors.
This forces teams to either delay merging Avo changes, or coordinate tightly across branches and reviews, which is not always feasible in fast-moving environments.
Request:
When a property is marked as optional in Avo, it should truly be optional in the generated code, meaning the property should not be required at all when calling the event function. Ideally, the property would be omitted entirely unless explicitly provided, rather than requiring an explicit undefined.
Benefits:
- Prevents code breakage when optional properties are added.
- Allows asynchronous development workflows without coordination bottlenecks.
- Reduces friction when merging Avo updates into main before all consuming branches are ready.
We’re aware of this existing feature request:
👉 Optional event properties should be optional in the generated TypeScript interface: https://feedback.avo.app/bug-reports/p/optional-event-properties-should-be-optional-in-the-generated-typescript-interfa
However, that solution doesn’t work for us. We have a dedicated team that reviews all tracking implementations, ensuring that optional properties are included when relevant. Because of that, we’re not worried about developers forgetting to include meaningful optional data, but we do need the flexibility for those properties to be truly optional in the code, to allow smoother collaboration and staging of changes across branches.
Perhaps a good solution would be to let users choose between both behaviors in Avo depending on their team’s workflow.
Right now, this is becoming a significant blocker and is noticeably slowing down our ability to implement new tracking reliably and efficiently.
Thanks in advance.