Repository navigation
feat: figure out UI definitions, as well as whether to send UI definitions from serverside to clientside and let modules on the clientside determine when and how to render some of them #2
Description
no clue how this should be done but I don't want to require modules for absolutely everything, so I would like to somehow let the server send the client UI shit to render on it's own with buttons that send stuff to the server onclicked
Activity
DexrnZacAttack commentedon Aug 13, 2026
I think what I'll do is allow the server to send the client basic widget definitions
the client will hold a service that builds those definitions into avalonia objects, and also allow modules to add their own builders.
the server will also be able to send pages and such, and when buttons are clicked the client will just ask the server to do something, sometimes involving telling the client to do something again.
the only concern I have is the speed of this system, because what if the user is farther away from the server and has like upwards of 300ms ping... I would have to try to cache some stuff and maybe add some smarter helpers (like some PageButton that switches the page before calling to the server to refresh data for it...)
DexrnZacAttack commentedon Aug 13, 2026
okay I'm thinking to let the server send the client a keyed widget, the client won't give a shit about keeping it in sync and will render it regardless but the server will push updates for these widgets with their ID...
this should allow the UI to stay fast and keep the amount of control that it should have for arbitrary scanner types.
flow would be like create widget -> update widget -> (at the end) delete widget
wip!: SSR, scanner sync, fixes, refactors, use latest Shiki
Merge pull request 'feat: implement websockets, start a little on aud…