Scratch in editor #1312
Open
Scratch in editor #1312
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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
zetter-rpf
had a problem deploying
to
previews/1312/merge
GitHub Actions
Failure
zetter-rpf
temporarily deployed
to
previews/1312/merge
GitHub Actions
Inactive
This is just an empty project for now 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.
zetter-rpf
force-pushed
the
scratch-in-editor
branch
from
092aa7c to
0dde409
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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