2 stable releases
2.0.0 | Oct 12, 2024 |
---|---|
1.0.0 | Nov 13, 2021 |
#491 in #automatic
1,229 downloads per month
Used in 13 crates
(via tuirealm)
15KB
54 lines
tuirealm_derive
~ Automatically implements MockComponent ~
Get started · tui-realm · Documentation
Developed by @veeso
Current version: 2.0.0 (12/10/2024)
About tuirealm_derive 👑
tuirealm_derive is a crate which implements the procedural macro MockComponent
which can be used to automatically implement
the MockComponent
trait for a tui-realm Component
.
Indeed, as you already know if you're a tui-realm user, you've got two kind of component entities:
- MockComponent: generic graphic component which is not bridged to the application and is "reusable"
- Component: which uses a MockComponent as "backend" and is bridged to the application using the Event -> Msg system.
The Component wraps the MockComponent along with additional states. Such as:
pub struct IpAddressInput {
component: Input,
}
impl MockComponent for IpAddressInput {
...
fn state(&self) -> State {
self.component.state()
}
...
}
impl Component<Msg, UserEvent> for IpAddressInput {
fn on(&mut self, ev: Event<UserEvent>) -> Option<Msg> {
let cmd: Cmd = match ev {
...
};
match self.perform(cmd) {
...
}
}
}
Since Component
MUST implement MockComponent
, we need to implement the mock component trait too, which in most of the case it will just call the MockComponet methods on the inner component
field. This is obviously kinda annoying to do for each component. That's why I implemented this procedural macro, which will automatically implement this logic on your component.
So basically instead of implementing MockComponent
for your components, you can just do as follows:
#[derive(MockComponent)]
pub struct IpAddressInput {
component: Input,
}
impl Component<Msg, UserEvent> for IpAddressInput {
...
}
With the directive #[derive(MockComponent)]
we don't have to implement the mock component trait.
❗ In order to work, the procedural macro requires you to name the "inner" mock component as
component
as I did in the example.
If we give a deeper look at the macro, we'll see that what it does is:
impl MockComponent for IpAddressInput {
fn view(&mut self, frame: &mut Frame, area: Rect) {
self.component.view(frame, area);
}
fn query(&self, attr: Attribute) -> Option<AttrValue> {
self.component.query(attr)
}
fn attr(&mut self, query: Attribute, attr: AttrValue) {
self.component.attr(query, attr)
}
fn state(&self) -> State {
self.component.state()
}
fn perform(&mut self, cmd: Cmd) -> CmdResult {
self.component.perform(cmd)
}
}
Get started 🏁
In order to get started with tuirealm_derive all you need to do is to add tui-realm to your dependencies and enable the derive
feature if needed.
If you're using the default features:
[dependencies]
tuirealm = "^2"
If you're not using the default features, be sure to enable the derive feature:
[dependencies]
tuirealm = { version = "^2", default-features = false, features = ["derive", "crossterm"] }
⚠️ tuirealm_derive requires tui-realm >= 2.0.0; the old API is not supported
Then you need to include tuirealm in your project using the macro use
directive:
src/lib.rs
#[macro_use]
extern crate tuirealm;
and finally derive MockComponent
on your components:
#[derive(MockComponent)]
pub struct MyComponent {
component: MyMockComponentImpl,
}
❗ In order to work, the procedural macro requires you to name the "inner" mock component as
component
as I did in the example.
And ta-dah, you're ready to go 🎉
Support the developer ☕
If you like tui-realm and you're grateful for the work I've done, please consider a little donation 🥳
You can make a donation with one of these platforms:
Changelog ⏳
View tuirealm_derive's changelog HERE
License 📃
tuirealm_derive is licensed under the MIT license.
You can read the entire license HERE
Dependencies
~240–690KB
~16K SLoC