How to initialize a state of a complex lazy component, directly after components constructor call?

[AlphaAmphib]

I am trying to build a flexible List / Table with a lazy component at the moment. However I do not understand how I can setup the ListState directly after instantiation of the List. Here is the commented List Code:

pub struct List <'a, RBuilder: RowBuilder<DATA>, MsgFactory: MessageFactory<MSG>, DATA, MSG> where
    [(); <RBuilder as ListHeaderBuilder>::MAX_HEADS]:
 {
    rb: PhantomData<RBuilder>,
    mf: PhantomData<MsgFactory>,
    msg: PhantomData<MSG>,
    max_rows_viewport: usize,
    data_ref: &'a Vec<DATA>
 }

impl <'a, RBuilder: RowBuilder<DATA>, MsgFactory: MessageFactory<MSG>, DATA, MSG> List<'a, RBuilder, MsgFactory,  DATA, MSG> where
[(); <RBuilder as ListHeaderBuilder>::MAX_HEADS]:
{

    /* Create a new list to visualize some data vector
       At the moment trying to solve the case, where the list is const (no add / edit operations)
     */
    pub fn new (data: &'a Vec<DATA>, max_rows_viewport: usize) -> List<'a, RBuilder, MsgFactory,  DATA, MSG> {
       let mut list: List::<'a, RBuilder, MsgFactory,  DATA, MSG> =
           List::<'a, RBuilder, MsgFactory,  DATA, MSG>{
            rb: PhantomData::<RBuilder>{},
            mf: PhantomData::<MsgFactory>{},
            msg: PhantomData::<MSG>{},
            max_rows_viewport: max_rows_viewport,
            data_ref: &data
        };
        let mut_list: &mut list;
        //How can I add a new ListState to the state tree here,
        //so that when component.view(&self, state: &Self::State) -> Element<'_,Event, Renderer>
        //is called the first time, the ListState already reflects the data vector????

    }



    fn vp_to_data_idx(&self, vp_idx: &usize, state: &ListState) -> Option<usize> {
        let data_len: usize = self.data_ref.len();
        if  data_len> 0 && 0  <= *vp_idx && *vp_idx < self.max_rows_viewport {

            let data_idx: usize = state.start_row_viewport+ vp_idx;
            if 0<=data_idx && data_idx  < data_len {
                Some(data_idx)
            }
            else{
                None
            }

        }
        else{
            None
        }
    }
}

and here is the commented ListState Code:

#[derive(Default)]
pub struct ListState{
    inited: bool,
    start_row_viewport: usize,
    row_selection_states: Vec<SelectionState>,
    last_event: Option<Event>

}

impl ListState{

    /* Here is my problem, how can I modify the row selection
       state vector before the first draw call???
       (The row selection state vector holds UNSELECTED / SELECTED / ACTIVATED
       for every data entry).
     */
    fn new() -> ListState{
        ListState{
            inited: false,
            start_row_viewport: 0,
            row_selection_states: Vec::<SelectionState>::new(),
            last_event:None
        }
    }

    fn init(&mut self, data_ref: & Vec<DATA>) {
        if !self.inited {
            self.row_selection_states.resize(data_ref.len(), SelectionState::UNSELECTED);
        }
        self.inited=true;
    }
    
}

Another question where I already encountered a problem in a previous implementation attempt is the type parameter RBuilder of trait RowBuilder. Basically it contains one method create_row taking a DATA instance and producing a
Vec<Element<>>. But if I later on want to solve the case of a non constant list I will have a second method update_data_from_row, that takes a Vec<Element<>> extracts the current value, then sets the corresponding field of the data struct. However l have not found a way to cast back the widget trait to the concrete implementation after calling Element.as_widget() or Element.as_widget_mut(). My problem is, that I don't know how to go get from &dyn Widget to &dyn Any?

[Mingun]

Can someone tell me, why the source code is not displayed correct. Do some characters of the rust code need to be escaped?

Use three backticks and the rust code for proper highlight. Documentation

[AlphaAmphib]

