}
}
```
In the above example, we're annotating CounterModel with
leptos_tea::Model, which will derive a few important things:
```rust
// Original struct, stays as-is
struct CounterModel {
counter: usize,
}
// Model passed to the update function
struct UpdateCounterModel {
counter: RwSignal,
}
// model passed to the component when you call .init()
struct ViewCounterModel {
counter: ReadSignal,
}
impl CounterModel {
// Initializes everything and starts listening for messages.
// Msg::default() will be send to the update function when
// called
fn init(
self,
cx: Scope,
update_fn: impl Fn(UpdateCounterModel, &Msg, Cmd),
) -> (ViewCounterModel, SignalSetter) {
/* ... */
}
}
```
You first need to create your CounterModel, however you'd like.
In this case, we're using Default. Then you call .init(),
which will return a tuple containing the read-only model, as well
as a SignalSetter, which allows you to do msg_dispatcher(Msg::Blah)
on nightly, or msg_dispatcher.set(Msg::Blah) on stable.
And that's how this crate and state management approach works.
Model nesting
Models can be nested inside one another like thus:
```rust
[derive(leptos_tea::Model)]
struct Model {
#[model]
inner_model: InnerModel,
}
[derive(leptos_tea::Model)]
struct InnerModel(/* ... */);
```
Important Node : Although this can be done, it is not
recommended, because it leads to nested .update()/.with
calls for each level of nesting. Instead, try and break out each
nested model into it's own independent model, view, update. Nevertheless,
sometimes this isn't desired or worth it, so the option is there in case
you need it.
Limitations
leptos_tea::Model currently only supports tuple and field structs.
Support will be added soon.
License: MIT