Show project picker when no project id is in main.js

[weeksling]

Screen.Recording.2023-07-05.at.12.47.47.PM.mov

Adds a parameter for the projectId and lets the user select between projects they are associated with. Includes serverChannel method to mutate the storybook configuration when setting the projectId & projectToken.

Not working yet:

• useParameters pulls values from preview.ts, but not from addon options. Need to find a way to use option parameters from main.ts instead.

Pull request base is test-screens to make the changes here easier to diff. Should be changed to main prior to merging.
This depends on related Chromatic api PR https://github.com/chromaui/chromatic/pull/7460

📦 Published PR as canary version: 0.0.4-canary.10.1175a32.0

✨ Test out this PR locally via:

npm install @chromaui/addon-visual-tests@0.0.4-canary.10.1175a32.0
# or 
yarn add @chromaui/addon-visual-tests@0.0.4-canary.10.1175a32.0

[linear]

AP-3260 Project Picker with Chromatic api and token

After the user has logged into Chromatic, the onboarding asks them to select a project to connect to. Using the authentication token, and the public API, implement a project picker.

Questions/Unknowns:

• How to persist this selected project?
  • Localstorage, or manual config in main.js
  • Can we get access to this information with the projectToken somehow?
• Can we use the Chromatic design system for the UI? Would this increase the addon's size too much?

[tmeasday]

@ndelangen can you take a look, especially at the preset code-- @ghengeveld can you review the UI code.

I have it working doing the following:

1. Reading project id + token from main.js
2. Running a git command on startup
3. Setting all of the above in process.env (sort of similar to your idea of automatically setting addon options in the build).
4. Writing to main.js when you select a project.

What's missing/broken right now is:

1. Because we use env to set initial values, if you select a project and refresh the browser, you'll lose track of the selected project.

• We could store the selected project in local storage to avoid this
• Or we could change it to request the selected project + git info via an event on bootup as originally planned. WDYT @ndelangen?

2. Similarly if you change branch or commit but there's initial value built into the SB it'll go out of date if you refresh (although in that case I expect to poll for values). So maybe events is better?

3. The branch behaviour is weird in other ways but I'm not looking to fix that in this PR.

If y'all agree we could just say we are OK with 1+2 as limitations right now and fix it in a later ticket. I'm leaning that way.

[ndelangen]

Or we could change it to request the selected project + git info via an event on bootup as originally planned. WDYT

I feel like that's what I've been saying for a while, that will yield the best result, no weird behavior for anyone.
It won't support static build, but the addon won't support static storybook anyway.

[tmeasday]

I feel like that's what I've been saying for a while, that will yield the best result, no weird behavior for anyone.
It won't support static build, but the addon won't support static storybook anyway.

I guess so. But it seems overly complex to have 2 events just to request some data. Is that the pattern we want to lay down for client initiated server->client communication?

Other options:

• HTTP requests rather than server channel (like /index.json) for data requests
• Some API that abstracts away how it is implemented (which I think you also suggested).

My inclination is to take it a bit further like this just to gather information and then thrash it out very soon.

[ghengeveld]

I added slug to the lastBuild field args. This requires an update on the API side.