Scratch in editor#1312
Conversation
092aa7c to
0dde409
Compare
mwtrew
left a comment
There was a problem hiding this comment.
Looks good!
I did notice that if you "Add a file" it throws an error because the new project type key hasn't been added to an object. Not expecting that to work at the moment, but perhaps the new project type is needed elsewhere.
| setStageSize, | ||
| } from "@scratch/scratch-gui"; | ||
|
|
||
| const ScratchIntegrationHOC = function (WrappedComponent) { |
There was a problem hiding this comment.
As we discussed, I think it might be possible to use a "boundary" component and hooks here instead of a class-based HOC (which is not the fashion these days), but it's probably best left for now because we know this piece of code works elsewhere.
This approach is similar to the one taken by Experience CS. The scratch.jsx, scratch.scss and ScratchIntegrationHOC.jsx as well as the scratch build are all taken from the experience CS repo with minimal changes. We're not using all parts of the integration yet, but expect we will need it. I've chosen to use the the public build of scratch for now as it was the simplest to set up. Many of the changes we previously relied on have been merged into main, but it's possible we may need use a fork or patch behaviour around loading and saving projects. I've kept scratch and the editor using the same package.json and webpack config for now. This makes it simpler to get started and run and build the projects. In the future there may be value in splitting these out as it would allow us to use different versions of tools (react/redux) between them
This is just an empty project for now We've chosen to use 'code_editor_scratch' rather than just 'scratch' as the project identifier so we don't conflict with the existing experience cs scratch. I've chosen to use srcDoc to embed the iframe to avoid the need of serving the contents of the iframe. If we want the iframe to be in the same domain as the project, the project including the web component would need to serve it. As far as I can tell, srcDoc doesn't have any limitations that would affect us, but if it does we have alternatives: + Set up an a page that can host the iframe contents in each project that wants to use Scratch + Permanently hosting the iframe contents at a known subdomain, e.g. code-editor-scratch.raspberrypi.org and handling the complexities of cross domain iframes.
This stops some images 404ing such as the icons used in some of the blocks. This approach was copied from the experience CS repo. I've set assetHost so the assets are loaded from the deployed web component site rather than relative to the project.
This test makes sure that scratch is rendering by checking the 'Go' button (green flag). We might want to update it to test more interesting behaviour later.
0dde409 to
6c3c1b5
Compare
Thanks for the spot! I'll add to the todo list. |
Closes https://github.com/RaspberryPiFoundation/digital-editor-issues/issues/1135
Add Scratch into editor, using a similar approach to experience CS. See commits for details
This will just visible to people looking at the test page, not anyone using the code editor.
This doesn't yet handle any project loading or saving which which will be added separately. See outstanding tasks.
Screenshot