Closed adamschoenemann closed 3 years ago
Hey @adamschoenemann thanks for submitting a PR! I think I'm not fully grokking the use case exactly. Don't we already have access to the props
like in the advanced usage example?
You have access to props when creating the track data but not in the dispatch function which actually sends the events to some backend.
Ah, I see now! I think I get the use case now, although I'm hesitant to increase the API surface area for a couple reasons.
/* tracking component */
@track(props => ({ module: 'foo', props }))
class Foo extends Component { ... }
/* dispatch function */
const dispatch = (data) => {
const { ...trackingData, props } = data;
// can do whatever with `props`
// push the rest to the dataLayer
(window.dataLayer = window.dataLayer || []).push(trackingData);
}
What are your thoughts?
The use case is quite simple: You have your top-level component on which you define your dispatch
function. This top-level component receives some props that you want to access when dispatching. In my case, i have the quite common case where there is an API
object that is created at runtime and passed to my top-level component as a prop. This API object ultimately determines where the events should be sent.
In any case, I ended up not using this library anyway, so I won't push this PR much further, but I think it'd be a good addition to the library :)
Thanks @adamschoenemann it's an interesting case and maybe something we could consider in the future if this sort of request comes up again. Given that you ended up not using this library (curious, what did you end up using?) I think I'll close this PR for now. Thanks again for the contribution and the discussion though, it's appreciated!
A small change that'd be very nice. For example, I have a component that takes an API object that communicates with my backend and I want to use this prop to dispatch the tracking data