Centralise logic for calypso_customer_home_card_impression avoid null cards
Proposed Changes
- While looking at Tracks events being triggered from My Home, I realised that we are logging
nullfor thecardevent prop in cases where we're using the two-column layout we added for the Launchpad in My Home. - This PR centralises the logging code into a new
trackMyHomeCardImpression()helper function that supports alocationvalue, and refactors the existing code that tracked these impressions to call the new function
Why are these changes being made?
- I noticed that we're logging thousands of non-events, so we ought to stop doing that.
- It also looked like our tracking for secondary cards was inconsistent, so I wanted to make sure we have visibility into which cards are being rendered
- I also realised that it would be valuable to know where a card was rendered, not only that it was rendered somewhere in My Home.
Testing Instructions
- Run this branch locally or via Calypso.live
- Ensure you can view Tracks events in your browser
- Navigate to My Home for sites in different states, especially sites with different intents or that are showing the launchpad in My Home for other reasons
- Verify that you see a number of
calypso_customer_home_card_impressionTracks events, where every event includes both acardand alocationproperty. - Also verify that we're not triggering multiple events for any card and location pairs.
Pre-merge Checklist
- [x] Has the general commit checklist been followed? (PCYsg-hS-p2)
- [ ] Have you written new tests for your changes?
- [x] Have you tested the feature in Simple (P9HQHe-k8-p2), Atomic (P9HQHe-jW-p2), and self-hosted Jetpack sites (PCYsg-g6b-p2)?
- [x] Have you checked for TypeScript, React or other console errors?
- [N/A] Have you used memoizing on expensive computations? More info in Memoizing with create-selector and Using memoizing selectors and Our Approach to Data
- [N/A] Have we added the "[Status] String Freeze" label as soon as any new strings were ready for translation (p4TIVU-5Jq-p2)?
- [N/A] For changes affecting Jetpack: Have we added the "[Status] Needs Privacy Updates" label if this pull request changes what data or activity we track or use (p4TIVU-aUh-p2)?
Jetpack Cloud live (direct link)
|
|
https://calypso.live?image=registry.a8c.com/calypso/app:build-109510&env=jetpack |
Automattic for Agencies live (direct link)
|
|
https://calypso.live?image=registry.a8c.com/calypso/app:build-109510&env=a8c-for-agencies |
Here is how your PR affects size of JS and CSS bundles shipped to the user's browser:
Sections (~155 bytes added 📈 [gzipped])
name parsed_size gzip_size
home +314 B (+0.0%) +155 B (+0.0%)
Sections contain code specific for a given set of routes. Is downloaded and parsed only when a particular route is navigated to.
Legend
What is parsed and gzip size?
Parsed Size: Uncompressed size of the JS and CSS files. This much code needs to be parsed and stored in memory. Gzip Size: Compressed size of the JS and CSS files. This much data needs to be downloaded over network.
Generated by performance advisor bot at iscalypsofastyet.com.
This PR modifies the release build for the following Calypso Apps:
For info about this notification, see here: PCYsg-OT6-p2
- wpcom-block-editor
To test WordPress.com changes, run install-plugin.sh $pluginSlug fix/my-home-tracking-for-empty-primary-card on your sandbox.