You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When #2 gets merged we'll have basic functionality in place but creating events from scratch will be rather cumbersome since there aren't any factory functions that populate primarily meta fields with reasonable defaults. Quoting the README.md example:
The EventModifier type would be a function type whose implementations could make various transforms of the newly created event. Unfortunately it's a bit icky to write such functions that work on all events since there currently aren't any common types, i.e. every single event type (and major version) has its own struct for the meta field, but maybe we can use reflection and define an interface like
that all struct types can implement? This is what this could look like from the client side to explicitly select a particular event version (if you don't want the latest v3.x.y):
Other useful EventModifier implementations includes those that modify meta.source.serializer, meta.source.name, meta.source.host, and meta.source.domainId.
We could also consider supporting factory factory functions, i.e. a function that returns a function that creates an event. This would be useful to avoid repeating the same set of factory configurations.
This'll make it much easier for programs that create events to construct valid event structs. It'll reduce the amount of boilerplate code and the risk of bugs.
Exemplification
N/A
Benefits
See above.
Possible Drawbacks
Nothing besides more code and complexity.
The text was updated successfully, but these errors were encountered:
Description
When #2 gets merged we'll have basic functionality in place but creating events from scratch will be rather cumbersome since there aren't any factory functions that populate primarily
meta
fields with reasonable defaults. Quoting the README.md example:To solve this we should generate factory functions with the following example signature:
The EventModifier type would be a function type whose implementations could make various transforms of the newly created event. Unfortunately it's a bit icky to write such functions that work on all events since there currently aren't any common types, i.e. every single event type (and major version) has its own struct for the
meta
field, but maybe we can use reflection and define an interface likethat all struct types can implement? This is what this could look like from the client side to explicitly select a particular event version (if you don't want the latest v3.x.y):
Other useful EventModifier implementations includes those that modify
meta.source.serializer
,meta.source.name
,meta.source.host
, andmeta.source.domainId
.We could also consider supporting factory factory functions, i.e. a function that returns a function that creates an event. This would be useful to avoid repeating the same set of factory configurations.
Motivation
This'll make it much easier for programs that create events to construct valid event structs. It'll reduce the amount of boilerplate code and the risk of bugs.
Exemplification
N/A
Benefits
See above.
Possible Drawbacks
Nothing besides more code and complexity.
The text was updated successfully, but these errors were encountered: