Document how the state of a Component can be managed
This commit is contained in:
parent
e9e8e83cca
commit
2367f7863a
1 changed files with 13 additions and 0 deletions
|
|
@ -31,6 +31,19 @@ use std::rc::Rc;
|
||||||
///
|
///
|
||||||
/// Additionally, a [`Component`] is capable of producing a `Message` to notify
|
/// Additionally, a [`Component`] is capable of producing a `Message` to notify
|
||||||
/// the parent application of any relevant interactions.
|
/// the parent application of any relevant interactions.
|
||||||
|
///
|
||||||
|
/// # State
|
||||||
|
/// A component can store its state in one of two ways: either as data within the
|
||||||
|
/// implementor of the trait, or in a type [`State`][Component::State] that is managed
|
||||||
|
/// by the runtime and provided to the trait methods. These two approaches are not
|
||||||
|
/// mutually exclusive and have opposite pros and cons.
|
||||||
|
///
|
||||||
|
/// For instance, if a piece of state is needed by multiple components that reside
|
||||||
|
/// in different branches of the tree, then it's more convenient to let a common
|
||||||
|
/// ancestor store it and pass it down.
|
||||||
|
///
|
||||||
|
/// On the other hand, if a piece of state is only needed by the component itself,
|
||||||
|
/// you can store it as part of its internal [`State`][Component::State].
|
||||||
#[cfg(feature = "lazy")]
|
#[cfg(feature = "lazy")]
|
||||||
#[deprecated(
|
#[deprecated(
|
||||||
since = "0.13.0",
|
since = "0.13.0",
|
||||||
|
|
|
||||||
Loading…
Add table
Add a link
Reference in a new issue