Version 0.5 brings many exciting changes but also a few major breaking changes. In this chapter, all changes should be covered to help you migrating your existing code quickly.
Component unifies several traits that existed before.
It entirely replaces
Components are now more similar to
MicroComponent which means they are much more flexible and don't need a typed connection to their parent component.
This makes using the same component with different parent components much easier.
Instead of accessing the parent model, you define
Init as a type that includes all information to initialize the component.
The life cycle has changed a bit, too.
- Initialization of the root widget. The reason behind this is to allow parent components to access the root widget before the rest of the component is initialized.
- Initialize the component itself and the widgets. This happens in one method now, which makes it easier especially for more difficult initializations.
- Regarding updates, there hasn't been a lot of changes. However you can now optionally update view and model at once using
- The shutdown method is called when the component is destroyed. Components don't have to live for the entire application lifespan anymore.
Components have three kinds of messages now:
Inputis the regular
Msgtype from the
Modeltrait in 0.4.
Outputis the message type, that can be used to forward information to other components automatically (or
()if you don't care about forwarding). You will find more information about initializing components in the next section.
CmdOutputis the output of commands. Commands are futures that are executed in the background. They fully replace async workers. The result of this future is the
CmdOutputmessage handled in
update_cmd, similar to the regular update function.
send! macro is obsolete. Please use
Components are initialized in the init method of their parent.
You simply call
MyComponentType::builder() to get a
Then you launch the component by calling
builder.launch(init_params) to receive a
From the connector you can decide to automatically forward messages to another component or just detach the connector to get a
The controller is the type you now store in the model of the parent component instead of creating a separate components struct.
Components trait necessary.
For types that implement
Component that don't have any widgets (such as implementers of the
Worker trait), you can call
detach_worker from a
This spawns the internal runtime on a separate thread and gives you a
SimpleComponent is a simpler variant of
Component that helps with the implementation of
Particularly, it doesn't support commands.
Worker is an even simpler variant of
SimpleComponent that helps with the implementation of
Particularly, it doesn't support widgets and allows running the components update loop on a different thread by using
This is the replacement for the previously separated
Factories now work very similar to components.
In fact, the new
FactoryComponent trait that replaces
FactoryPrototype is almost identical to the
Messages can now be optionally passed by using the
FactoryVec was entirely removed in favor of
Edits to factories are now similar to
Mutex and require a guard.
When the guard is dropped, all changes are rendered automatically, so no render method is required anymore.
- In general, a lot of internal macros were moved to be just attributes like
track!now written as
- Multiple arguments now don't need
()whereas tuples need two parenthesis
- Wrapping widgets into
Someis now also an attribute
- Additional arguments are now passed with square brackets
instead of parenthesis
- Cloning variables for closures is always done with square brackets
instead of parenthesis
- The macro in now called
- You need to use
let widgets = view_output!();in the
initfunction to inject the code from the
pre_init-> Code before
post_init-> Code after
Now you need to specify an application id and a generic parameter is required when calling
&stras parameter instead of
|Store a |
|Forward output messages from one component to another by using |