Add components about yew HOT 8 CLOSED

@deniskolodin would this be a 0.2.0 feature too? I'd love to help with this one as it's the one abstraction I think would be nicest. 😄

from yew.

I've been playing around with this implementation. I don't think I should be the implementer, based on the amount of trouble I've been having even coming up with an API, but I have some thoughts.

I think each component should have its own lifecycle almost identical to a full yew program. That is to say, each component should have a view, an update, and a model with an internal message type. Each component should also have a public Props struct (could be empty but actually must be named Props), and yew could implement a custom derive for the Props object using procedural macros, thus abstracting away the need for the component's user to ever actually use the Props "export" (JS terms because JS developer).

I ran into issues when trying to create a VComponent, and I also tried to make VTag compatible with components. Neither methodology "worked" for me and my Rust skills.

I implemented a potential example in this commit, so this was the example I was trying to get to compile and run.

Would love to hear thoughts on this.

I think we should really consider what the "modularity", "reusability", and "scaling" stories are for yew before coming up with the exact API for components. That said, I've been very happy with how React handles components, and I think a similar story might work very well for yew if we can work it in with Rust's type system. Callbacks and closures might also not work quite as well as they do in JS for passing up data to parent components, so we might want to have some sort of hook to pass a message up to the parent or global message handler. This is really where I started running into design issues.

I also read up on Elm's scaling story and was unimpressed due to the fact that (I believe) it relies on one global message type and model. I think we need a more rigid, opinionated component structure.

from yew.

@rivertam @deniskolodin I guess it's a matter of what feels best and where we're taking influence from? I agree that components should have their own lifecycles but I was thinking something more alike to React. I'm also not the strongest in Rust though. Maybe if we could enumerate the things we would want abstracted away we could figure out what that looks like in Rust.

from yew.

The good thing about modeling after React is that it encourages "strict" typing very strongly with PropTypes. I wouldn't be mad at a 1-to-1 translation, if possible. The hardest part is probably going to be the macro if we go that route. For that reason, it might be better to avoid the JSX-style and stick with a direct component interpolation. Just a thought.

from yew.

@rivertam Agreed. It doesn't need to look too much like React. I was most interested in taking the ideas around its state management. The abstraction around setState, Props, State, etc is really well built and lets users encapsulate stuff well.

from yew.

@wldcordeiro

I disagree about state management for two reasons.

1. The way state management works in React is different than how yew does it. In React, state management is done through transformations. It is highly encouraged to not change the state directly, but rather return a new state based on the old state. This doesn't work so well in Rust, as it would require state-model subsets. E.g. If your state-model looks like { counter: u64, name: String }, and you just want to change counter, you'll have to create an entirely new state-model instance, where in React you just have to return { counter: counter + 1 }. This is also noted in the highest level update function, which treats the state as mutable rather than returning a new state.
2. The way setState works is/would be quite inefficient. If we're not making massive ergonomic improvements by implementing it as React does, I don't think it's worth the tradeoff.

Another approach I've been thinking of is more Redux/Elm-like, which would be that we'd have "reducers" (update), "models", and "actions" (messages) which would be specified in the same file as the view and would only affect a certain part of the global model and only receive those messages. I have no idea how we'd implement it, but I feel this might be another reasonable approach.

from yew.

Basically copying the API in reason-react should work well. There each component has a message type and reducer to update the state: https://reasonml.github.io/reason-react/docs/en/state-actions-reducer.html

ReasonML is in many ways more similar to rust than Elm or JS anyway :)

from yew.

Components was implemented with #91 🎉

from yew.