From Classic to Core - React Native Edition
If you're using Heap's Classic React Native SDK and you're thinking about upgrading to our latest Core SDK offerings, there are a few differences you'll want to be aware of to help inform that decision.
SDK Configuration
Heap's Classic React Native SDK is an "autocapture by default" solution. This means that the SDK is built to primarily enable autocapture with custom tracking being a secondary use case. Advanced configuration is required to disable the autocapture behaviors in the Classic SDK, but disabling autocapture can also lead to some properties, such as library version or build type, not being captured.
In the Core SDKs, we've reworked our offerings so that we start with custom tracking and a set of standard APIs first. Everything you need to track events, identify users, and add user and event properties is available through our custom tracking SDK. If you want to add autocapture on top of that, it's as easy as adding our autocapture SDK and BabelJS plugin, along with a single line of code, to get that setup. No advanced configuration is needed to enable or disable autocapture.
Configuration Summary
Classic SDK | Core SDKs |
---|---|
Autocapture by default. | Custom tracking foundation with autocapture available |
Advanced configuration needed to disable autocapture. | Easily add autocapture on top of custom tracking with minimal code updates. |
Configuration Methods
The Core React Native SDK does not offer automatic initialization. Instead, you can use Heap.startRecording
in your app's code Ideally, this should be executed once, but calling the method multiple times with the same options is safe.
Heap can also be de-initialized using Heap.stopRecording
, supporting behavior like analytics opt-out.
Autocaptured Events
The Core React Native SDK captures all of the same events as Classic SDK. There are two changes to events that will affect autocapture.
- Edits to text fields will now show up as "Change on" rather than "Field edit" events. This brings the React Native SDK in line with the other SDKs, which produce a single event type for form field changes.
- React Native screen views are now saved as pageviews rather than events. Again, this brings the SDK closer to the other SDKs.
Autocaptured Properties
The React Native hierarchy has been refined in a few ways. These are all designed to simplify event creation, but can impact migration between the two SDKs.
testID
is now used for IDs in hierarchy, so<Button testID="add-to-cart" />
will show up asButton#add-to-cart
rather thanButton[testID=add-to-cart]
by default.To match existing event definitions on
testID
, you can use thepreserveTestIdProp
registration option:registerHeapAutocapture({ isDefault: true, preserveTestIdProp: true, });
- When using React Navigation, the hierarchy will end at the screen rather than continuing through the navigation library's internal views. This will produce shorter, and easier to read, hierarchies.
- When interacting with elements like
<Button />
, the touched view will be reported asButton
rather than the internalTouchableOpacity
. This will also make it easier to create events and get meaningful event properties. - When using
<HeapIgnoreText />
, properties that are known to display text are automatically excluded from the hierarchy. - Duplicate views from HOCs are omitted from the hierarchy.
Additionally, the "Screen Name" property no longer returns the inner-most component and instead returns the same value as "Screen Path".
Pageview support
The Core SDK has two distinct improvements over the Classic SDK:
- React Native Navigation 7.0 and later are now supported. Apps using this library will now see autocaptured pageviews.
- React Navigation 5.0 and later no longer need manual instrumentation with
withReactNavigationAutotrack
. This function is still safe to call but can be removed from the app.
Event Creation
Heap Classic events are commonly created via either the live data feed or visual labeling. Visual labeling has the added benefit of being able to create an event using the hierarchy of the UI component that was interacted with, which isn't visible for events created via the live data feed with the Classic SDK.
In Heap Core, events are primarily created via the live data feed. The visual labeling interface is not currently supported for Heap Core. Autocaptured events from Heap Core will include their hierarchy in the live data feed to allow this property to be used in events.
Visual Labeling Support
If the visual labeling interface is a core part of your workflow in Heap, we do not recommend switching from Classic to Core at this time.
Creation Methods
Classic SDK | Core SDKs |
---|---|
Live data feed | Live data feed with enhanced hierarchy data |
Visual labeling interface | No visual labeling support at this time. |
Explore events | Explore events |
Users and Installs
The Core SDK does not read from or write to the same storage location as the Classic SDK. Because of this, switching to the Core SDK will cause a temporary spike in new users and install events, as if you were seeing all of your users for the first time. This spike is temporary and will level out once all users have upgraded to a version of your app that uses the Core SDK.
Updated about 1 month ago