Add support for creating a file via link, and add ability to generate and share such links

[franknoirot]

• Add a command that accepts the following arguments and creates a new file with the provided code and navigates to it.
  • method
    • newFile adds a file to the root of the current project and gives the file the value of name
    • newProject adds a project with name and adds a main.kcl file within. Hide this on web
  • projectName only required if the newFile argument is selected
  • code
  • units
  • name
• Add a query parameter like ?create_file that, whenever present, triggers this command with the code value found in a code query parameter, and units value in a units one. code will be base64 encoded
• Add a command to "Share a link" that generates this sort of link and copies it to the user's clipboard
  • Add a warning on the confirmation step of this command that tells people this URL will be available to anyone, and contain a copy of the current code

Future work

1. Pass this URL through a self-hosted URL shortener to generate manageable URLs
2. Upload temporary, content-hashed files to link to so the URL doesn't contain the payload
3. Add password and org-level auth for such links after 2 is implemented

[jessfraz]

we will want the nice modals that are like yo tthe units are different than your current project if they add to existing so we will want to pass the units as well

[jessfraz]

all the investment into nice modals and user experience here will be reused on:

• kcl-samples opening
• text-to-cad open from the text-to-cad site
• share urls

so its worth really making this flow nice as it will be used A LOT

[franknoirot]

Oh nice yeah we can just add the units as another query parameter and corresponding argument to the command! I've updated the description to include that.

[franknoirot]

all the investment into nice modals and user experience here will be reused on:

• kcl-samples opening
• text-to-cad open from the text-to-cad site
• share urls

so its worth really making this flow nice as it will be used A LOT

I'm planning on routing this through the command palette, like how the current implementation of the "Open a sample" command works. Is that okay? There will be warnings on the confirmation step too, I just like reusing that UX path for as much as we can, but I want to make sure you don't have a specific new idea of modals and UX here that I should implement.

[nadr0]

What is the plan to gracefully handle the user doing this workflow multiple times for the same URL?

[franknoirot]

What is the plan to gracefully handle the user doing this workflow multiple times for the same URL?

@nadr0 I think the idea is that the user gets the opportunity to create a new file each time, with the option to update to provide a new file/project name as well. I know that we have logic that gracefully increments duplicate file names so repeat use should not be a problem there, but I need to test repeat project creation to make sure it doesn't blindly overwrite existing projects.

[franknoirot]

I am realizing that the fact that our web experience doesn't have a /home experience is starting to require weird engineering effort to work around. Something we should think about in the future, trying to get these things more in-sync so there isn't so much branching logic between the platforms.

[franknoirot]

Hide this while not in a project

I realize that this would mean anyone who opens the link in the desktop app would never have access to adding the file to an existing project. I need a projectName argument that only is required if you choose the newFile argument. In the web those will be filled with defaults and whatnot and skipped, but that's how on the desktop users can choose a project to slot into.

That being said, I think the user workflow is as follows, with some technical details for my memory:

1. user receives link with format app.zoo.dev/?create_file&units=in&code=some-base64-encoded-string (or a shorted version from our service) either by running the "Share file" command or from someone else, and clicks it
2. depending on platform:
   1. If the user is on the web and the "open this in the app" browser UI doesn't intercept, they are redirected, with the query parameters intact, to the /file route, because the /home route is not present in the browser
   2. When opened in the app, the URL opens to the /home route and the command flow takes place in the same manner
3. The app sees the presence of the ?create_file param and requisite other parameters and fires off the command bar "Find and select command" XState action, with the query parameters provided as default values
4. Thanks to skip configs on the command arguments, the user teleports to the method argument
5. If the user chooses newFile, they must enter another arg for which project they want to add to
   1. On the web, the only method argument is newFile and both 4 and 5 are skipped, since they are already in a project
6. In the confirmation step, we perform a check to make sure the file or project will not collide with their targets and warn the user if they will

[nadr0]

The workflow you described looks good.

Do we want to add any other default information to the create_file action? Could we provide the users filename as default and encode filename=<> into the URL as well?

I don't think we should encode the project folder structure but I think the default filename could be useful.

[franknoirot]

Do we want to add any other default information to the create_file action? Could we provide the users filename as default and encode filename=<> into the URL as well?

Yes for sure! There's a name parameter that will either be the default name of the project (if method is newProject) or file (if method is existingProject)