The biggest problem with this extension's architecture, in its current state, is that the format of the Event class, as well as the names of the events and the property names in the serializers, are all specific to Klaviyo, because it was originally extracted from the source code of solidus_klaviyo.
However, the entire idea behind the extension is that it can be used with multiple trackers, not just Klaviyo.
There are two potential solutions here:
- Simply provide the hooks for trackers to subscribe to and fire their own events. In this scenario, each tracker provides its own event and serializer classes. While this allows maximum flexibility, it also means that there's very little reusable logic across the different trackers. If we add support for an event in solidus_tracking, each tracker will have to implement it on its own. The same goes for serializer properties. It kind of defeats the purpose of having the extension in the first place.
- Make the serializer and event classes more tracker-agnostic by returning more idiomatic Ruby hashes, and allow each tracker to transform the data according to the format for that tracking service. While a bit more complicated to pull off, this feels like the right path.
The biggest problem with this extension's architecture, in its current state, is that the format of the Event class, as well as the names of the events and the property names in the serializers, are all specific to Klaviyo, because it was originally extracted from the source code of solidus_klaviyo.
However, the entire idea behind the extension is that it can be used with multiple trackers, not just Klaviyo.
There are two potential solutions here: