🪟 🔧 Add proper page view events for Segment

[letiescanciano]

What

Closes #15849
There was a bug preventing analytics.page being fired on page views.

How

This PR changes a the old implementation where we were checking the url to determine what event should we fired (even though it wasn't working because a bug in how those routes were being checked) to calling useTrackPage() directly in every page component.

Main reasons of this change:

• We avoid having to add a new check in that old getPageName method, avoiding also regex and string checks.
• We have all of our tracked routes/event names in one place pageTrackingCodes
• When removing a page, we also removed it's page view event.
• When adding a page, we should make sure to ALWAYS include useTrackPage() and create the needed code.

🚨 User Impact 🚨

No user impact, just better analytics

[krishnaglick]

I have questions about the intent here. This seems like a lot of engineering for something that doesn't seem like a simple problem.
Do we only want to report certain pages? Is there some reason we couldn't parse out what we need from the url? React-router has useRouteMatch

[timroes]

@krishnaglick The advantage of having it distrbuted is, that we don't need to have one central place (as of today), that needs to know about all the paths that exist across the app and handle that centrally (and therefore likely to forget adjusting that place when adding a new page). I personally prefer the approach of having it tracked in the page component itself. (I'd only have preferred more if we could have attached meta information to the actual react-router route and read that out, but unfortunately that's not supported by react-router - despite many people already asked for it).

[letiescanciano]

@krishnaglick thanks for your comment. As Tim was explaining, we see benefits on having it colocated directly at the page level, making the page component responsible for its own tracking.
Re: inferring it from the url, we could indeed, but we want to have a more friendly page view name to make analytics easier. Segment will capture the url no matter what, but this way we can easily group page views for single items, for example, /workspaces/:id/source/:sourceId without having to worry about ids when we want to analize the data.

[krishnaglick]

@krishnaglick thanks for your comment. As Tim was explaining, we see benefits on having it colocated directly at the page level, making the page component responsible for its own tracking. Re: inferring it from the url, we could indeed, but we want to have a more friendly page view name to make analytics easier. Segment will capture the url no matter what, but this way we can easily group page views for single items, for example, /workspaces/:id/source/:sourceId without having to worry about ids when we want to analize the data.

I guess this just sets off my code smell, but I understand. Having that single data point to query against would be easier on analytics.

[timroes]

We tend to use enums for those places we plan to have "complete" lists of keys that should be used. Also we'd be able to change then the type of useTrackPage parameter type to only accept that enum.

[timroes]

Also could we maybe re-export this type from the src/hooks/services/Analytics/index.ts file, so we can import it from there. We try to re-export types and methods that are supposed to be used outside that specific folder, and if it's not re-exported try to treat it as private to this folder.

[timroes]

Code LGTM, have not tested locally. Vale!