I have built a handful of applications starting with visual basic and Java Applets. I have been working on a React app for the past two years.
In my view, so much of a UI is dealing with state in ways that is truly unique to what a UI requires. I love working with types in Rust and Haskell; this said, I also really like working with React very much because we use it in conjunction with Redux. With the recent advent of hooks I believe the combined use of the technology provides the most elegant way of managing state in a UI context.
The framework does a great job of having us distinguishes when we are engaging:
- pure-functions (input determines output for all of the possible inputs)
- effects where the return value depends on some hidden/broader access to state
- effects that mutate state (e.g., may not return anything :: input -> void)
... in addition to distinguishing when we are engaging a sync versus async effect.
Understanding the above has been critical to augmenting the intent in our designs and the consequences of our choices; concrete implementations of how to proceed in a more robust, streamlined manner (this often means understanding what edge cases we need to consider to ensure we are defining a complete function, i.e., handles the complete domain of inputs).
Unlike the backend code, in the frontend UI we often don't have control over the sequence of events... the user does (this is at least generally true). In my experience, ad-hoc code (code with lots of if else statements ) is not a sustainable way to manage chaos. The long-term approach involves managing chaos with order. This is where the react-redux pairing has taken the UI implementation to a whole new, sustainable level.
There is some boiler-plate to which I would comment: boiler-plate is not always a bad thing. In fact given what the real challenge is, managing chaos (user-directed changes in state and user-directed commands to compute), the boiler-plate is a welcome attribute. Hear me out, what boiler-plate exists, is more a welcome rhythm that clearly articulates our intent and understanding of how the user interaction impacts state in context of all that is going on in the app (a rhythm to manage chaos). An accountant uses a ledger to track money; entries are made in several locations (e.g., cash flow, income statement and balance sheet) in a repeatable, rote manner that ensures the balance sheet... balances. Said differently, communication by repetition is not always a bad thing.
All this to say, there is a lot to steal from what has made the react-redux combination so pleasant to work with. The framework augments my understanding of the task; it does not get in the way of accomplishing the task.
In summary
A successful UI framework may benefit by considering the following:
- UI rendering in a standard and flexible way is key; something like React components go a long way here
- UI introduces specific challenges in how to manage state - chaotic in that we don't have control, the user does. Redux forces order in how we define the UI state-machine:
- think and manage information in a strict sequence (user event -> dispatch -> update state -> display/render state using child components with props that accomplishes read-only access to state)
- be more thoughtful and articulate in how we are implementing our state machine over time and increasing complexity.
- Types are useful a la typescript but likely even more so with Rust.
- Embraces the benefits of functional programming:
- declarative code to address chaotic UI state (imperative can become a slave to state that only exacerbates the chaos)
- explicit use of pure versus other functions with effects (useful inventory, decomposition and compartmentalization of the chaos)
- composable (re-use of code to address a wide range of chaotic states; express an infinite set of states with combinations or reusable code/components)
- associative (be sequence independent to manage sequence dependent state machines)
- Carves out specific UI state management use-cases when to exploit the benefits of the OO and imperative rust attributes.
I hope this helps scope what the specification might want to include in a next generation UI library for Rust.
- E
