Seed: Define traits for component methods

[mankinskin]

There is an implicit concept of components in Seed, which could be made explicit:

struct Model {
    state: u32,
}
struct Msg {
    Increment,
}
fn update(msg: Msg, model: &mut Model, orders: &mut Orders<Msg>) {
    match msg {
        Msg::Increment => model.state += 1,
    }
}
fn view(model: &Model) -> IntoNodes<Msg> {
    div![
        model.state
    ]
}

These functions could be put into traits. The benefits of this are

• better error messages if the functions are implemented incorrectly
• generic programming targetting these methods
• idiomatic code

I have a crate which I use in my personal seed projects which implements traits like this:
https://github.com/mankinskin/components/blob/master/src/lib.rs

There are some examples aswell:
https://github.com/mankinskin/components/blob/master/src/auth/mod.rs

[MartinKavik]

There (and in Elm community) were a LOT of flame-wars and a lot of different Page/Component API designs. We don't want to add it into the core, because:

• The main goal of TEA is to have a single source of truth. By creating components you basically break the rule.
• In ideal world, you have one view, one update, one Model. TEA components with msg_maps is a necessary evil to split the code into a more manageable pieces of code. It's typically recommended only for pages or some big page parts.
• When you create components you automatically have to create an abstraction / mechanisms for communication among them and also something like life-cycles, etc. It often makes the app more complex.
• My "components" have often pretty different "interface" - some pages/components have only a generic view and no Model, some view doesn't need Model at all, other ones also require to pass Context, other ones also require to pass a mapping function to invoke the parent Msg, etc. I wouldn't be able to use any Component/Page traits in any of my Seed projects, because the goal is to make the app structure as simple as possible. and don't define any local state.

However we know TEA isn't a silver bullet for everything and it's hard to optimize it in a not specialized languages, so we are working on Hooks to mitigate boilerplate and improve performance.

Some explanations are here - https://guide.elm-lang.org/webapps/structure.html or you can find many discussions in older issues and some explanations also on seed-rs.org.

[mankinskin]

This feels like an extension of the Object-oriented vs Data-oriented programming discussion. And interestingly, I have always been on the more "data-oriented" side of the discussion, but now here I am, advocating for components, which are essentially objects.

I am not experienced enough with front-end development yet, so I will not try to convince you of anything here. But I will continue on this route for now, and see where it leads me. So far, I did not have any issues because of the component system I am using right now. You can still use function-style views, you can have components without state, but it would require uniform function signatures and a type to represent the component. It feels more structured for me, that is why I use it, but I can understand if this is not a concept seed wants to embrace.