react-tracking

Actually move core-js to peerDep this time 😄 #101

core-js moved to peerDep (thanks @damassi in #99)

Adds core-js dependency #98 thanks @damassi

Thanks to @damassi in #94 react-tracking now uses Babel 7

6bf2c3a Upgrade to babel 7 (#94)
759879f Update deepmerge, fix vulns (#96)
698e18c Fix lint (#95)
59c45f1 (damassi/master) Update README.md
a4a74db Fix test as a result of enzyme upgrade
81feee0 Update deps
c922ca4 Update README.md (typo) (#90)

Bug Fixes

Thanks to @schustafa , react-tracking default dispatch will no longer push empty objects {} to window.dataLayer[]

8b40759 don’t push empty event objects (#88)

Thanks to @spencewood in #82 react-tracking now supports async functions (or functions that return a Promise)

  @track()
  async handleEvent() {
    return await asyncCall(); // returns a promise
  }

See the main README documentation for more details, including how to conditionally dispatch a tracking event only when the promise resolves and/or rejects.

Bumps some dependencies and bumped React peer dependency to support React 16 (thanks to @lszm in #72 )

Thanks to @dortzur in #62 Now uses deepmerge for a ~65% smaller bundle size! 🎉

Before #60 by @tanhauhau changes to props on intermediate components would not be updated when descendent components fired off tracking events. They would instead use the values that they were initialized with. They now properly update as their props update.

This is a bit of an edge case, but the usage feels natural enough that it makes sense to fix. It should not affect any current semantics or API. Take a look at the test cases added as part of the PR ( #60 ) for an example.

Much thanks to @tanhauhau for finding and fixing this bug! 🎉

New Feature (Breaking Change)

Thanks to @mennenia in #45 🎉

The signature of decorated class methods changes from:

(props, args) => { }

to:

(props, state, args) => { }

This is so that you can access Class runtime state information within the decorator, like so:

// Reminder, to decorate class methods, you need to decorate the class itself
@track()
export default class FooButton extends React.Component {

  // In this case the tracking data depends on
  // some unknown (until runtime) value (state and event)
  @track((props, state, [event]) => ({
    action: 'click',
    inModal: state.isModalShowing,
    label: event.currentTarget.title || event.currentTarget.textContent
  }))
  handleClick = (event) => {
    if (this.props.onClick) {
      this.props.onClick(event);
    }
  }

  render() {
    return (
      <button onClick={this.handleClick}>
        {this.props.children}
      </button>
    );
  }
}

NOTE: This was technically possible in previous versions, but required you to use the imperative this.props.tracking.trackEvent() API so that you had access to Class state, this.state. Now it's possible to keep the tracking logic declaratively in the decorator thanks to @mennenia ! 💪

Bug Fix

#40 - Fixes the TrackingPropType export

In #39 we now export two different proptypes:

• TrackingPropType (new) - This is a proptype you can use for decorated components.
• TrackingContextType (renamed) - This is a context proptype you can use if you want to pick off context (this was previously named "TrackingPropType" which would be confusing with the new proptype mentioned above).

Same as v4.0.0 but now published to npm as react-tracking 🎉

Breaking Change

In #35 the default dispatch behavior of emitting a CustomEvent has been removed in favor of pushing tracking objects to window.dataLayer[]. This is a good default for most pass that use Google Tag Manager for tracking.

If you had previously been relying on CustomEvent, you will need to now import that module into your project and define the call to CustomEvent as your new overriding dispatch() function on some top-level component. See the main README for details.

If you had previously been defining dispatch() on some top-level component, then this is not a breaking change from your perspective because any overriding dispatch function declaration will be used instead of the default behavior.

New Feature

In #31 we now expose a single tracking prop that looks like:

{
  // tracking prop provided by @track()
  tracking: PropTypes.shape({
    // function to call to dispatch tracking events
    trackEvent: PropTypes.func,

    // function to call to grab contextual tracking data
    getTrackingData: PropTypes.func,
  })
}

This is so that you can grab the contextual tracking data if you need it by calling props.tracking.getTrackingData(). The previous props.trackEvent() is now props.tracking.trackEvent().

Breaking Changes

props.trackEvent() is now props.tracking.trackEvent()

#30 - Now using prop-types module for React PropTypes

Bug Fix

#29 Fixes a bug introduced in v2.2.0, where tracking events were dispatched from process() even when tracking events were dispatched in child handlers

New Feature

options.process() ( #27 ) can now be defined to selectively dispatch a tracking event when any decorated component mounts, based on the tracking object for each component. This will help clean up the verbosity that's currently required to dispatch PageView events using dispatchOnMount() previously.

See the README for more details.

Bug Fix

options.dispatchOnMount() will now merge in the context data for you.

New Features

options.dispatchOnMount() as a function (#20) - You can now provide a function instead of just a boolean for dispatchOnMount. The function provided will be called with a single argument, all of the context tracking data in the app. You can chose to ignore this in order to dispatch exactly the object you want when the component you are decorating mounts (in componentDidMount()).

See the README for example usage.