Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add integration for the Blocks Editor #92

Merged
merged 5 commits into from
Jan 28, 2022

Conversation

rvanasa
Copy link
Contributor

@rvanasa rvanasa commented Jan 24, 2022

This PR adds a lightweight integration for building and deploying canisters from the Blocks Editor.

When the integration=blocks query parameter is present, Motoko Playground will listen for serialized JSON messages from http://localhost:* or https://blocks-editor.github.io/* parent windows. This makes it possible for Blocks to preload the workplace automatically (rather than copying/pasting everything and clicking the "Deploy" button).

@chenyan-dfinity, does this look good to merge? We also updated the package-set.dhall upstream URL and removed a deprecated CLI flag in dfx start in order to get the project working with the latest DFX version. Let us know if you think it would be worth splitting these into a separate PR or anything like that.

Cheers!

@chenyan-dfinity
Copy link
Contributor

Thanks for the PR. We try to make playground as generic as possible. It would be great if you can design an interface that is not tied to the blocks editor. There are several options:

  • Commit the code into a github repo, and load with ?git query. Extending this to support gist may fit with your use case.
  • Use the saved canister to save code: https://github.com/dfinity/motoko-playground/blob/main/service/saved/Saved.mo#L55, then use ?tag query.
  • Your PR seems to be a good solution for temporary code transfers. I'm happy to merge it if you remove mention of the blocks-editor, and provide it as a generic code transfer service.

@rvanasa
Copy link
Contributor Author

rvanasa commented Jan 25, 2022

Sounds good to me. We updated the PR to make this concept available for other third-party applications with similar use cases.

I still think it makes sense to (at least initially) include a cross-origin whitelist to minimize the surface area of possible vulnerabilities, especially once Motoko Playground includes wallet-related features (e.g. #46). The updated implementation allows cross-window access from localhost environments, and developers could submit PRs adding their production webapp URLs to src/integrations/allowedOriginPrefixes.js in the short term.

The system also requires editor={uid} (instead of integration=blocks) to be present in the URL for end-user transparency.

Does this seem like a reasonable compromise to preserve the original level of security while making the system more general?

Thanks for the alternate suggestions. We initially explored using the sharing / tag feature for loading projects; this integration will provide a significant UX improvement for our particular use case (and hopefully for other projects as well).

Copy link
Contributor

@chenyan-dfinity chenyan-dfinity left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mostly LG.

src/App.tsx Outdated
const hasUrlParams = !!(
urlParams.get("git") ||
urlParams.get("tag") ||
urlParams.get("editor")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe post? I think this is similar to the post message.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure; I switched to editor to post in the latest commit. The value of this query parameter corresponds to a unique ID defined by the external application in order to distinguish from other message sources (such as HMR).

return;
}

// Validate and parse integration message
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's worth documenting the format and protocol being used here, and how to call this from the client,
so that other apps can use it. Seems you are prepending a message before the JSON, and reply the ack number back to the client.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added a section to the Readme. Is this what you were imagining? I'll also do another documentation pass once the protocol has been fully worked out.

src/components/Editor.tsx Show resolved Hide resolved
src/integrations/editorIntegration.ts Show resolved Hide resolved
src/integrations/editorIntegration.ts Outdated Show resolved Hide resolved
Copy link
Contributor

@chenyan-dfinity chenyan-dfinity left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

@rvanasa
Copy link
Contributor Author

rvanasa commented Jan 27, 2022

Awesome, thank you! Looking forward to seeing this in production.

@chenyan-dfinity chenyan-dfinity merged commit c74174b into dfinity:main Jan 28, 2022
@chenyan-dfinity
Copy link
Contributor

Deployed

@rvanasa
Copy link
Contributor Author

rvanasa commented Jan 28, 2022

Thank you! The integration works as expected.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants