Big changes towards version 1.0

[PsichiX]

Hello, RAUI users and followers!

During last year i've been collecting requests and feedback about RAUI, both from users and during my use of it, and i have been doing research on how we can solve these problems for 1.0 version. Here is what i have came up with, let's discuss it:

Passing data to and from RAUI application

Since RAUI relies heavily on data transformations, just like React does, we do pass data to RAUI app as Props along with root widget.
This works fine when RAUI app is the host of an application, which in case of games isn't necessarily true - i would even say, more often it's just one another game system. This makes difficult to pass arbitrary data to RAUI app, especially when integrating it with ECS.

For some time i've been working with Unreal's ViewModel system that solves this problem quite nicely.
How it works:
User creates ViewModel object that serves either as data storage or interface to some data storage and this ViewModel is accessed by both game and UI, so whenever user updates ViewModel (parts of it), it leaves notification about what particular change happened, then UI widgets that listen for given ViewModel changes, updates their view using ViewModel to read data from or writing into it.

This sound like DataBindings we have right now, but the goal is to bring ergonomics of binding data to widgets, which DataBinding doesn't have right now - at the moment DataBinding has to be passed as Props with root widget, which then has to be passed down the widget tree to the widget that actually needs it.

What i, and i think users too, expect it to do is more along these lines:
User creates shared ViewModel object, registers it into RAUI application (not passing it via Props), then whatever widget wants to interact with ViewModel, it just tells RAUI it will get updated when given notification arrives, while user can also interact with it from the game side. When it comes to ECS, ViewModel could do queries over the world.

This means we completely replace DataBindings with ViewModel that gets integrated into RAUI internals instead of being something external to RAUI as DataBinding somewhat is at the moment. This might also entirely replace concept of Signals and Messages, or rather unify all of three into single ViewModel.
The goal is to aim as much as possible to how Unreal's MVVM solves this problem, to ensure data bindings between game and UI is as much ergonomic as possible.

STATUS: Shipped in version: 0.40.0 🚀

Performance

Performance issues has source in two reasons:

• RAUI app updates goes through entire widget tree, no matter what widget actually needed a change.

To solve entire tree problem we will implement Virtual DOM mechanism, that will detect the common root widget of all widgets that changed, either by their state or by ViewModel notification, and will only render widgets in that common root hierarchy, nothing else.
That's standard in reactive UI libraries that sadly haven't been implemented so far, and this is about the time to finally add that to RAUI.

Macros and DSL hell

This had to happen sooner or later - we are gonna completely get rid of macros in favor of builder pattern. We started with custom DSL for defining widgets only because we wanted to have analog of JSX in RAUI, but that only confused users and forced them to look at docs and examples constantly whenever they needed to work with UI tree. That was one of the biggest architecture failures carried on because no real useful reason and no real help being provided by its existence, while builder pattern is easier to use, has much less comprehensive complexity, integrates well with code completion like Rust Analyzer, and is understood by Rust users.
I apologize for introducing custom DSL into the workflow in the first place, this should not ever happen and i am happy to finally remove it completely.

STATUS: Shipped in version: 0.46.0 🚀

Rendering integration

RAUI suffers from being too simple with its rendering - it's fine if you only want to do colored or textured rectangles and text, but for games there is more often need for custom rendering like for example canvas, or even just any shapes and curves. This cannot be done without changing its rendering architecture and i've found out that this can be solved with immediate mode rendering.

The idea is that widget renderable is no more defined by primitive, instead it allows for providing immediate mode rendering context to instruct it how to render widget, this produces renderable commands buffer that later is being executed by various renderers. It also means, user could render its UI without reactive layer of RAUI, just fill commands buffer with what we want to render and where - again, better modularization in the spirit of RAUI goals.

This approach changes how we structure RAUI architecture:

• Renderables engine is used to define how to produce visuals for the UI.
• Layout engine is used to convert widget tree into spatial representation for Renderables engine.
• Renderer engine is used to convert widget tree into final visuals using layout, instructing Renderables engine.

License

This one is short and quite simple: MIT license is fine, but i would want to make it MIT/Apache2 to comply to ecosystem standard for open source permissive Rust libraries, to add bit of protection layer against malicious abuse of the sources.

STATUS: Shipped in version: 0.43.0 🚀

---

Expected RC version is planned in later Q4, more likely close to December (i will test these changes till the end of the year with Oxygengine and Tetra).

I hope you will find proposal of these changes interesting, if you have any thoughts or questions, ask in comments and i hope i wil be able to give best answers i can :)

[PsichiX]

removed props allocation section because of source being really old laptop setup i had problems on - allocation performance leave barely noticeable trace on upgraded machine, still considered old, but not a toaster anymore, so problem is no more needed to be solved 🎉

[PsichiX]

here is first draft of View-Model API:
https://gist.github.com/PsichiX/0c7a99f80afd8827baeab42b968b206c

[PsichiX]

Example of View-Model in RAUI:
https://gist.github.com/PsichiX/0e280f29b5d21e5b4d7502fa6422244b

[PsichiX]

Version 0.40.0 with View-Model support landed! 🎉

Next task to do is Virtual-DOM, where we will re-render only those widgets that were actually changed.

[PsichiX]

While building game editor, i've came into the conclusion, that entire text field / text input widget should be turned into stateless, or have a stateless variant.
Right now text field work on cached string, which is fine when input field is the only source of truth for given widget data, but it makes working with it much complicated, when widget should be actually a view over external data, for example: game/app stores string in View Model or something similar.
What i and probably users too do imagine, it should work rather like this: input field should use externally provided string via props to render, then every NavSignal should do some work on that external data to mutate it, and avoid caching it, so if user types text, that change should change external string data and trigger widget refresh.
The $1000 question is: how to abstract that change over string data so it can be provided via props and mutated via props in a hook? Maybe some trait object used as interface? Or we should reuse Managed values (that came from Intuicio dependency)? Managed value is limiting ways user can provide reference to string data source this widget will work on. Trait object will be storage-agnostic, which means however users provides a reference to data, that's not a problem of widget itself. Additionally trait can provide standardized read and write methods, which means we could inject widget refresh and any other notification into write method.