Architecture
Architecture walkthrough video: https://youtu.be/yGThvRorXtI
Timestamps:
- 00:00 Intro
- 00:31 How visual editing works
- 01:25 How Onlook understands your code
- 01:59 How to set up for your project
- 03:01 The Onlook app architecture
- 04:23 Directory structure
- 05:45 Other technical details
- 06:48 Outro
Previous walkthrough video
Typical electron architecture with an extra web view that holds the users' page
app ────┐ > Onlook app
|
├─┬ electron
| |
│ ├─┬ main > Main Node process
│ │ └─── index
| |
│ └─┬ preload > Injected scripts
| |
│ └─── browserview > React front-end entry point
| |
│ └─── webview > The window inside of canvas
|
└─┬ src > React front-end
├── routes
└── lib
demos ──┐ > Demo projects with Onlook setup for supported frameworks
│
├── babel
├── next
├── astro > (Not officially supported
├── remix
└── webpack
plugins ┐ > Plugin library to instrument projects
│
├── babel
└── next
docs ──── > Docs React app
cli ───── > Npx script for setup
backend ─ > Supabase backend
Onlook is technically a browser that points to your localhost running the app. It can manipulate the DOM like a Chrome Devtool, and all these changes are injected into the page through a CSS stylesheet or DOM manipulation. The changes are non-persistent until written to code.
To translate the changes to code, we inject an attribute into the DOM elements at build-time that points back to the code like a sourcemap. The attribute gives us the location of the code block, and the component scope [1]. We then find the code, parse it into an AST, inject the styles, then write it back.
This technique is framework agnostic as we can swap in a different compiler for another framework[2]. It can work for any codebase as we’re just using open standards that don’t require any custom code. The code generated is written directly into your codebase, locally, so you can always take the output without being locked-in to the tool.
All the changes made are stored as actions. This allows them to be serialized, stored, and reproduced. We did it this way so eventually we can introduce online collaboration or letting an agent generate actions. To do this, we’d just need to serve the locally running page and resolve incoming actions.