✨ feat: standalone extension manager

[alexcui03]

Description

Proposed Changes

Test Coverage

Additional Context

[cloudflare-workers-and-pages]

Deploying clipcc-preview with    Cloudflare Pages

Latest commit:	02f6866
Status:	✅  Deploy successful!
Preview URL:	https://2c8f3097.clipcc-preview.pages.dev
Branch Preview URL:	https://feat-extension-ng.clipcc-preview.pages.dev

View logs

[SimonShiki]

add -> remove

[alexcui03]

fixed

[SimonShiki]

should call extensionManager's refreshInfo(), or the extension block's locale won't get changed. also not seen in gui

[alexcui03]

updated in 1a84c8a, vm's {get,set}Locale method is marked as deprecated since it is only used for translating extensions' blocks. i consider to implement that feature in extension manager.

btw, currently all extensions uses vm's format-message. the package used in vm and extension manager should be same version, to ensure that they share the same instance. later, builtin extensions should be splited from vm to solve the problem.

[SimonShiki]

consider add theme support for extension blocks, like what handleExtensionAdded did

[alexcui03]

implemented in b0cf2b9

[SimonShiki]

1. check if extension manager is available before access in VM, like installTargets and shareBlocksToTarget
2. Current implementation drops load extension from url (?
3. If worker fails, pendingWorker never get recycled correctly

[alexcui03]

1. check if extension manager is available before access in VM, like installTargets and shareBlocksToTarget
2. Current implementation drops load extension from url (?
3. If worker fails, pendingWorker never get recycled correctly

For 1: vm-related methods should be invoked after vm-manager-hoc is mounted. it should work fine. there is a problem that vm.initialized is not a property of vm, but assigned by vm-manager-hoc, then some methods might be invoked before vm is actually initialized due to React's lifecycle, like setLocale called in Blocks.

For 2: extension manager loads an extension from its adapter. it should be able to load original scratch extensions from url with worker adapter.

For 3: see 02f6866, idk whether i understood the problem correctly.

[SimonShiki]

1. check if extension manager is available before access in VM, like installTargets and shareBlocksToTarget
2. Current implementation drops load extension from url (?
3. If worker fails, pendingWorker never get recycled correctly

For 1: vm-related methods should be invoked after vm-manager-hoc is mounted. it should work fine. there is a problem that vm.initialized is not a property of vm, but assigned by vm-manager-hoc, then some methods might be invoked before vm is actually initialized due to React's lifecycle, like setLocale called in Blocks.

For 2: extension manager loads an extension from its adapter. it should be able to load original scratch extensions from url with worker adapter.

For 3: see 02f6866, idk whether i understood the problem correctly.

For 1, VM should work without extension manager. installTargets get called during deserialization, need to check whether functions that related to extensions would break

[alexcui03]

1. check if extension manager is available before access in VM, like installTargets and shareBlocksToTarget
2. Current implementation drops load extension from url (?
3. If worker fails, pendingWorker never get recycled correctly

For 1: vm-related methods should be invoked after vm-manager-hoc is mounted. it should work fine. there is a problem that vm.initialized is not a property of vm, but assigned by vm-manager-hoc, then some methods might be invoked before vm is actually initialized due to React's lifecycle, like setLocale called in Blocks.
For 2: extension manager loads an extension from its adapter. it should be able to load original scratch extensions from url with worker adapter.
For 3: see 02f6866, idk whether i understood the problem correctly.

For 1, VM should work without extension manager. installTargets get called during deserialization, need to check whether functions that related to extensions would break

It seems that installTargets will only use extension manager when there exists a block from extension. Running a project with extension blocks but without a manager to load these extensions should be invalid.