-
Notifications
You must be signed in to change notification settings - Fork 18
Description
Svelte4 -> Svelte5
This is a large issue, many changes to the syntax of svelte has been made, most notably the introduction of runes.
Another good reason for this migration is that both performance improves and it will make it easier to introduce React adapters suitable for anyone who wishes to extend the project functionality.
Investigation
The usage of Readable and Writable interfaces makes the transition very difficult. The stores abstraction is the coupling point for all controllers, and have been very instrumental in getting easy access to global state, however it's also very tighly coupled to the svelte interfaces.
To separate the different components a few changes will be made. Each system will be put into either the core, backend or frontend. The backend isn't a separate service but serves as the separation of the state, logic and interface.
Reactive UI should tap into a framework-agnostic pubsub system with adapters in-between, adapters can then be used to implement framework specific reactivity
-
Stores.ts should be gradually dissintegrated, replaced with framework agnostic abstractions
-
Any tools or utility that's applicable to most scenarios should be put into the core
-
Any fundamental application logic should be put into the backend
- The backend is separated into 3 layers, the interface, application, domain and infrastructure layers. This is a very common layered architecture, borrowed from hexagonal architecture
-
Svelte UI elements should be put into the frontend
- Interactions with the application logic, should happen in the interface layer of the backend.
Tasks
- Add a pubsub system for reactive states (infrastructure / interface) - Command-query style pattern
- Add an event publishing service
- Add LiveData to the pubsub state
- Remove LiveData from stores
- Move micro:bit handlers to controllers
- The UI shouldn't depend on this, but depend on a microbit or data controller instead
- Remove svelte translation from filter implementations
- Move feature toggle into backend
Comments
Try to keep away from introducing the concept of pages and navigation. Ideally the backend should just consider all pages to be open all of the time and data should flow across pages