3 ms·

A lot of people in the Rust community (yours truly including) are trying to work out how to build UI frameworks in this paradigm. It's a really interesting ques

A lot of people in the Rust community (yours truly including) are trying to work out how to build UI frameworks in this paradigm. It's a really interesting question, if anyone has any good input, I'm alll ears.

fsociety 6y ago
Modern React/Relay with GraphQL fragments does this semi-well I think. Sources of data include the fragment in their GraphQL query and can blindly pass that to components which depend on it. That lets you re-use components quickly and easily. Changing the downstream component which consumes the fragment just requires changes in that component and nothing else.
- adamnemecek 6y ago
  Modern React meaning Hooks?
  - fsociety 6y ago
    I like Hooks a lot but I’m not sure how it’d apply in the Rust UI sense (maybe well, maybe not). It is nice to not be forced into building classes and to also ensure that specific state changes will force partial re-renders. I’m talking more about https://relay.dev/docs/en/fragment-container https://relay.dev/docs/en/fragment-container. Creating opaque types that can be fetched from a data source and passed off to a child component is more what I am thinking of. I mention it because I recall working on a Qt product where you have to parse data from a source, then you bring it throughout your program and try to keep it in the right form for every UI component that uses it. It was easy for the project but we had no composability of components. With fragments, you don’t really care and duplication of data between fragments on the same source of data generally just works. That way you can pass the fragments to each component as required. The idea behind that being that, you can have “efficient” and opaque data structure received from a data source which can be blindly passed to a component to consume. I say data source but in this instance I mean GraphQL... so maybe it doesn’t apply to a generic UI library.
eyesee 6y ago
I'm not in the Rust community, but it seems like one could have their cake and eat it too, using OOP with DOD storage. * Use a special allocator for objects which reserves a vector slot from your structure-of-arrays. * Objects records are offsets instead of pointers * Object definition includes getter/setters which index the columnar vectors * Store fields declared 'columnar' in a value vector. This could even give flexibility to group columns for locality where needed, and allow ancillary data to be stored in a "leftover" struct.
- adamnemecek 6y ago
  Yes, generational arena allocations are very popular. The larger question is more about the application architecture. Like where does one handle user input? Where does rendering happen? Etc.

fsociety 6y ago

Modern React/Relay with GraphQL fragments does this semi-well I think. Sources of data include the fragment in their GraphQL query and can blindly pass that to components which depend on it. That lets you re-use components quickly and easily. Changing the downstream component which consumes the fragment just requires changes in that component and nothing else.

adamnemecek 6y ago
Modern React meaning Hooks?
- fsociety 6y ago
  I like Hooks a lot but I’m not sure how it’d apply in the Rust UI sense (maybe well, maybe not). It is nice to not be forced into building classes and to also ensure that specific state changes will force partial re-renders. I’m talking more about https://relay.dev/docs/en/fragment-container https://relay.dev/docs/en/fragment-container. Creating opaque types that can be fetched from a data source and passed off to a child component is more what I am thinking of. I mention it because I recall working on a Qt product where you have to parse data from a source, then you bring it throughout your program and try to keep it in the right form for every UI component that uses it. It was easy for the project but we had no composability of components. With fragments, you don’t really care and duplication of data between fragments on the same source of data generally just works. That way you can pass the fragments to each component as required. The idea behind that being that, you can have “efficient” and opaque data structure received from a data source which can be blindly passed to a component to consume. I say data source but in this instance I mean GraphQL... so maybe it doesn’t apply to a generic UI library.

eyesee 6y ago

I'm not in the Rust community, but it seems like one could have their cake and eat it too, using OOP with DOD storage. * Use a special allocator for objects which reserves a vector slot from your structure-of-arrays. * Objects records are offsets instead of pointers * Object definition includes getter/setters which index the columnar vectors * Store fields declared 'columnar' in a value vector. This could even give flexibility to group columns for locality where needed, and allow ancillary data to be stored in a "leftover" struct.

adamnemecek 6y ago
Yes, generational arena allocations are very popular. The larger question is more about the application architecture. Like where does one handle user input? Where does rendering happen? Etc.