Thank you Mingun, I think my post looks more "help-friendly" now!

[AlphaAmphib]

I think my question is related to the discussion Related discussion. After reading again through the source code of TextInput widget, I understood, that the data to be visualized in a widget should be passed in as constructor argument, while the state of a widget contains the information to parametrize the algorithms inside the draw() and on_event() methods!
Same principle applies to a lazy components view() update() methods.

However what is, if the state depends on data passed in like in my List/Table example, where the state needs to contain a vec representing the selection state for each data element in the data vec? In this case the assumption, that the state impl always is of type default is problematic (I cannot pass in the size of the data vec to the table state).

Another example is filtering in a table parametrized by DATA (the data type) and configurable with regards to its column filters. Obviously filtering influences the way, how the table is drawn and which rows can throw selection events, therefore the predicates parametrizing the filter algorithm should also be part of the widget state, not part of the widget.

Well, now one can argument that a freshly initialized table widget should never filter nor sort the input data list, but is this realistic? In case of a file open dialog, on start one would generally like to filter by the file extension, but in some special case probably by a "modified date older than" criteria. If you want the table widget to be really that customizable, I do not see any other way than wrapping all the possible state information together with the data vector in some kind of "listmodel wrapper " that is passed in on widget creation, thereby really exposing the Lists / Tables state to the outer world.
Unless s.o. can explain me how to solve the mentioned example problems in a "pure elm way", I doubt that generally prohibiting custom state intialization is practicable for highly customizable widgets / components!

If you do not like the idea of having a special state initialization method inside the widget trait, would a special INIT_STATE_EVENT that can be received by the normal on_event() method after default state initialization be more elm-like?

[lufte]

Are you trying to build a reusable widget that can be used by other Iced users, like TextInput, or are you just building a part of your app using other Iced widgets?

[AlphaAmphib]

Well, for the moment I am just building it as part of a personal app evaluating iced as gui framework in general. The main reason is, that I need a file open dialog, therefore the need for some Table / List component. But as it turns out to be quite a bit of work, I also consider turning it later on into a full reusable widget, probably offering the source code back to the iced project. I guess I am not the only person in need of a file dialog...

[lufte]

Just asking because the answer to your original question may depend on it. For a normal component of your app (not a widget) you have to embrace the Elm architecture. You are in charge of the state of your app. You know when your Table is going to be drawn for the first time, because it depends on the state of your app, so you can decide when and how to construct the state of your component. All of it is going to happen during an invocation of your app's update() method. Your component, then, doesn't really need new and init methods, only one method is enough for you to build it at the right time and since it will be during iced::Application.update() then you will have access to all of your app's state to pass all the arguments you need.

[AlphaAmphib]

When you talk about component, do you mean the component class inside the lazy crate? Like I understand your answer in this case, the solution I outlined (packaging the data vector with the initial selection state for all rows, initial filter predicates etc... in some ListModel, than passing the model to the component) would be the way to go? How would this differ when building really a reusable widget?

[AlphaAmphib]

Probably it would also help me if you can confirm my observation, that generally the data (what is to be drawn) is passed to the widget constructor and the information (how the data is drawn and how the component reacts) is hold in the components state.

[lufte]

inside the lazy crate?

Oh, sorry, I didn't know we were talking about a particular lazy library, I thought it was the general concept of "I want to initialize this object only when and if it's used".

I don't think "component" has a clear definition in Iced, so you're right, I should state what I mean. I usually use it to describe a collection of Iced widgets that together form a cohesive part of my app. Perhaps all the state required to draw these widgets is held in its own particular unit (like your ListState here) to encapsulate it nicely. I also, heh, use to describe the state object as well (ListState again), so when I talked about the component's "methods" I was talking about the state object.

Probably it would also help me if you can confirm my observation, that generally the data (what is to be drawn) is passed to the widget constructor and the information (how the data is drawn and how the component reacts) is hold in the components state.

