Skip to content

Latest commit

 

History

History
40 lines (31 loc) · 4.12 KB

ARCHITECTURE.md

File metadata and controls

40 lines (31 loc) · 4.12 KB
Raw

AEON Sketchbook Architecture

This document gives a general rationale behind the chosen architecture and technologies.

Technologies

  • Overall, we rely primarily on Rust, TypeScript and HTML/CSS. We use less as a CSS pre-processor and posthtml as a HTML pre-processor.
  • Dependencies for Rust are managed through cargo (obviously), while the JS part is managed by npm, because it's the default choice almost everywhere.
  • The connection between the Rust back-end and the TypeScript front-end is facilitated using tauri.
  • To build TypeScript and less, we use Vite. It is not a particularly mainstream choice, but it is officially recommended by Tauri, so hopefully it will give us the best compatibility.
  • To help with the UI, we use UIkit. It seems to be reasonably popular, stable, and above all simple (i.e. just sensible widgets, no special framework logic, templates, etc.).

Overall, you should be able to work with the source code comfortably from Visual Studio Code, although IntelliJ IDEA may be preferable for the Rust portion.

Project structure

  • vite.config.ts | Configuration for the Vite build system (HTML/JS/CSS processing). Most stuff is generated by Tauri, there's just some extra code related to properly building UIKit and to declaring multiple entry points for different windows.
  • tsconfig.json | Configuration for the TypeScript compiler. Generated by Tauri for now. Later we might want to make it a bit more restrictive.
  • package.json | List of npm dependencies. Mostly just Tauri, UIkit, Less, PostHTML and some packages with types declarations.
  • src | The HTML/JS/CSS frontend:
    • uikit-theme.less | A Less file where you can place all custom overrides and hooks for the UIkit widgets. If this grows too much, we should create a theme folder with Less files and split the overrides into per-widget files.
    • styles.less | Other relevant styling unrelated to UIkit. Again, if this grows too much, feel free to refactor it into something like styles folder.
    • main.ts | The entry point for all JavaScript code. Later we'll probably want different entry points for different windows, but for now it's just a single file.
    • html/window.html | The default HTML "wrapper" that is extended by individual windows. Later, we'll probably need to add other wrappers for things like dialog windows.
    • html/component | A preliminary home for the HTML files of self-contained components.
    • html | Other HTML content goes here. For now, this includes various windows.
    • assets | Any images/icons/whatever.
  • src-tauri | The rust backend: 
    • tauri.conf.json | Mostly default Tauri config. Might need tweaking once we start working more with windows.
    • cargo.toml, build.rs and src | Mostly standard Rust project.

Architecture notes

Since this is very early in the project, these are mostly just ideas regarding how things should work:

 - Each window has a data structure which maintains it's whole state in Rust. The reason why this is in Rust is that this data structure might include (a) detached windows or (b) dialogs, in which case it might actually span multiple physical windows.  - We should be able to completely serialise this window state in order to "save" the state of the program.  - The JS/TS front-end sends "input events" which are reflected in the Rust state, which then sends "display events" to the frontend to actually update the contents of inputs. This is similar to what we did in Pythia. It is a bit worse in terms of performance, but should be manageable.  - Each event that changes the internal state should be also saved into an undo/redo stack based on which events can be replayed or reversed.  - The UI consists of self-contained "components". Each component should  only span a specific sub-tree of HTML elements. However, a component can have sub-components. Ideally, sub-components can be detached into separate windows, with a placeholder in the original location.