Onboarding improvements

[mariusandra]

Changes

This converts the onboarding page to TypeScript, converts the logic of changing card panes to Kea and fixes the regular JS code snippet, which was cut after the first line.

All of this works, though it's still a WIP as I want to implement changing the URL when you move between tabs, so we can use the back/forward buttons to go back without restarting everything. That was the original aim of these improvements. This should be easy to accomplish via the urlToAction and actionToUrl logic keys, pending slight alteration to the path system (using selectors to create the ordered steps beforehand based on existing input, so that the index will just follow the precalculated array)

I also saw under certain conditions the steps go "step 1 of 3", "step 3 of 4", "step 4 of 4" (or something like that, can't remember 100%).

Checklist

• All querysets/queries filter by Team (if this PR affects any querysets/queries)
• Backend tests (if this PR affects the backend)
• Cypress E2E tests (if this PR affects the front and/or backend)

[mariusandra]

After some refactoring, the onboarding widget now supports back/forward motion!

It's now also under its own URL at /onboarding

[mariusandra]

Hm, small bug to fix - after the first onboarding and getting an event, it redirected me back to the start of the onboarding... so not yet ready for review :)

[mariusandra]

Ok, that's fixed!

[mariusandra]

Something was still broken in the build, fixed now.
Also added:

• The preflight page now redirects to /setup inside the SPA without an extra browser refresh
• The "check again" button on preflight doesn't reload the page, but just makes an API call

[paolodamico]

* The "check again" button on preflight doesn't reload the page, but just makes an API call

Hey @mariusandra the reason for reloading the page instead of just doing an API call again is that if you change the SSL/TLS configuration, the check won't change unless the page is fully reloaded.

[mariusandra]

@paolodamico ah, got it! I reverted this.

[paolodamico]

Review mostly from a UX perspective. Just minor comments.

• I would change the /onboarding/* URLs to something like sources/* or ingestion/* because: a) we may reuse this same flow for already onboarded users that wish to add additional event ingestion sources in a guided way; and b) we might implement a different flow for the user onboarding at some point in the future (e.g. a feature walk-through). This way we can future-proof (mostly the metrics / analytics). Side note: It's great that you split this into its separate URL and each step now has a different URL, analytics on this was a bit painful before.

• Small UI thing, based on the background color of the notification, I would maybe change the text to white or more on the light side for better readability.
  

• I would move the /onboarding/mobile/api out of the mobile space as this is relevant for server-side events too (which we'll implement on New guided event ingestion #1547) [same for /onboarding/web-custom/api].

  • The copy to clipboard here copies the entire thing, but it's not a cURL command, so it's not pretty pretty helpful to copy the whole thing, I would either just copy the JSON body or turn this snippet into a cURL command.

• Should we maybe do a universal verify/listening endpoint instead of /onboarding/web-custom/nodejs/verify, /onboarding/mobile/verify? I think it might be easier to do analytics this way.

[EDsCODE]

code looks good. @paolodamico tag teamed the manual QA

[mariusandra]

Hey @paolodamico ! Thank you for the UX comments! I'll make changes soon, just to clarify a few things:

1. I'll change it to /ingestion, I think that's a better name than /sources

2. Will do!

3. Regarding /api, the idea is that the URL itself should contain all the information we need to go back to the previous page. Thus changing it to /ingestions/api will break the "back" button in the interface... and it may break the number/index of the step as well. I could use query params and have code like /ingestions/api?platformType=web-custom or hash params with /ingestions/api#platformType=web-custom (these won't be saved into posthog), though they both seem like a bit of a hack... and I'll need a special case for when the user just lands on /ingestions/api without any extra params to guide the "back" button.

4. Same for the verify step. We could have a final /ingestion/verify step, but it would have a few caveats: 1) I'd have to again include the previous steps inside the url like #platformType=web&framework=ruby (or with ?), in order for the back button to work and the step count would be correct. If opened without any platformType and framework parameters, I could just make the interface back button go back to the start of the ingestion.

Thoughts? Are these changes/tradeoffs worth it? Better to use a #hash parameter (won't be saved in posthog) or a ?query parameter (will be saved in posthog)?

[paolodamico]

In reply to @mariusandra:

I think the best way would be to do the static routes with QS params (?) as this will allows us to any type of analytics that we need, either holistic views where the specific selected framework doesn't matter or get very specific on a framework. From an analytics perspective it's even better to have these params, so it's great that you actually need them for the navigation too.

[mariusandra]

Hey! I fixed all the feedback, except for renaming onboarding to ingestion. That will be done with the next commit. It's a big change since a lot of files need to be renamed, not just the URL. Just confirming that we're all happy with the new name? @paolodamico

[mariusandra]

@paolodamico ready for another look