I'm no expert here, so take me lightly, but I think your two concepts ("data" and "information") are even just one thing in Iced: state. When you draw your widgets on each view() you read your app state and draw the widgets accordingly. You also attach messages to your widgets handlers (like Button::on_press) and decide how the widget should look. All of this happens every time iced::Application::view() runs, it's like you are constructing your widgets over and over. This is the key concept about an "immediate mode" GUI toolkit like Iced, maybe you want to read on the differences between that and a "retained mode" GUI.

How would this differ when building really a reusable widget?

Widgets actually have their own internal/private state that is managed separately from your app's state, like a TextInput "focused" state. If you are writing a widget then the API is different and you do need to keep track of this state.

[AlphaAmphib]

First, I want to thank you for your replies. Still I am not sure, what is the correct way to solve the problems mentioned in the initial post. This lazy component also has an interior state, similar like a widget. If I follow the route like you suggested to combine all additional information with the data in the application state, like you would proceed in a normal iced application (without encapsulating parts in a reusable component / widget), I would not use this internal state structures at all. Somehow I have the "feeling" that this solution is not the correct way to build a reusable table component. I hope that s.o. of the core team can give a detailed explanation when and how to use the internal state structures regarding my initial problem. Or that s.o. can point me to a code example of a custom reusable component, that is of similar complexity like a table widget, so I can analyze some code.

[nicksenger]

The Lazy and Component widgets each store state in the persistent widget tree which, similarly to your application state, lives longer than individual invocations of view & update.

The Lazy widget is intended to be applied in cases where you have some expensive computation to perform in view, but this computation can be memoized based on some other state so that it doesn't need to be performed every view (e.g. some unrelated state changes). Another way of putting this is that you can use Lazy to cache a particular iced Element for use across separate views.

