RFC: sandbox/playground for QA/training/sales

[twschiller]

Goals/Purpose

An environment replicating different situations that occur in websites in the wild

• Training environment: stable place for learning different skills
• Sales demo environment: mimic internal tools (e.g., CRMs, etc.)
• QA environment: replicate different conditions on web sites. For both manual QA and automated QA (e.g., with Selenium or Rainforest QA, or other tools)

Requirements

• Backend: for Turbolinks/Turbo: https://github.com/hotwired/turbo
• Isolated front-end versions: multiple versions of React, Ember, Vue, etc. Paired with different state management libraries
• Mimic screens/interactions of common business tools
• Isolated URL roots for testing different front-end router implementations
• No restart/cold start time

Examples of Cases to Cover

• Major frameworks: React with Redux, React with MobX, Vue, Ember
• Ruby with Turbolinks (navigation event occurs before page content changes)
• Infinite scroll
• Site with hotkeys enabled

Business Apps to Mimic

• CRM
• Ticketing system
• BPM forms
• Project Management

Open questions / considerations

• Is it worth having a backend? We'd need it for Turbolinks? Static admin interfaces, e.g., Django admin? We probably need affordances for multiple backends (Ruby vs. Django)
• Are JS modules at a point where we don't even need to bundle them? We could just reference the CDN directly from the page (e.g., using https://unpkg.com/)
• Repository structure: have as a separate AGPLv3 repository from the extension. Categorized by major framework, sub-organized by combination

Prior Art

• https://replit.com/@PixieBrixTodd/ReactSandbox Our current sandbox, implemented as a Repl
• TodoMVC: https://todomvc.com/ (implementations of a simple TODO app in different frameworks)

[fregante]

I think it's easier to handle each page completely independently, especially if multiple frameworks and versions are involved, we don't want to have to mess with a global bundler/system for that.

Possible solution:

1. One folder per "case" or similar cases
2. Publish the whole repo to GitHub Pages or similar
3. If necessary, allow each "case" to handle its own bundling/publishing to a separate URL/host

Advantages:

• Static projects are immediately available on the GitHub Pages URL
• No host/bundling setup required
• No forced maintenance of a "global" system
• Parcel bundler allowed per-case, when/if necessary
  • Parcel makes it easy to bundle whole "apps" without much config, but it's best to have one per case/project, or else it's even more painful than webpack to setup

Examples:

• https://github.com/fregante/webpack-sandbox
  • Each folder in this repo has its own webpack config. When I change or add a folder, I definitely won't affect other projects nor do I have to update them, ever

---

Side note: For very simple situations, I also have this testing ground customizable via URL: https://fregante.github.io/pixiebrix-testing-ground/Parent?iframe=./Child&iframe=./Other

I'm using it on the Messenger for the automated testing: https://github.com/pixiebrix/webext-messenger/commit/1827186a854b3febe3d44bb031f674019860c7cc

[fregante]

• Is it worth having a backend? We'd need it for Turbolinks? Static admin interfaces, e.g., Django admin? We probably need affordances for multiple backends (Ruby vs. Django)

This could be one of the "cases" in a subfolder. This specific case would handle its own deployment via GitHub Actions

• Are JS modules at a point where we don't even need to bundle them? We could just reference the CDN directly from the page (e.g., using unpkg.com)

Sort of! unpkg serves raw files as they appear on npm; They only work if they're pre-packaged as UMD. I think Skypack is the "smart" CDN for this use case.

[fregante]

Example set up here: https://github.com/pixiebrix/playground

Default page available at: https://pixiebrix.github.io/playground/example/

More subfolders can be added by anyone who wants to create custom cases for their tests.