SWC is written in Rust and will hopefully improve build time and CI significantly.

• Try to replace ts-loader/ts-jest by SWC, see https://github.com/swc-project/swc-loader and https://github.com/swc-project/jest.
• Enable ESM support for jest
• Try if switching compilation/transpiling from ts-jest to SWC allows the testing of Monaco Editor, therefore finishing PR #20

Implement loading of a .json file as part of the FE

This will allow ink! Playground/Rust Analyzer to provide error correction/syntax hightining and auto-completion for ink dependencies/sourcecode.

• Implement loading it Typescript and passing as string to RA

• Since the file which contains the ink! Dependencies is approx 50mb large (however, only 5mb gzipped), it would be nice to optimize the way in which it is loaded. Possible approaches:

  • Split into chunks
  • Stream the JSON and batch process it

• Implement a compile functionality / endpoint for the Backend. Makes use of the sandbox.rs file from Issue #63 .
• Check https://github.com/achimcc/ink-backend and https://github.com/integer32llc/rust-playground for inspiration.
• Add unit tests (if possible, probably without actually running the compilation in Docker), check how tests are organised in Rust Playground.

• When the compile button becomes available at the Frontend, implement Async functions whcih can be called for Compilation requests.
• The same concept should be extendable to the sharing functionality.
• Check https://kentcdodds.com/blog/how-to-use-react-context-effectively#what-about-async-actions for an acceptable approach
• Tests are mandatory. Mock the backend services for unit tests

Implement React Context.

The different funcitonalities of the app, especially the Terminal/Messaging and the Darkmode require a shared global state solution.

We will use React Context now for simplicity since it shipd with react.

• Implement React Context together with a good and scalable solution for seperating state/context/types/async actions.
• Context should make use of useReducer hook and provide dispatch to its consumers.
• For async action consider the solution which is discussed here: https://kentcdodds.com/blog/how-to-use-react-context-effectively#what-about-async-actions
• Since the funcitonality related to async actions is currently not implemented (Gists Creation/Sharing, Compile), add a dummy async action
• Provide tests

Prettier/rustfmt should run on CI, so we don't accidentally merge differently formatted source files.

Improve GitHub CI:

• forbid direct push to main
• can we forbid merge commits by CI?

• this will improve stability, thread safety, typization and hopefully performance
• consider the usage of https://threads.js.org/ or https://github.com/GoogleChromeLabs/comlink - ThreadsJs has the nicer features (observables/reactive programming) but Google provides a Demo on how to combine wasm-pack with Comlink: https://github.com/GoogleChromeLabs/wasm-bindgen-rayon/tree/main/demo

• https://github.com/rust-analyzer/rust-analyzer/blob/64bf67c5aa096eb6a059d6bb8304981ecb90318e/crates/project_model/src/project_json.rs is more or less a serialization of CrateGraph. Add this data structure to RA wasm (the project_model crate wont compile to wasm)
• make RA wasm capable of converting the json into a 'CrateGraph'

Define an optimized Color Scheme in Monaco for Tokens delivered by Rust Analyzer

Rust analyzer returns a set of Tokens for Syntax Highlightning. Assign individuakl colors to those Tokens which are inspired byb the Color Scheme which Visual Studio Code uses together with its Rust Analyzer Plugin:

• Collect a list of Tokens returned by Rust Analyzer for ink! Smart Contracts
• Assign the matching colors to these Tokens
• Implement the derived Color Scheme, look e.g. at this example for inspiration

Mapping of tag -> token is handled in /packages/playground/src/compnents/Editor/utils/configureLanguage.ts by the function fixTag

See https://code.visualstudio.com/blogs/2017/02/08/syntax-highlighting-optimizations for further details

The colors should be aligned with the !ink branding. Take Figma design and further input from the designer into account.

• Tailwind color palette
• Custom Primereact theme
• Custom monaco theme

The project currently references Rust Analyzer Version 0.0.72.

We should upgrade to Version 0.0.77.

Will have some small breaking changes which needs to be fixed.

• Generate required change.json file during the build process
• Add Rust Analyzer to WASM
• Add rust Analyzer to the Monaco Client:
  roughly follow https://github.com/rust-analyzer/rust-analyzer-wasm/blob/master/www/index.js and https://github.com/achimcc/rust-analyzer-react-
  typescript/blob/main/www/workers/createRa.ts.
• Should be strongly typed and reafactored into several JS files
• Should use Comlink Plugin for Webworker instantiation and Proxying

The Settings Switch from the Header menu should toggle the global dark mode over Context state.

• Can we use https://tailwindcss.com/docs/dark-mode functionality and trigger change by the Context darkmode boolean?
• Don't define indivivual colors allo ver the app, define Primary/Secondary/Tertiary Colors for Dark and for Bright in Tailwind Config.
• Add tests for switchin between dark/bright mode.

The current README contains to much information about architectural decisions. At the same time, it is not clear what precisely the getting started isntrucitons will lead to (building all packages/crates and starting the webserver).

• provide a better description of how to use all the provided crates/packages.
• create a ARCHITECTURE.md file and move the architectural part of the current README there. Add the image depicting the build flow and if neccessary other architectural information. For inspiration, see: https://matklad.github.io/2021/02/06/ARCHITECTURE.md.html
• Would be gre4at to also have a CONTRIBUTE.md file with a contribution guideline, especially for external contributors, but also to reflect on our own practices.

Maybe a bit silly, but the obvious did not work:

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    let opts: Opts = Opts::parse();
    let port = opts.port;
    let frontend_folder = opts.frontend_folder;
    let host = "127.0.0.1";

    if !Path::new(&frontend_folder).is_dir() {
        panic!("{} is not a valid directory.", frontend_folder);
    }

    print!("before: Backend server running at {}:{}", host, port);

    HttpServer::new(move || {
        App::new()
            .wrap(
                middleware::DefaultHeaders::new()
                    .header("Cross-Origin-Opener-Policy", "same-origin")
                    .header("Cross-Origin-Embedder-Policy", "require-corp"),
            )
            .service(serve_frontend(&frontend_folder))
            .route("/compile", get().to(manual_hello))
    })
    .bind(format!("{}:{}", host, port))?
    .run()
    .await?;

    print!("after: Backend server running at {}:{}", host, port);

    Ok(())
}

Both messages are logged before the process terminates (e.g. user hits Ctrl+C)

rustfmt can be compiled to WASM. Compile it to wasm and provide Browser/WASM based code formatting for Playrgound. For inspiration see:

• https://github.com/alexcrichton/rustfmt-wasm
• https://alexcrichton.github.io/rustfmt-wasm/

Check the currently used Dockerfile:

https://github.com/achimcc/ink-backend/blob/main/compiler/Dockerfile

Used by https://github.com/achimcc/ink-backend/blob/main/src/sandbox.rs to compile ink! Smart Contracts to WASM

Try to opmtimize the build performance. Currently the build process slows down drastically if the genereated Dockerimage is > 1 day old.

(!) Docker commands should be changed to be executed as non-root user for securioty concerns

Is Caching possible in the build process? Keep in mind that concurrent builds should be possible. Check if https://github.com/paritytech/cachepot is useful.

Tasks:

• Change to non root user: https://dzone.com/articles/docker-without-root-privileges
• Evaluate usage of cachepot: https://github.com/paritytech/cachepot
• Evaluate other performance optimizations

We found out that clap can parse environment variables as well, so we don't need those extra dependencies.

And the refactoring is a minor task as we already have a working pattern in the create_change CLI.

Add a general App Layout. Inspect the Figma Layout for inspiration. Style only in dark mode first.

• Might make sense to add a Template Component which receives Header, Terminal, Editor as Props (?)
• The Terminal should be resizable, https://www.primefaces.org/primereact/showcase/#/splitter can be used for this. The current Icon/Button that ships with the Splitter component is to small. Replace it with something more visible, so that users don't miss the resize feature of the Terminal.
• The header component should be left empty for this issue, it is an individual one.
• The current Prototype has the animated Status bar. Since this is redundant with the Terminal, we skip the Status Bar for a first iteration. Keep in mind that the Terminal messages should be somehow animated instead...
• Add tests, at least Snapshot tests for ful page rendering.

Add basic Monaco Webeditor (without Rust Analyzer) to the Frontend/Webpack Repo

Explore different options:

• custom component
• usage of prebuild React component: https://github.com/react-monaco-editor/react-monaco-editor
• usage of Monaco Webpack plugin

Keep in mind that the appearance of Monaco should be customizable (Light/Dark Mode, numbering, display minimap).

Explore different strategies to speed up initial loading of Monaco Webeditor, check https://medium.com/@ollelauribostr/dynamic-imports-speeding-up-the-initial-loading-time-of-webassembly-studio-9f50b975472a for inspiration.

Further inspiration regarding a custom setup and to learn basics about LSP can be found here: https://betterprogramming.pub/create-a-custom-web-editor-using-typescript-react-antlr-and-monaco-editor-part-1-2f710c69c18c
and here:
https://betterprogramming.pub/create-a-custom-web-editor-using-typescript-react-antlr-and-monaco-editor-bcfc7554e446

In the Prototype, the sharing functionality is provided by creating Github Gists. This works, but it relies on the Server and also on GitHub servers. A more decentralised solution would be great.

• Explore options to save Contract Code on ipfs instead of in GitHub Gists.
• Can we do this from within the broswer without requiring a user login?
• Can we use https://www.textile.io/ for this? This would be the best solution, since it is already used in Contracts Explorer.
• Or other tools, possibly: https://thegraph.com/en/ ?

Implement a Terminal component. For inspiration, see: https://github.com/achimcc/ink-playground-frontend/tree/comlink/www/components/Terminal. Feedback from our UX designer

@erler : The Status bar is redundant, would be great to have animated messages as part of the terminal. It is important that they are animated, due to potentially long loading times of the app.

• Scroll Bar should look better as in the prototype and should be aligned with Monaco Editor scroll bar.
• Implement a message Format together with a message array in Context. So that messages can be dispatched to the Context. The Message Format should carry an enum for Serverity (Info/Success/Error realted to colors) and fields for Prompt Text (Or an Enum which identifies the message dispatcher) and Message text.
• Implement a Terminal component which receives messages from Context and renders them.
• Add a concept for animated messages
• (!) Add tests for dispatch and appearance of messages

For inspiration: https://kentcdodds.com/blog/use-react-error-boundary-to-handle-errors-in-react

• Add handling of rednering errors in React
• Use https://github.com/bvaughn/react-error-boundary
• Add tests that check correct error handling

Initiate a new wasm Project
The initial structure for the Playground/UI crate:

• use wasm-pack for this: https://github.com/rustwasm/wasm-pack
• add a custom React Webpack project
• add Implementation of a small sample function
• add rayon and bindgen-rayon to the rust source, expose init thread pool
• add wasm-pack-plugin to webpack
• add comlink and run the function which is expozed by wasm-pack through a Webworker
• add tests by jest and wasm-pack

Compilation of the the .wasm file should already be cached after initial load of twe App.

But it seems to be possible to prevent even the re-compilation of the WASM file on every page visit: https://v8.dev/blog/wasm-code-caching

Try to imprment this to optimize load performannce when re-visiting.

We have a hybrid monorepo, containing rust crates and ts packages (currently only one).

Technically it's ok if crates have the same name as ts packages. But I'd suggest to avoid this.

Concretely: one of crates/playground and packages/playground should be renamed.

Running cargo run -p crate-extractor -- create worked out only after upgrading to 1.55

We currently have some duplication in the tmp directory setup in the backend tests for static file delivery.

https://github.com/paritytech/ink-playground/blob/main/crates/backend/src/main.rs#L67
https://github.com/paritytech/ink-playground/blob/main/crates/backend/src/main.rs#L87
https://github.com/paritytech/ink-playground/blob/main/crates/backend/src/main.rs#L107

Tailwind should be available in the Frontend UI Repo for styling

Here is the result of the Jest testing:

 FAIL  __tests__/Editor.test.tsx
  ● Test suite failed to run

    src/components/WasmTest/Wasm.tsx:7:44 - error TS1343: The 'import.meta' meta-property is only allowed when the '--module' option is 'es2020', 'esnext', or 'system'.

    7     new Worker(new URL('./wasm.worker.ts', import.meta.url), {
                                                 ~~~~~~~~~~~

 FAIL  __tests__/Welcome.test.tsx
  ● Test suite failed to run

    src/components/WasmTest/Wasm.tsx:7:44 - error TS1343: The 'import.meta' meta-property is only allowed when the '--module' option is 'es2020', 'esnext', or 'system'.

    7     new Worker(new URL('./wasm.worker.ts', import.meta.url), {
                                                 ~~~~~~~~~~~

Test Suites: 2 failed, 2 total
Tests:       0 total
Snapshots:   0 total
Time:        63.12 s, estimated 90 s

Implement Header with Popup Buttons similar to the Prototype

• Use these provided ink! Logos: ink_logos.zip
• Take the design from Figma into account
• The compile/ Share Buttons should be mocked for now.
• Add tests, also for Opening menus/clicking buttons.

In the prototype, the ink! dependencies which are contained ion the Change.json file are received by calling fetch() to obtain them from the Netlify server after the initial page-load. This can take up to 2 min. Are there ways to improve the loading speed, like:

• Load them from another server?
• Split the file into multiple smaller files?
• Stream the .json file
• Directly subscribe to stream of JSON data instead of transferring file(-s)?

The Change.jsonm file is currently fetched, however, it is approx. 50 MB big (~5MB gzipped teransfer volume). It is probably not cached for long due to its size? Are there ways to more persistently cache this data?

Another approach whhcihs should be considered to improve the performance of loading and applying the Change.json file, is to fetch the data through Comlink Webworkers and to pass them to another Webworker thread which executes rust analyzer, see e.g.:

https://issueexplorer.com/issue/GoogleChromeLabs/comlink/450

Explore different Rust Web Frameworks:

• Rocket
• Actix Web
• Gotham
  Implement one of them which serves the current state of the UI as a https Webserver.

This Crate is inteded to grow into a full backend service which provides options for Smart Contract Compilation and Code Sharing/Gist Creation

Tasks:

• Create new backend crate
• Create running http server
• Serve frontend repo through http server
• Implement COOP/CORS headers for enabled SharedArrayBufferAccess/WebWorkers: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer
• Configure file paths thorugh environment variables
• Add basic rust tests

Since multiple packages/contributions are involved in the project, we should have a makefile/buildscript which builds all connected components in the required order.

This is the flow of the build process:

Therefore, the makefile should:

• (1) build crate extractor, which depends on change_json
• (2) run crate extractor on a ink project to generate the required change.json
• (3) build the wasm dependencies from the playground crate
• (4) build the frontend project, which uses the wasm deondencies from (3) and the change.json file from (2)
• (5) build the backend, which uses the Frontend code from (4)

Create a (de-serializable) data structure 'ChangeJSON' for ink-dependencies/rust projects

Should allow to convert the Change object into a ChangeJson object which is (de-)serializable and vice-versa

• First define a JSON structure for the CrateGraph which is the most complex part of Change
• Add (de-)serializable structures for the remaining parts of Change: roots and files_changed
• Implement ChangeJson by utilizing the structures from Step 1 and Step 2

Currently in CI we're using two different rust toolchains. nightly for fmt and stable for clippy.

Can we unify them?

For inspiration: https://blog.saeloun.com/2020/08/04/how-to-investigate-your-build-size-in-webpack.html

• add https://github.com/webpack-contrib/webpack-bundle-analyzer to dev dependencies
• research config for Monaco Editor to reduce bundle size
• research configs for Tailwind CSS

Consider usage of: https://github.com/fsubal/irontail

• Currently, rust-analyzer CLI tools can read a rust-project.json file, but not of creating those files. Implement it.
• Contribute this new functionality as a PR to Rust Analyzer (refer to https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Frust-analyzer/topic/Wasm.20version.20of.20Rust.20Analyzer)

https://martinfowler.com/bliki/GivenWhenThen.html

Add a CLI command for Rust Analyzer or write a small extension of Rust Analyzer

• the CLI command creates 'RustProject' for a provided Cargo.toml path
• serializes it and writes it into a .json file
• optional: add a read option to the CLI tool for consistency checking of the JSON file
• optional: add a subcommand which allows to split the .JSON file into multiple smaller files

The Playground should load as fas as possible, providing only a very basic monaco editor, dsiplaying the Smart Contract Sourcecode.

As much code as possible should be seperated and lazy loaded through web-workers. For inspiration:

For inspiration:

https://medium.com/@ollelauribostr/dynamic-imports-speeding-up-the-initial-loading-time-of-webassembly-studio-9f50b975472a

Add rust Analyzer to the Monaco Client
Add the Frontend implementation of Rust Analyzer WASM WebWorkers.

• Should be strongly typed and refactored into several JS files
• WASM Webworkers should be started and proxied by using Comlink plugin
• See https://github.com/achimcc/ink-playground-frontend/blob/comlink/www/components/Editor/utils/startRustAnalyzer.ts and https://github.com/achimcc/ink-playground-frontend/blob/comlink/www/components/Editor/workers/worker.ts

Create wasm version of Rust Analyzer

don't Copy & Paste the React/JS code from the Project

This should provide the Rust implementation which compiles to WASM.

• use source code of wasm version of RA: https://github.com/rust-analyzer/rust-analyzer-wasm
• make it compile with the latest version of RA (check https://github.com/achimcc/rust-analyzer-react-typescript/tree/main/src for hints)
• Provide Rayon based concurrency/multithreading, where possible. See https://web.dev/webassembly-threads/ for an introduction to the topic.
• Add tests for the provided wasm functions.

Parse the ink dependencies which are received as a JSON file by #1 and load them into RA

• RA should receive a string as part of its LSP functionalities
• deserialize the string into a 'RustProject' struct
• Create a 'Change' object out of the deserialized struct and apply it to RA base_db

In the current PR #14 the playground crate is a hybrid repo containing the rust code together with the WASM/JS bindings as well as the Frontend code. Refactor the structure so that the Frontend part obtains its own separate folder.

Consider:

• wasm-pack build plugin should still work, that means that editing rust sourcecode should recompile the frontend when executing yarn start
• testing setup (wasm-pack test folder and jest tests) as well as github CI should still be functional after refactoring