dec5c76bfd
This pull request introduces significant improvements to the TeaTui framework, focusing on error handling, functional purity, and codebase simplification. Most notably, it removes the dependency on `color-eyre`, introduces custom error types for each actor (effects, events, update, view), and updates the API to encourage pure functions and more idiomatic Rust error handling. The example app and documentation are also updated to reflect these changes. **Framework error handling and API improvements:** * Introduced custom error types (`EffectsError`, `EventLoopError`, `UpdateError`, `ViewError`, and unified `ProgramError`) for each actor, replacing the use of `color-eyre` and providing clearer, structured error reporting throughout the framework. [[1]](diffhunk://#diff-1a8ddf10086f54de37be278b04f140fea42a9dd9314ebed509a03510b34a3043L2-R24) [[2]](diffhunk://#diff-dd43168709f1ba547c9dbe210d659222793384f540898dfa4159d3d28447ea59L2-R14) [[3]](diffhunk://#diff-717c070f88e33e75d62e17bcfb063657cc2cbba2198d8faf77fb3855206ba036L2-R51) [[4]](diffhunk://#diff-348239946b2211ffea21e1282dde8299ee0e5484616b8b2da9c97589719531e4L2-R23) [[5]](diffhunk://#diff-eaa72a947a5cb60aaed20788a77b8c3b94606a2b4bd9218fa2bbeeba0a98f726L34-R62) * Updated the core `start` function to accept an `init_fn` initializer, and to use the new error types in its signature and internal logic, ensuring all errors are properly propagated and handled. [[1]](diffhunk://#diff-eaa72a947a5cb60aaed20788a77b8c3b94606a2b4bd9218fa2bbeeba0a98f726L61-R95) [[2]](diffhunk://#diff-eaa72a947a5cb60aaed20788a77b8c3b94606a2b4bd9218fa2bbeeba0a98f726L88-R157) * Refactored the `Update` enum and related logic to use a single variant (`Next(M, Option<E>)`) for state transitions and side effects, simplifying the update pattern and removing the need for multiple variants. **Example application and dependency updates:** * Updated the counter example to remove `color-eyre`, use the new error types, and conform to the new pure function API (no more `Result` returns from user functions). [[1]](diffhunk://#diff-d1e739029fa7deef7dec36d183f1097a4ed266898520ddae449cff9c91f65a96L1-R10) [[2]](diffhunk://#diff-d1e739029fa7deef7dec36d183f1097a4ed266898520ddae449cff9c91f65a96L96-R111) [[3]](diffhunk://#diff-d1e739029fa7deef7dec36d183f1097a4ed266898520ddae449cff9c91f65a96L128-R129) [[4]](diffhunk://#diff-d1e739029fa7deef7dec36d183f1097a4ed266898520ddae449cff9c91f65a96R38-R42) * Updated dependencies in `Cargo.toml` files: removed `color-eyre`, bumped `ratatui` version, and added `thiserror` for error handling. [[1]](diffhunk://#diff-2e9d962a08321605940b5a657135052fbcef87b5e360662bb527c96d9a615542L11-R12) [[2]](diffhunk://#diff-c6fd35fe7c3e8bcfcf9e60f261503d791b528405f92b6ba99f7272e91939d861L9) [[3]](diffhunk://#diff-1cd61e14e7d516bb58a3b2607848174d38c432631899f34dbc88076158f3bf52L10-R12) **Documentation:** * Added a comprehensive project overview and architecture description for TeaTui in `AGENTS.md`, explaining the functional philosophy, actor model, and usage guidelines. |
||
|---|---|---|
| .github | ||
| examples/counter | ||
| teatui | ||
| .gitignore | ||
| AGENTS.md | ||
| Cargo.lock | ||
| Cargo.toml | ||
| LICENSE | ||
| README.md | ||
TeaTui
Tea = The Elm Architecture
This is an experimental project that aims to build an Elm-like framework for TUI development in Rust on top of Ratatui.
My main motivation to build this was to understand if I could structure a Ratatui application in an Elm-like fashion.
The provided templates from the Ratatui official sources write code in a very procedural way, abusing of mutability a bit too much for my taste. (That is, using &mut all over the place in function arguments).
I want to minimize the usage of mutability and build the most pure functional TUI apps that I can.
I feel that Elm has always been a great example to follow when it comes to building frontend in a pure-functional style, and so I will try to reproduce it in here.
How does it work
The state of your application is represented by a single type called the Model.
The Model will be used by a view process to render a View.
A separate process will read events from the outside world and
send them to an update process.
The update process will take the model and an event and
return a new model, potentially also returning a side effect.
The updated model will be sent to the view, triggering a new render
based on the new state of the application.
If any side effects are returned from update, they will be processed
in a separate process.
If the process responsible for handling side effects wants to update
the state of the application, it will send a message to the update process.
The users of this framework only need to provide:
-
An update function that given a model and a message return an
Updateinstance. -
A view function that given a reference to the model, returns a
View -
An effects function that given a reference to the model and an effect, might perform any side effects and optionally return a message to update the state of the application
Examples
You can find a folder with example projects in the examples folder.
License
This project is licensed under the MIT license (LICENSE or http://opensource.org/licenses/MIT)