pub trait Component: Sized + 'static {
type Message: 'static;
type Properties: Properties;
// Required methods
fn create(ctx: &Context<Self>) -> Self;
fn view(&self, ctx: &Context<Self>) -> Html;
// Provided methods
fn update(&mut self, ctx: &Context<Self>, msg: Self::Message) -> bool { ... }
fn changed(
&mut self,
ctx: &Context<Self>,
_old_props: &Self::Properties,
) -> bool { ... }
fn rendered(&mut self, ctx: &Context<Self>, first_render: bool) { ... }
fn prepare_state(&self) -> Option<String> { ... }
fn destroy(&mut self, ctx: &Context<Self>) { ... }
}
Expand description
Components are the basic building blocks of the UI in a Yew app. Each Component chooses how to display itself using received props and self-managed state. Components can be dynamic and interactive by declaring messages that are triggered and handled asynchronously. This async update mechanism is inspired by Elm and the actor model used in the Actix framework.
Required Associated Types§
sourcetype Message: 'static
type Message: 'static
Messages are used to make Components dynamic and interactive. Simple
Component’s can declare their Message type to be ()
. Complex Component’s
commonly use an enum to declare multiple Message types.
sourcetype Properties: Properties
type Properties: Properties
The Component’s properties.
When the parent of a Component is re-rendered, it will either be re-created or
receive new properties in the context passed to the changed
lifecycle method.
Required Methods§
sourcefn view(&self, ctx: &Context<Self>) -> Html
fn view(&self, ctx: &Context<Self>) -> Html
Components define their visual layout using a JSX-style syntax through the use of the
html!
procedural macro. The full guide to using the macro can be found in Yew’s
documentation.
Note that view()
calls do not always follow a render request from update()
or
changed()
. Yew may optimize some calls out to reduce virtual DOM tree generation overhead.
The create()
call is always followed by a call to view()
.
Provided Methods§
sourcefn update(&mut self, ctx: &Context<Self>, msg: Self::Message) -> bool
fn update(&mut self, ctx: &Context<Self>, msg: Self::Message) -> bool
Called when a new message is sent to the component via its scope.
Components handle messages in their update
method and commonly use this method
to update their state and (optionally) re-render themselves.
Returned bool indicates whether to render this Component after update.
By default, this function will return true and thus make the component re-render.
sourcefn changed(
&mut self,
ctx: &Context<Self>,
_old_props: &Self::Properties,
) -> bool
fn changed( &mut self, ctx: &Context<Self>, _old_props: &Self::Properties, ) -> bool
Called when properties passed to the component change
Returned bool indicates whether to render this Component after changed.
By default, this function will return true and thus make the component re-render.
sourcefn rendered(&mut self, ctx: &Context<Self>, first_render: bool)
fn rendered(&mut self, ctx: &Context<Self>, first_render: bool)
The rendered
method is called after each time a Component is rendered but
before the browser updates the page.
Note that rendered()
calls do not always follow a render request from update()
or
changed()
. Yew may optimize some calls out to reduce virtual DOM tree generation overhead.
The create()
call is always followed by a call to view()
and later rendered()
.
sourcefn prepare_state(&self) -> Option<String>
fn prepare_state(&self) -> Option<String>
Prepares the state during server side rendering.
This state will be sent to the client side and is available via ctx.prepared_state()
.
This method is only called during server-side rendering after the component has been rendered.
Dyn Compatibility§
This trait is not dyn compatible.
In older versions of Rust, dyn compatibility was called "object safety", so this trait is not object safe.