12 releases
0.2.6 | Oct 22, 2023 |
---|---|
0.2.3 | Sep 10, 2023 |
0.2.2 | Apr 21, 2023 |
0.2.1 | Mar 6, 2023 |
0.1.3 | Nov 6, 2022 |
#408 in Rust patterns
55 downloads per month
76KB
465 lines
Context
R3BL TUI library & suite of apps focused on developer productivity
We are working on building command line apps in Rust which have rich text user interfaces (TUI). We want to lean into the terminal as a place of productivity, and build all kinds of awesome apps for it.
-
🔮 Instead of just building one app, we are building a library to enable any kind of rich TUI development w/ a twist: taking concepts that work really well for the frontend mobile and web development world and re-imagining them for TUI & Rust.
- Taking things like React, JSX, CSS, and Redux, but making everything async (they can be run in parallel & concurrent via Tokio).
- Even the thread running the main event loop doesn't block since it is async.
- Using proc macros to create DSLs to implement CSS & JSX.
-
🌎 We are building apps to enhance developer productivity & workflows.
- The idea here is not to rebuild tmux in Rust (separate processes mux'd onto a single terminal window). Rather it is to build a set of integrated "apps" (or "tasks") that run in the same process that renders to one terminal window.
- Inside of this terminal window, we can implement things like "app" switching, routing, tiling layout, stacking layout, etc. so that we can manage a lot of TUI apps (which are tightly integrated) that are running in the same process, in the same window. So you can imagine that all these "app"s have shared application state (that is in a Redux store). Each "app" may also have its own Redux store.
- Here are some examples of the types of "app"s we want to build:
- multi user text editors w/ syntax highlighting
- integrations w/ github issues
- integrations w/ calendar, email, contacts APIs
r3bl_redux
This crate is related to the first thing that's described above. It provides lots of useful functionality to help you build TUI (text user interface) apps, along w/ general niceties & ergonomics that all Rustaceans 🦀 can enjoy 🎉:
redux
Store
is thread safe and asynchronous (using Tokio). You have to implement async
traits in order
to use it, by defining your own reducer, subscriber, and middleware trait objects. You also have to
supply the Tokio runtime, this library will not create its own runtime. However, for best results,
it is best to use the multithreaded Tokio runtime.
Once you setup your Redux store w/ your reducer, subscriber, and middleware, you can use it by
calling spawn_dispatch_action!( store, action )
. This kicks off a parallel Tokio task that will
run the middleware functions, reducer functions, and finally the subscriber functions. So this will
not block the thread of whatever code you call this from. The spawn_dispatch_action!()
macro
itself is not async
. So you can call it from non async
code, however you still have to provide a
Tokio executor / runtime, without which you will get a panic when spawn_dispatch_action!()
is
called.
Middlewares
Your middleware (async
trait implementations) will be run concurrently or in parallel via Tokio
tasks. You get to choose which async
trait to implement to do one or the other. And regardless of
which kind you implement the Action
that is optionally returned will be dispatched to the Redux
store at the end of execution of all the middlewares (for that particular spawn_dispatch_action!()
call).
-
AsyncMiddlewareSpawns<State, Action>
- Your middleware has to usetokio::spawn
to runasync
blocks in a separate thread and return aJoinHandle
that contains anOption<Action>
. A macrofire_and_forget!
is provided so that you can easily spawn parallel blocks of code in yourasync
functions. These are added to the store via a call toadd_middleware_spawns(...)
. -
AsyncMiddleware<State, Action>
- They are will all be run together concurrently usingfutures::join_all()
. These are added to the store via a call toadd_middleware(...)
.
Subscribers
The subscribers will be run asynchronously via Tokio tasks. They are all run together concurrently
but not in parallel, using
futures::join_all()
.
Reducers
The reducer functions are also are async
functions that are run in the tokio runtime. They're also
run one after another in the order in which they're added.
⚡ Any functions or blocks that you write which uses the Redux library will have to be marked
async
as well. And you will have to spawn the Tokio runtime by using the#[tokio::main]
macro. If you use the default runtime then Tokio will use multiple threads and its task stealing implementation to give you parallel and concurrent behavior. You can also use the single threaded runtime; its really up to you.
-
To create middleware you have to implement the
AsyncMiddleware<S,A>
trait orAsyncMiddlewareSpawns<S,A>
trait. Please read theAsyncMiddleware
docs for examples of both. Therun()
method is passed two arguments: theState
and theAction
.- For
AsyncMiddlewareSpawns<S,A>
in yourrun()
implementation you have to use thefire_and_forget!
macro to surround your code. And this will return aJoinHandle<Option<A>>
. - For
AsyncMiddleware<S,A>
in yourrun()
implementation you just have to return anOption<A>>
.
- For
-
To create reducers you have to implement the
AsyncReducer
trait.- These should be
pure functions
and simply return a new
State
object. - The
run()
method will be passed two arguments: a ref toAction
and ref toState
.
- These should be
pure functions
and simply return a new
-
To create subscribers you have to implement the
AsyncSubscriber
trait.- The
run()
method will be passed aState
object as an argument. - It returns nothing
()
.
- The
Summary
Here's the gist of how to make & use one of these:
- Create a struct. Make it derive
Default
. Or you can add your own properties / fields to this struct, and construct it yourself, or even provide a constructor function.- A default constructor function
new()
is provided for you by the trait. - Just follow how that works for when you need to make your own constructor function for a struct w/ your own properties.
- A default constructor function
- Implement the
AsyncMiddleware
,AsyncMiddlewareSpawns
,AsyncReducer
, orAsyncSubscriber
trait on your struct. - Register this struct w/ the store using one of the
add_middleware()
,add_middleware_spawns()
,add_reducer()
, oradd_subscriber()
methods. You can register as many of these as you like.- If you have a struct w/ no properties, you can just use the default
::new()
method to create an instance and pass that to theadd_???()
methods. - If you have a struct w/ custom properties, you can either implement your own constructor
function or use the following as an argument to the
add_???()
methods:Box::new($YOUR_STRUCT))
.
- If you have a struct w/ no properties, you can just use the default
Examples
💡 There are lots of examples in the tests for this library and in this CLI application built using it.
Here's an example of how to use it. Let's start w/ the import statements.
/// Imports.
use async_trait::async_trait;
use r3bl_rs_utils::redux::{
AsyncMiddlewareSpawns, AsyncMiddleware, AsyncReducer,
AsyncSubscriber, Store, StoreStateMachine,
};
use std::sync::{Arc, Mutex};
use tokio::sync::RwLock;
- Make sure to have the
tokio
andasync-trait
crates installed as well asr3bl_rs_utils
in yourCargo.toml
file.- Here's an example
Cargo.toml
.
Let's say we have the following action enum, and state struct.
/// Action enum.
#[derive(Debug, PartialEq, Eq, Clone)]
pub enum Action {
Add(i32, i32),
AddPop(i32),
Clear,
MiddlewareCreateClearAction,
Noop,
}
impl Default for Action {
fn default() -> Self {
Action::Noop
}
}
/// State.
#[derive(Clone, Default, PartialEq, Debug)]
pub struct State {
pub stack: Vec<i32>,
}
Here's an example of the reducer function.
/// Reducer function (pure).
#[derive(Default)]
struct MyReducer;
#[async_trait]
impl AsyncReducer<State, Action> for MyReducer {
async fn run(
&self,
action: &Action,
state: &mut State,
) {
match action {
Action::Add(a, b) => {
let sum = a + b;
state.stack = vec![sum];
}
Action::AddPop(a) => {
let sum = a + state.stack[0];
state.stack = vec![sum];
}
Action::Clear => State {
state.stack.clear();
},
_ => {}
}
}
}
Here's an example of an async subscriber function (which are run in parallel after an action is dispatched). The following example uses a lambda that captures a shared object. This is a pretty common pattern that you might encounter when creating subscribers that share state in your enclosing block or scope.
/// This shared object is used to collect results from the subscriber
/// function & test it later.
let shared_object = Arc::new(Mutex::new(Vec::<i32>::new()));
#[derive(Default)]
struct MySubscriber {
pub shared_object_ref: Arc<Mutex<Vec<i32>>>,
}
#[async_trait]
impl AsyncSubscriber<State> for MySubscriber {
async fn run(
&self,
state: State,
) {
let mut stack = self
.shared_object_ref
.lock()
.unwrap();
if !state.stack.is_empty() {
stack.push(state.stack[0]);
}
}
}
let my_subscriber = MySubscriber {
shared_object_ref: shared_object_ref.clone(),
};
Here are two types of async middleware functions. One that returns an action (which will get
dispatched once this middleware returns), and another that doesn't return anything (like a logger
middleware that just dumps the current action to the console). Note that both these functions share
the shared_object
reference from above.
/// This shared object is used to collect results from the subscriber
/// function & test it later.
#[derive(Default)]
struct MwExampleNoSpawn {
pub shared_object_ref: Arc<Mutex<Vec<i32>>>,
}
#[async_trait]
impl AsyncMiddleware<State, Action> for MwExampleNoSpawn {
async fn run(
&self,
action: Action,
_store_ref: Arc<RwLock<StoreStateMachine<State, Action>>>,
) {
let mut stack = self
.shared_object_ref
.lock()
.unwrap();
match action {
Action::MwExampleNoSpawn_Add(_, _) => stack.push(-1),
Action::MwExampleNoSpawn_AddPop(_) => stack.push(-2),
Action::MwExampleNoSpawn_Clear => stack.push(-3),
_ => {}
}
None
}
}
let mw_example_no_spawn = MwExampleNoSpawn {
shared_object_ref: shared_object_ref.clone(),
};
/// This shared object is used to collect results from the subscriber
/// function & test it later.
#[derive(Default)]
struct MwExampleSpawns {
pub shared_object_ref: Arc<Mutex<Vec<i32>>>,
}
#[async_trait]
impl AsyncMiddlewareSpawns<State, Action> for MwExampleSpawns {
async fn run(
&self,
action: Action,
store_ref: Arc<RwLock<StoreStateMachine<State, Action>>>,
) -> JoinHandle<Option<Action>> {
fire_and_forget!(
{
let mut stack = self
.shared_object_ref
.lock()
.unwrap();
match action {
Action::MwExampleSpawns_ModifySharedObject_ResetState => {
shared_vec.push(-4);
return Action::Reset.into();
}
_ => {}
}
None
}
);
}
}
let mw_example_spawns = MwExampleSpawns {
shared_object_ref: shared_object_ref.clone(),
};
Here's how you can setup a store with the above reducer, middleware, and subscriber functions.
// Setup store.
let mut store = Store::<State, Action>::default();
store
.add_reducer(MyReducer::new()) // Note the use of `::new()` here.
.await
.add_subscriber(Box::new( // We aren't using `::new()` here
my_subscriber, // because the struct has properties.
))
.await
.add_middleware_spawns(Box::new( // We aren't using `::new()` here
mw_example_spawns, // because the struct has properties.
))
.await
.add_middleware(Box::new( // We aren't using `::new()` here
mw_example_no_spawn, // because the struct has properties.
))
.await;
Finally here's an example of how to dispatch an action in a test. You can dispatch actions in
parallel using spawn_dispatch_action!()
which is "fire and forget" meaning that the caller won't
block or wait for the spawn_dispatch_action!()
to return.
// Test reducer and subscriber by dispatching `Add`, `AddPop`, `Clear` actions in parallel.
spawn_dispatch_action!( store, Action::Add(1, 2) );
assert_eq!(shared_object.lock().unwrap().pop(), Some(3));
spawn_dispatch_action!( store, Action::AddPop(1) );
assert_eq!(shared_object.lock().unwrap().pop(), Some(4));
spawn_dispatch_action!( store, Action::Clear );
assert_eq!(store.get_state().stack.len(), 0);
Other crates that depend on this
This crate is a dependency of the following crates:
r3bl_rs_utils
crates (the "main" library)
Issues, comments, feedback, and PRs
Please report any issues to the issue tracker. And if you have any feature requests, feel free to add them there too 👍.
Dependencies
~15–26MB
~247K SLoC