poc: Workspace support

[allansson]

⚠️ This is only an exploration of a potential feature and does not reflect a commitment of implementing it.

This PR contains a proof-of-concept implementation of workspaces in k6 Studio. I will share some of my findings in the description of this PR.

What

Having more flexibility in organizing your recordings, generators and scripts is a highly requested feature. This marks a significant change in how these artifacts are handled by k6 Studio, both in terms of UX and internal architecture.

This exploration has assumed a VSCode-like experience where users can open any folder as a workspace. The sidebar contains an file tree where you can browser files, create folders, etc.

Pain points

In this section I'm going to go through the issues I had to tackle to get things to work and how I solved them.

File path handling

Problem

Files in k6 Studio are tracked by their filename (e.g. and its type (recording, generator, test or script). When loading and saving files the paths are created by using by getting a static path for the file type (e.g. ~/Documents/k6-studio/Recordings) and concatenating the filename to it.

Any files references stored in other files, such as the recordingPath, are also stored as just the filename and the type of file is inferred from the property.

Solution

The first step was to make k6 Studio only work with absolute paths internally (incl. files referenced from other files). This removed the dependency on concatenated paths for everything except listing the files.

File references in other files, such as data files in generators, are always stored as relative paths. When files are loaded paths are converted to absolute paths internally.

A migration was added to convert stored filenames to relative paths. This is possible because we know where all the files are stored in pre-workspace files.

File loading and saving

Problem

Each type of file has its own load and save logic. It becomes a problem when a user can attempt to open arbitrary files. When that happens the only thing we have to go on is the file path that the user picked.

Solution

A common interface for loading and saving files was introduced. The file types are always inferred from the file extension, regardless of whether the file is opened from the file tree or from an "Open file"-dialog.

Files are deserialized based on their inferred type. If the type cannot be inferred or serialization fails, a special "unsupported" file type is returned.

File creation

Problem

When creating anything, e.g. a generator, k6 Studio will immediately create a file for it. This is possible because we know exactly where to put it: recordings go in Recordings/, generators in Genterators/, etc.

This workflow does not work when users can organize their files themselves. We can't just assume where the user wanted to put a file and create it there.

Recordings are especially interesting because the files are created when a recording is completed and a "Discard" button is shown to undo the file creation. This is the inverse of how file creation usually works.

Solution

This is solved in two ways:

1. Files created via e.g. the "Create test" button aren't be created until the user save them for the first time. It follows the well-established pattern of showing a "Save as"-dialog when the file has not been saved before.
2. Folders in the file tree have a button to create files. This immediately creates a "virtual" item in the tree and lets the user input a name for the file. Pressing enter immediately creates the file.

NOTE: In this implementation recordings can only be created if there is a Recordings/ folder in the workspace. Changing the behavior of this flow turned out to be more work than I had time for.

Script generation

Problem

Exported scripts can reference data files and those paths need to be relative to the location of the script itself. Our current solution is based on:

1. Copying data files to a predetermined directory (Data files/).
2. Knowing exactly where the script is stored (Scripts/)
3. Constructing a relative path from these known locations (../Data files/)

When users are allowed to organize their files this is no longer possible.

There are also multiple places where we generate a script:

1. When exporting a script
2. When validating an HTTP test
3. In the Script preview tab

All of these currently assume that the script will eventually end up in the Scripts/ folder. When validating a script we create a temporary script file with a specific filename pattern that is then filtered from the UI.

Solution

In order to generate correct paths to data file, the intended absolute path to the script is passed to codegen. Since data file paths are also absolute, the relative path can be calculated between the two.

Exporting a script uses a native file system dialog. Users can pick any path and filename. This path is then used to generate the script.

When validating we create a temporary file in the OS's tempdir. This is possible because the relative paths are not calculated, making the location of script and data files independent on each other. This also removes the need for special filtering logic.

Previews just use the same path as the generator for which it is generated. This produces a nice looking path, even though it might not be exactly the same path that is exported.

Opportunities

Native menus

The implementation makes good use of native menus. Previously opened workspaces are tracked using native recent files functionality.

// TODO: Video capture

It provides a highly recognizable workflow.

HAR and data file import

Since there are no longer any predetermined directories where HAR and data files can be copied, the implementation has to assume that they can be anywhere on disk. This makes the concept of importing files redundant.

Location independent editors

While the implementation centers around having a workspace, the editor actually makes no difference between opening a file in the workspace and opening it from anywhere else. This makes creates a nice experience when you want to quickly debug a script outside the workspace directory.