search

Soluto / shisell-js

A service agnostic library for building immutable scoped analytic event dispatchers with extra data, identities and lazy filters.
MIT License
41 stars 3 forks source link

Consider changing the name ExtraData #21

Closed itaym2 closed 7 years ago

itaym2 commented 9 years ago

I think the name "ExtraData" is confusing. Why is this data is extra? What data is not extra? I think changing the name to EventProp or Props or something similar and updating the dsl accordingly will make the meaning clearer:

var homeViewDispatcher = rootDispatcher
                          .withEventProp('firstName', user.firstName)
                          .withEventProp('lastName', user.lastName)
                          .withEventProp('email', user.email)
                          .withEventProp('age', user.age);
Yshayy commented 7 years ago

Props is definitely better, What about more js approach:

rootDispatcher.withProps({firstName: user.firstName, lastName:user.LastName})
talarari commented 7 years ago

Sounds good to me. Also we should consider changing the term filter, since it doesn't filter anything. More like middelwares.

Yshayy commented 7 years ago

I think filters and middlewares are pretty equivalent in web, as seen in asp.net mvc filters, iis isapi filters, ruby on rails filters, play framework filters. However, both concepts (middlewares and filters) are commonly used in servers, in clients usually the concept is interceptors, but it feels weird. If we look at filters as low-level building blocks for building enhancers, we can provide a friendlier (and maybe mutation free) api for adding just-before-dispatch dynamic properties (or meta).

dispatcher.withDynamicProps({eventTime: (props)=> new Date().getTime())

While filters abstraction can be useful, we can keep it for more advanced usages. (for example, PII filter)

Yshayy commented 7 years ago

26