Suggestion: `update` should return a model which implements update and view about yew HOT 4 CLOSED

Thank you for the feeedback!
You offered the good direction in which I want to move. It makes possible to have a transitions of states and change runtime completelly. Sounds cool! 👍

To be honest, I have a prototype of Component trait and it looks quite similar to your trait:

/// Implements local update->view loops.
/// <Component prop="value", onevent=|_| Parent::Msg, />
/// CTX - is a way to get external resources, for example:
/// CTX: HasFetchService
pub trait Component<'a, CTX: 'a> {
    type Msg;

    fn create(context: &'a CTX) -> Self;
    fn update(&mut self, msg: Self::Msg) -> ShouldUpdate;
    fn view(&self) -> Html<Self::Msg>;
}

/*
impl Component {
    fn get_property()
    fn on_event()
}
*/

And I feel I could combine both to have a universal trait for this needs. But there is the issue I haven't resolved yet: delayed messages. For example what if update implementation spawns the timer and replaces itself:

impl YewTrait for Model1<Msg1> {
  fn update(_) -> impl YewTrait {
    context.timer.spawn(Duration::from_secs(100), |_| Msg1::Fire);
    Model2::new()
  }
}

impl YewTrait for Model2<Msg2> {
  fn update(_) -> impl YewTrait {
   // Msg2 type expected here
  }
}

To solve this we could cancel all tasks on handler's Drop, but it's not yet implemented and have to be improved. Another approach: to have a subscriptions entity like Elm do, but I like services more, because it's simpler to use.

I'm working on an implementation prototype and I'm sure we will have something similar to YewTrait and very handy.

from yew.

@deniskolodin I'm not sure how props work with your prototype. get_property would be unable to return different types, right? This was my main concern while mocking up a prototype myself.

It would also be good to move this conversation to #1 if that's the way this is going

from yew.

I hadn't ever looked into Elm subscriptions. (I've never used elm, just read about it.) Oh nice! I like this component trait. Any React project of a significant size (with higher order components, etc) is so loosely-typed that I imagine it's going to be tough to have a type-safe component system :) but I'm glad you're working on it.

Hm. I hadn't thought about the async story yet. My thoughts:

• Async things can be thought of as streams of events which have a type. So, promises, intervals, timeouts, RxJS streams, etc. all fall in this category.
• In my opinion, the cleanest and most type-safe thing would be to wrap them in AsyncStream<Msg> wrappers and have our code handle them synchronously.

My initial attempt at a solution:

• When the AsyncStream generates an event, if and only if it is still accessible from the current model, then update(self, context, msgFromAsyncEvent) is called. (I'll get to accessibility below)
• Then, when we change models, we either explicitly transfer our AsyncStream objects to the new model (if they still apply), or they go out of scope and are dropped.
• For example, let's say on the LoadingPage, we make an async request to see if the user has permissions to see the SuperSecret page. If so, we send them to the SuperSecret page. If not, we send them to HomePage. We also pre-fetch a magic string that we're only going to use on SuperSecret page.

enum LoadingScreenPageMsg {
  HasPermissions(bool),
  PrefetchMagicString(String),
};
LoadingScreenPageModel {
  userHasPermissions: AsyncStream<LoadingScreenPageMsg::HasPermissions>,
  magicStringRequest: AsyncStream<LoadingScreenPageMsg::PrefetchMagicString>,
}
impl YewTrait for LoadingScreenPageModel {
  type Msg = LoadingScreenPageMsg;
  fn update(self, context, msg) -> impl YewTrait {
    match msg {
      HasPermissions(true) => SuperSecretPageModel {
        magicStringRequest: self.magicStringRequest,
      },
      HasPermissions(false) => HomePageModel::new(), // magicStringRequest is dropped forever.
      _ => _, // ignore magicStringRequest messages
    }
  }
}

Open questions

• How can we ensure that only events that are still accessible from the model generate events? Hopefully the Drop trait will suffice.
• A model can contain AsyncEvent<Msg>s for any type of Msg. It does not have to correspond to the self::Msg defined in impl YewTrait for Model. So, something has to be done about that.
• I don't think Rust has enum composition, so it might be difficult to transfer AsyncEvents across models. Perhaps something like AsyncEvent.mapMsg can do the trick, but it sounds like boilerplate.
• Maybe tokio/futures will help.

from yew.

This issue is stale, Component should solve all of these issues

from yew.