I am not entirely sure whether this architecture requires that but I want to implement a custom widget that would act as a part of a page. It should contain some textboxes with content from an api, just like the usual blog tutorial example.
Reading the documentation I found iced::widget::component but I’m unsure how to implement that / if that even makes sense in my usecase.
Currently, I have a blog.rs which should contain the code for that widget to then be included in main.rs.
I would be really thankful if someone could provide me with an example on that or ideas how you structure your code
1 Like
Hi. Also quite new to Iced so take my advise with a pinch of salt.
You should check out the component example which wraps up a text input and two buttons in a custom component that implements a numeric input with the buttons inc/decrementing the value in the input (see the numeric_input inline module inside the source file for all the custom component bits). One important thing to note, which is not in the documentation, is that all the custom component code is hidden behind the “lazy” feature so you will need to enable that in your Cargo.toml to use it.
As for if it makes sense in your use case. Custom components are good for code reusability but you can achieve that in other ways, where they are invaluable is in encapsulation. In the example above the custom component handles all the events/logic around pressing inc/dec buttons, parsing text as a number etc. so that the code that uses the component only needs to store the current state and handle the event when the value changes. So for you, if there is repetative or complex logic that the application doesn’t need to know about then by all means hide it away in a custom component but, if the component is just a wrapper around repeated UI elements then consider using a simple helper function instead.
Hope that is helpful.
1 Like
Helpful indeed!
Thank you for your complex answer with all the ideas to go about it. I must have overlooked that particular example but I guess that happens when you’re new.
I presume a helper function would just return something like a container filled with certain widgets.
Glad you found it useful. Not surprising you missed that example thought: it’s not actually in the list of examples in the readme and doesn’t even have its own readme to say what it is. I’m sure these things will be sorted once the library is a little more mature and the API is stable.
Yes, exactly. See e.g. view_controls in the todos example. That function also contains a closure filter_button that is used for the same purpose which seems to be a common pattern in the examples.
I also have just noticed that in the todos example, each Task is implemented with a component like pattern - a view() and update() method is implemented but because it does not implement From<Task> for Element (I think) it requires additional logic in the parent application update/view methods to tie it all together. I’m unsure if there is any advantage to this style of doing things, perhaps someone with more experience with Iced can comment, but something to think about regardless.
1 Like