The Component widget is for cases when you have some state which generally will not be needed outside, or need to be mutated as a result of any event occurring outside the component. An example of somewhere components are useful is custom pickers, pick-lists, dropdowns, etc -- usually the rest of the application doesn't care whether or not the picker is open or closed: a component allows you to factor this sort of concern out of your main application state. The tradeoff is that manipulating this state from your application's update becomes harder (you can still do it, but you'll need to use operations).

Generally I'd say: rather than picking one from the beginning, build whatever it is you want to build without using Component or Lazy. Just use a regular function which returns some elements/custom widgets, and some associated application update logic. After that, you can ask if you are doing unnecessary work in view (Lazy could help) or if your update logic has become cluttered by the minutiae of isolated widget sub-trees (Component could help).

For that last point, an Elm purist would likely point out that you can address the same problem through refactoring the application's update logic. A nice thing about Iced is that you can choose your own adventure there, depending on whether you prefer more of a pure functional or incremental style for building UI :)

[AlphaAmphib]

Hi Nick,

thank you for your reply. From your response I got the feeling, that you are sufficiently deep inside the internal structures of iced to help me out! From your explanation I already found out, that I don't need to use Lazy. Like I wrote somewhere in the post I had the idea to go with the component from somewhere on the web, where the component was wrapped inside the lazy widget. And although I have read until now multiple times through the component struct, I did oversee that component itself implements widget - Whoops!

However from your explanation when to use component I am almost sure, that component is the iced construct from where to start my implementation. First like I initially explained, the final goal is to have a working "file open dialog" and from there arises the need for a working table component. I think the internal state of a file dialog is sufficiently complex, that you want to keep it out of your application state! Second, like I deduce from your examples "pick-lists", "drop-down", my table component fullfills the second criteria, that you want to keep inside the internal state only the information necessary, that the widget can draw itself correctly and parametrize its event handling according to its internal state. (I want to encode inside my state the information about the currently activated column filters, the column which determines the actual sort order and the viewport offset and the selection state of all rows (not just the ones being shown in the current viewport)).

Still my original problem, that my initial state depends on the Vec passed in to the table widget remains. Even worse I found out, that the requirement of the STATE type inside component to implement Default produces an even bigger problem for me. Imagine my state struct like this:

pub struct ListState<DATA, const MAX_COLS: usize>{
    start_row_viewport: usize,
   //(The row selection state vector holds UNSELECTED / SELECTED / ACTIVATED
    row_selection_states: Vec<SelectionState>,
   //The currently active column filters
   col_filters: [Option<Fn(&Data)->bool>;MAX_COLS],
    last_event: Option<Event>
}

/*the type parameters DATA and MAX_COLS are passed from the 
 the surround List component, that itself is parametrized by this
type parameters*/
impl<DATA, const MAX_COLS: usize> ListState<DATA, MAX_COLS>{

    /* My problem still persists, my outer ListComponent also should 
       support another type parameter "<FSB: FilterSorterBuilder>",
       that produces the filter and sorting FN's for each column, so that
       the ListComponent is very configurable in its behavior. 
       However, as component forces me that ListState implements Default,
      how do I get the intial configuration from the FilterSorterBuilder inside
      ListState??? How can I set the size of row_selection_states and fill it
      with value "UNSELECTED" without being able to pass the &Vec<DATA>
      hold inside my ListComponent??? Keep in mind, I have to bring in this
     information before the first call to component::view(), as in iced's updates cycle,
      view is always called before the first time update is called,
     so I do not have any chance to get a mutable ref to the state earlier!!!!
    */
    fn new() -> ListState<DATA>{
        ListState::<DATA>{
            start_row_viewport: 0,
            row_selection_states: Vec::<SelectionState>::new(),
            col_filters: [Option<Fn(&Data)->bool>;MAX_COLS]
            last_event:None
        }
    }

 //Called from ListComponent::update(), whenever I receive a ListEvent::Selection event
  fn set_selection_state (row_index: usize, sel_state:SelectionState ){
      //impl
 }    

 //Called from ListComponent::update(), whenever I receive a ListEvent::FilterChanged event
  fn set_col_filter (col_index: usize, filter_predicate: Option<Fn(&Data)->bool> ){
      //impl
 }    

 //Called from ListComponent::view(), returns an iterator of all items of the data vec, that pass the filters,
 //in sort order, and inside the current viewport set by self.start_row_viewport.
 //from the returned iterator, a new Grid widget is created and filled with widgets created by the type
 //parameter <RBuilder: RowBuilder> of the outer ListComponent
 //The basic function of the RowBuilder trait is to take in an &Data and to spit out the Elements<'a, ListEvent,Renderer>
 //making up the widgets of &Data's row  
 fn  get_filtered_sorted_at_viewport_offset(&mut self, data_ref: & Vec<DATA>)-> Iterator<&DATA>{
     //impl
  }
    
}

Even worse, when I started to parametrize ListState with type parameter DATA, of course the compiler complains, that when ListState is forced to implement Default also my generic DATA type is forced to implement Default! Now I ask myself, is this really appropriate, that by this design choice of iced my list component can only deal with structs and enums implementing Default? And how can I setup my ListState before the first view call, when I really want to support that another programmer can set the inital fitering and sorting conditions for his ListComponent configured by the FSB: FilterSorterBuilder type parameter??? From my perspective keeping all the information of my ListState object inside the application state is highly undesirable, as it really does not contribute to the applications workflow, it only determines how ListComponent::view() draws its content. I hope with this explication it is possible to understand why I struggle with the Default constraint for STATE. If still not clear, I will paint a (sloppy) UML diagram for the whole construction.

enlightment appreciated!

[nicksenger]

If I'm understanding correctly, you want to create a component which manages some internal state, but also expose the ability for its creator to customize that state in the initial view call that produces the component.

That's definitely possible, but Iced will, by way of the type system, force you to address potential awkward behaviors that could come about from doing it.

Let's say the state is type T: you can do what you want by setting the State associated type on the component trait to SomeNewType(Option<T>). The requirement for T to implement default can be avoided by implementing the Default trait manually for "SomeNewType." Then, store &T on whatever struct it is you are implementing Component for to use as the initial state.

Now you will have to decide in the component's view when you want to refer to the T coming in from above versus the one in the component's internal state. The easiest would be to only refer to it whenever the internal state is none, e.g.

fn view(&self, state: &Self::State) -> Element<'_, Self::Event, Renderer> {
  let state_for_this_view = state.0.as_ref().unwrap_or(&self.state_from_app);
 
  ...
}

