Component v2 #1646

jstarry · 2020-11-15T15:18:16Z

Description

This PR aims to address two common issues with Components:

Too much boilerplate when implementing components
Easy to forget to update props inside the change lifecycle method

This PR addresses the two above issues with breaking changes and renames and deprecates the existing Component trait (now named LegacyComponent) to encourage devs to switch to the new trait.

Fixes #830

Changes

New Component trait!
Component change method renamed to changed (and is only called when props != new props)
Component methods are now passed a Context which right now is just an alias to Scope
Renamed yew::html::Component to LegacyComponent
Updated html! to only handle new components so legacy components must be wrapped in Legacy<..>
Properties must now implement PartialEq
Removed a bunch of stdweb examples because who has the time..

Checklist

Write new docs
I have run cargo make pr-flow
I have reviewed my own code

jstarry · 2020-11-15T18:07:37Z

@siku2 any thoughts?

siku2 · 2020-11-17T08:20:01Z

Hmm... The whole wrap! macro doesn't seem very ergonomic to me. Is it possible to implement Component on the state directly (like we have it now) but instead of accepting a receiver (self) the trait methods accept a Context which is basically Wrapper but more transparent?

I'm imagining something like this:

// Context contains props, state, and the component link

struct Props {
    init_text: String
}

struct Foo {
    counter: usize
}
impl Component for Foo {
    type Properties = Props;
  
    fn update(ctx: &mut Context, msg: Self::Message) -> bool {
        match msg {
             Msg::Increment => {
                ctx.state.counter += 1;
                true
             }
        } 
    } 

    fn view(ctx: &Context) -> Html {
        html! { <span>{ &ctx.props.text }</span> }
    }
}

jstarry · 2020-11-17T15:34:46Z

@siku2 yeah thanks for talking some sense into me. That's a better solution than using more magic macros, I'll switch to that 👍

jstarry · 2020-11-22T15:04:45Z

examples/boids/src/main.rs

+use yew::component::{Component, Context};
+use yew::{html, Html, Legacy, ShouldRender};
+
+type Slider = Legacy<LegacySlider>;


I didn't migrate this Slider intentionally to show how a project could slowly migrate away from the legacy component trait

github-actions · 2020-11-22T15:06:34Z

Visit the preview URL for this PR (updated for commit 53fe13d):

https://yew-rs--pr1646-yew-comp-3eimqgb8.web.app

_{(expires Tue, 01 Dec 2020 14:39:33 GMT)}

_{🔥 via Firebase Hosting GitHub Action 🌎}

siku2

I love it!

siku2 · 2020-11-22T16:53:05Z

yew/src/component/mod.rs

+use crate::html::{Html, Properties, Scope, ShouldRender};
+
+/// Context
+pub type Context<T> = Scope<T>;


I think all these type aliases only add confusion... Is there a good reason why we don't use the same name everywhere?

Hmm good point. I will just move yew::html::Scope to yew::component::Context.

siku2 · 2020-11-22T16:56:53Z

yew/src/lib.rs

@@ -1,4 +1,4 @@
-#![allow(clippy::needless_doctest_main)]
+#![allow(clippy::needless_doctest_main, deprecated)]


Shouldn't #[allow(deprecated)] be applied locally so we don't accidentally end up using deprecated API of another crate in the future?

yew/src/app.rs

siku2 · 2020-11-22T18:44:25Z

yew/src/html/mod.rs

+    since = "0.18.0",
+    note = "Please switch to the yew::component::Component trait"
+)]
+pub trait LegacyComponent: Sized + 'static {


Switching to LegacyComponent seems like more of a pain than just upgrading to the new Component trait. Is there anything I'm missing that would make the transition impossible?

This was the big dilemma I had when making these changes. Ideal situation would be:

Create new Component interface which works well with yew-macro

Deprecate existing Component interface but have it still be compatible with yew-macro

But these two are conflicting at the macro level. I decided to prioritize the new interface experience over having a nice deprecated experience but try my best to minimize changes needed to switch to the legacy component interface.

I opted to rename to LegacyComponent to make it obvious to devs which components have been upgraded but I don't feel too strongly about that. The main annoying thing is the macro changes to wrap all the html! components with Legacy<..>. Perhaps it is too annoying. I really care about this upgrade being smooth because upgrading to the new Component is tedious.

Call me crazy, but @siku2 what do you think about adding a new macro? It would act the same as html! but would handle the new Component interface. I'm thinking it could be called vdom!

I feel very conflicted about this. I very much understand the need to make the transition as seamless as possible but we might be worrying a bit too much about this given that Yew is officially still at major version zero (i.e. initial development).

To quote semver.org:

If you’re worrying a lot about backwards compatibility, you should probably already be 1.0.0.

Adding a new macro is a step too far in my opinion. If you think the migration to the new component trait is too tedious, I'm fine with keeping LegacyComponent around until the following release. We can deal with the Legacy<_> wrapper by suggesting the use of a type alias type MyActualComponent = Legacy<MyComponentImplementation>.

The migration guide could look something like this:

Replace impl Component with impl LegacyComponent

Rename your component Foo to something like FooComp locally

Create a type alias pub type Foo = Legacy<FooComp>;

Use the Foo type instead of the FooComp struct

Personally though, I wouldn't even consider switching to LegacyComponent, if I have to do some modifications in each file anyway, I might as well upgrade to the new Component trait.

siku2 · 2020-11-22T18:50:00Z

yew-router/src/lib.rs

-        route::Route,
-        switch::{Routable, Switch},
-    };
+    pub use crate::switch::Switch as Routable;


