search

urbit / shrub

An operating function (Prototype)
https://urbit.org
MIT License
29 stars 2 forks source link

Sky: Revise UI Framework #91

Closed tiller-tolbus closed 3 weeks ago

tiller-tolbus commented 2 months ago

Current implementations of /con files to render UIs are hacky and unwieldy. Many use-cases, like %messenger, will lie to the underlying system about what it is rendering in order to resolve an impedance mismatch between the "type" of a node being converted and the actual data that is being rendered in the UI. Because of this, we have instances of /con files lacking generality in their application to the actual type they represent -- for example, /con/task-htmx does not actually work on any arbitrary node with a pro/task in its state, but rather assumes a great deal about the rest of the node's API.

What's desired is an extension to the build system that, rather than working based on the type of the state of the node being operated on, works on the API definition of the root node as well as its kids. The design problems extending from this involve making the type constraints in the Shrubbery build system transparent to the UI developer. For example, if the system is aware of a [quay lore] that specifies a back-end data structure to be rendered in a UI, the developer should come as close as possible to typed Hoon values that they can operate on off the bat, rather than axals and pails that need to be unpacked.

will-hanlen commented 1 month ago

i think we can call this done