[AlphaAmphib]

Good morning,

now this hint is incredibly useful. I will try it directly after my breakfast coffee. I wil then close the topic, if I do not run into problems with his solution. Still I would like the iced team to think about the use case " a component which manages some internal state, but also exposes the ability for its creator to customize that state in (before) the initial view call", which is a very good description of the problem! I think as soon as s.o. builds components like table / tree widgets that can be customized by their creators, there is a necessity for this.

My interpretation of Nicks phrase "That's definitely possible, but Iced will, by way of the type system, force you to address potential awkward behaviors that could come about from doing it " tells me, that although this is a solution, it is not the most beautiful one. I personally think that on the long term, iced's component should provide an easy mechanism for supporting this....

[nicksenger]

I guess it could be as ugly or beautiful as you want to make it 😄 If it's something you encounter frequently, you could abstract out the pattern, something like this maybe:

use std::marker::PhantomData;

use iced::Element;

#[derive(Default)]
enum State<T: Clone> {
    #[default]
    Initial,
    Touched(T),
}

pub trait CustomInitialStateComponent<Message, Renderer> {
    type Event;
    type State: Clone;

    fn initial_state(&self) -> &Self::State;

    fn update(&mut self, state: &mut Self::State, event: Self::Event) -> Option<Message>;

    fn view<'b>(&'b self, state: &Self::State) -> Element<'b, Self::Event, Renderer>;
}

pub fn view<'a, C, Message, Renderer>(component: C) -> Element<'a, Message, Renderer>
where
    C: CustomInitialStateComponent<Message, Renderer> + 'a,
    C::State: 'static,
    Message: 'a,
    Renderer: iced_core::Renderer + 'a,
{
    iced_widget::component(Wrapper(component, PhantomData))
}

struct Wrapper<Message, Renderer, C: CustomInitialStateComponent<Message, Renderer>>(
    C,
    PhantomData<(Message, Renderer)>,
);

impl<'a, Message, Renderer, C: CustomInitialStateComponent<Message, Renderer>>
    iced::widget::Component<Message, Renderer> for Wrapper<Message, Renderer, C>
{
    type Event = C::Event;
    type State = State<C::State>;

    fn update(&mut self, state: &mut Self::State, event: Self::Event) -> Option<Message> {
        match state {
            State::Initial => {
                let mut touched_state = self.0.initial_state().clone();
                let msg = self.0.update(&mut touched_state, event);
                *state = State::Touched(touched_state);
                msg
            }
            State::Touched(state) => self.0.update(state, event),
        }
    }

    fn view(&self, state: &Self::State) -> iced_core::Element<'_, Self::Event, Renderer> {
        match state {
            State::Initial => self.0.view(self.0.initial_state()),
            State::Touched(state) => self.0.view(state),
        }
    }
}

I'm not sure it's a common enough use-case to warrant inclusion in Iced itself though. I've run into that once or twice before, but usually the standard Default is enough.

Again I'd caution against putting everything in a component's state up-front, because refactoring state up out out of a component back into the application is more painful than breaking off some small piece of your app state into a component. If you're not yet familiar with the Elm way of doing things, you should really start there, as Iced is based on that architecture first and foremost. Component has its uses IMO, but it can also over-complicate things if applied unnecessarily.

[AlphaAmphib]

Thank you again Nick, I am working at the moment at including the hint, I guess your additional code will be helpful. At least I learned s.th. new about rust (did not know, that by the new type pattern + option you can circumvent generally the Default requirement). I guess you have much more experience with elm and also rust, so if you think that my case is to special to support it out of the box, it's okay for me.
After all with your help, I will achieve what I wanted. Did you see my bug report from this morning (I now installed an older nightly toolchain to be able to continue)?

[nicksenger]

Glad to hear you think you've figured it out 👍 , not sure about the nightly issue as I generally use stable

[AlphaAmphib]

Okay, seems to work now, closing...