Ergonomic Extensions

[dragazo]

The current extension system is becoming increasingly more difficult to use as we begin to have more projects that use them (especially in terms of sharing). I think we need something along the lines of the following changes:

Allow extensions to be loaded after the fact

I run into this pretty frequently where I open the editor and then realize I needed an extension to do what I wanted to work on, meaning I have to close that editor, go to a separate website, and click a magic link to re-open the editor with the extension I needed. I think we should just always show the extension menu button and have a submenu to load in any (official) extension that isn't currently loaded.

I know we discussed this before and the issue was how to unload extensions (e.g., when switching to a different project), but we can always just reload the page if that's needed (e.g., don't allow unloading extensions unless you switch projects, in which case reload the page when switching), or better yet we can just add a method for the Extension abstract class that requests it stop any background tasks it launched (after which we can delete the blocks anywhere they were used, with the same confirmation prompt that deleting a custom block uses).

Save extensions in the project

We really really need something that addresses this. Without this, opening up a specific project that uses an extension presents the user with a bunch of generic Obsolete! blocks. It's then a matter of trial and error to figure out what extension they were supposed to be from, as absolutely no information is shown to the user (it doesn't even warn them that there was an undefined block when loading).

I think we need to change it so that (at least official) extensions are saved as urls in the project xml and loaded up when the project is opened (unloading any loaded extensions that weren't used, as per the previous point). We would also need to do this when switching to a new project after e.g., accepting a role invite. Otherwise you need external communication to instruct the invitee on how and which extensions to load in a new editor before they can be invited without error. But that would come naturally from saving extensions in the project, as it's basically an open operation plus linking them in a room.

Importantly, if we do this then we can simply delete the ultra long &extensions=[...] portion of the url after the page is loaded, as the magic link is no longer relevant to the user or to the shareability of the project.

Make extensions backwards compatible

Currently, every non-cosmetic change to the block interface of an extension (other than adding entirely new blocks with an internal name that has never been used before) is a breaking change for all projects that used it. We should be able to add a deprecated flag to a block def that allows it to be hidden from the block palette but still render correctly and function if present in old projects (i.e., no Obsolete blocks).

Address namespacing issues

This is less important, but we should probably namespace extension blocks so they can't conflict. I can imagine multiple extensions having a block like isConnected or something basic like that. We can just take the metadata returned by the extension and prepend the extension's class name to each block like MyExtension_isConnected. For existing projects, we can scrape the db and update any extension blocks that were used to the new namespaced version, or we can add handlers for the un-namespaced versions that attempt to find an unambiguous namespaced definition (or else error).

[gsteinLTU]

I was looking through these, deprecated shouldn't be needed, they only need to not be in the palette.

[dragazo]

Ah, that's true. We still need a way to actually remove the blocks eventually (otherwise the music project would be riddled with more deprecated blocks than not), but semver could cover that. It's really just down to the assets problem.