Why don't we actually rename Switch -> Routable and then create a deprecated type alias for Switch.

#[deprecated(note="use `Routable` instead")] pub type Switch = Routable;

yew-functional/src/use_context_hook.rs

Co-authored-by: Simon <simon@siku2.io>

docs/advanced-topics/optimizations.md

Co-authored-by: Teymour Aldridge <42674621+teymour-aldridge@users.noreply.github.com>

frostu8 · 2021-04-07T17:35:52Z

I really do love this. I feel like the clunkiest part of writing components was the ComponentLink and Properties. Now that the component is directly managed by its own concrete type, that means less boilerplate, more fun, and also enables some other things that could be implemented in the future.

hamza1311 · 2021-07-19T05:55:54Z

I think we should just remove LegacyComponent. There has already been a good amount of breaking changes so what's one more?

Also, what's left to be done in this PR? Is there any way I could help out?

siku2 · 2021-07-19T11:34:04Z

I think we should just remove LegacyComponent. There has already been a good amount of breaking changes so what's one more?

Agreed!

Also, what's left to be done in this PR? Is there any way I could help out?

Feel free to take over this PR

mc1098 · 2021-08-05T13:55:07Z

Should this now be closed in favour of #1961?

jstarry force-pushed the yew-comp branch from f2b4113 to 5415fe1 Compare November 22, 2020 14:56

jstarry changed the title ~~Introduce ergonomic wrapped components~~ Component v2 Nov 22, 2020

jstarry added 3 commits November 22, 2020 23:03

Components v2

c7a2114

Remove most of the stdweb examples

6c22fcf

Fix tests

7c11af5

jstarry force-pushed the yew-comp branch from 5415fe1 to 7c11af5 Compare November 22, 2020 15:03

jstarry commented Nov 22, 2020

View reviewed changes

More fixes

c3acb2a

jstarry marked this pull request as ready for review November 22, 2020 15:23

fmt

68cc68c

jstarry requested a review from siku2 November 22, 2020 15:36

siku2 reviewed Nov 22, 2020

View reviewed changes

jstarry and others added 2 commits November 24, 2020 22:36

Update yew-functional/src/use_context_hook.rs

4c72967

Co-authored-by: Simon <simon@siku2.io>

Update yew-functional/src/use_context_hook.rs

53fe13d

Co-authored-by: Simon <simon@siku2.io>

jstarry mentioned this pull request Nov 24, 2020

Deprecate App struct in favor of function based interface #1652

Closed

jstarry added the breaking change label Dec 27, 2020

teymour-aldridge reviewed Jan 13, 2021

View reviewed changes

docs/advanced-topics/optimizations.md Outdated Show resolved Hide resolved

Update docs/advanced-topics/optimizations.md

14ee6e6

Co-authored-by: Teymour Aldridge <42674621+teymour-aldridge@users.noreply.github.com>

hamza1311 mentioned this pull request Apr 23, 2021

yewtil: NeqAssign may encourage update patterns with derived data that are not panic-safe #1820

Closed

3 tasks

hamza1311 mentioned this pull request Jul 19, 2021

Components v2 (2) #1961

Merged

3 tasks

siku2 closed this Aug 5, 2021

hamza1311 mentioned this pull request Jul 20, 2022

Make fn update() re-render the component by default #2786

Merged

2 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Component v2 #1646

Component v2 #1646

jstarry commented Nov 15, 2020 •

edited

jstarry commented Nov 15, 2020

siku2 commented Nov 17, 2020 •

edited

jstarry commented Nov 17, 2020

jstarry Nov 22, 2020

github-actions bot commented Nov 22, 2020 •

edited

siku2 left a comment

siku2 Nov 22, 2020

jstarry Nov 24, 2020

siku2 Nov 22, 2020

siku2 Nov 22, 2020 •

edited

jstarry Nov 24, 2020

siku2 Nov 28, 2020 •

edited

siku2 Nov 22, 2020

frostu8 commented Apr 7, 2021

hamza1311 commented Jul 19, 2021

siku2 commented Jul 19, 2021

mc1098 commented Aug 5, 2021

		@@ -1,4 +1,4 @@
		#![allow(clippy::needless_doctest_main)]
		#![allow(clippy::needless_doctest_main, deprecated)]

Component v2 #1646

Component v2 #1646

Conversation

jstarry commented Nov 15, 2020 • edited

Description

Changes

Checklist

jstarry commented Nov 15, 2020

siku2 commented Nov 17, 2020 • edited

jstarry commented Nov 17, 2020

jstarry Nov 22, 2020

Choose a reason for hiding this comment

github-actions bot commented Nov 22, 2020 • edited

siku2 left a comment

Choose a reason for hiding this comment

siku2 Nov 22, 2020

Choose a reason for hiding this comment

jstarry Nov 24, 2020

Choose a reason for hiding this comment

siku2 Nov 22, 2020

Choose a reason for hiding this comment

siku2 Nov 22, 2020 • edited

Choose a reason for hiding this comment

jstarry Nov 24, 2020

Choose a reason for hiding this comment

siku2 Nov 28, 2020 • edited

Choose a reason for hiding this comment

siku2 Nov 22, 2020

Choose a reason for hiding this comment

frostu8 commented Apr 7, 2021

hamza1311 commented Jul 19, 2021

siku2 commented Jul 19, 2021

mc1098 commented Aug 5, 2021

jstarry commented Nov 15, 2020 •

edited

siku2 commented Nov 17, 2020 •

edited

github-actions bot commented Nov 22, 2020 •

edited

siku2 Nov 22, 2020 •

edited

siku2 Nov 28, 2020 •

edited