Remove struct components

[voidpumpkin]

So more and more I'm dealing with the camp that loves function components and does not give proper attention for struct components.

Context API has lacking documentation and I know its fixable, but we should have noticed the lack of clarity in the docs for struct components. Just look at this issue #2280

Then we already have a case where somebody wants to add a feature that will not be available in struct components #2212

Hooks overall just cause confusion because we need to be super clear everywhere that your struct component will not rerender on its own when just calling a hook function.

I say lets stop the split. Get rid of the legacy, because unlike react we are in 0.x version and we can do it.

[voidpumpkin]

Ofc i am worried about performance/bundle sizes. We need to make sure of what we would be losing/sacrificing first, before making the decision.

[futursolo]

Somebody here. ;)

I do support the move to function component whenever possible.

However, there’re a couple things to consider before removing struct components:

1. Currently function components are implemented with struct components (might no longer so after Suspense Support #2212).
2. Components that need special treatments (e.g.: ContextProvider and Suspense) cannot be implemented as function component (needs a way to access state and send messages from outside of component).
3. Function Component macro still has things to be worked out. (e.g.: generic with default does not work.)

I think removing most struct component examples / mentions from the website should be good enough for the moment.

[voidpumpkin]

Regarding actions, I agree with you, if we do decide to remove them.
As a first step we just remove examples, docs and no longer recommend using them.

[WorldSEnder]

struct components will not simply go away because at the end of the day, the Component trait allows them and should continue to do so.

Is part of the suggestion of special treatment of function components to auto-detect Html/HtmlResult and provide the correct wrapper code to macro-magic the way to victory? Even so, the endgoal should not be to hide or make it undocumented to implement the Component trait yourself. It's the simplest interface into the lifetime of a component and already much more than what React class components were. You get mutable access to self, instead of having to go through a confusing setState, there's no reasons to deriveStateFromProps etc.

Hooks provide a way to interact with the lifecycle in a function component, but there are several rough edges, like dealing with lifetimes of the contained state, or the fact that you have to call them always in the same order. Dealing with those problems in react, for example, there's a custom lint pass that warns you if you have a hook under a conditional. But at the end of the day, that's just pretending that function components are the end-all-be-all of design which they aren't, imo. If they are the only thing appearing in docs, a loud wake-up call will be heard when another paradigm evolves that solves any of the issues function components still have (do I see generators on the horizon?).

Tl;dr: the Component trait should still be the favored way of interacting the impls under the hood and be the eventual public interface to components. I'm not against breaking changes in it, comps v2 already did that anyway. But simply having that as the common denominator of components means struct comps are allowed and here to stay. No need to push them under a rug.

[hamza1311]

(do I see generators on the horizon?).

I've not really looked at generators but I'm curious, how could they be helpful here?

[WorldSEnder]

@hamza1311 Generators can keep state. So instead of having to put the hook state into globally initialized things. I.e. the generator equivalent of use_state would contain its state and you keep it inside your generator. Since the gen lives across yield points, it doesn't get dropped. Yielding would then be the equivalent of producing a new view, and the generator gets resumed when the properties change/view should run again.

Sadly none of this is possible in stable rust yet, but I might be able to build a small nightly library to explain :)

[hamza1311]

That sounds good. Maybe we could have generator components but only on nightly, like we have lints.

[WorldSEnder]

I implemented this for yew 0.18 already, just had to dig it up, see this gist. Needs upgrading, polishing and more utility around it, but it kinda works.

[Kritzefitz]

@WorldSEnder Sorry, for being so late to the party, but doesn't re-creating the generator with G::start in WrapGeneratorComponent<G>::update mean that the internal state of the generator is thrown away, whenever the properties of the component change? This seems very undesirable to me.

[JtotheThree]

I think supporting both at least in main documentation and philosophy isn't a great idea. All it will do is split an already small community and confuse newcomers when tutorials offer completely different directions. I believe one side would feel neglected and eventually just fork off. I actually prefer Components v2 to functional components so it pains me to say that, but I don't think pushing both is healthy for the project. I don't think v2 is really all that much boiler plate compared to functional components and it does a better job of making code readable.

If the direction is functional components there needs to be a really strong push toward in depth documentation, examples, and ergonomics. I do like the functional components, but they push some of the more complicated aspects of Rust to the forefront. There's a lot of roadblocks that a beginning Rust user is going to slam head first into using functional components, mainly A LOT of borrow checking.

Maybe it's not important to hand hold new Rust developers in Yew, but I think Yew will become a really attractive crate for people coming over to Rust. Web development is extremely popular and there's a lot of people excited to hop off JavaScript. I fear with the state of functional components newbies are going to slam head first into the roadblocks and give up immediately.

With components, most newbies can probably follow a simple tutorial and start building simple websites on their own without having to worry about the intricacies of Rc and the borrow checker immediately.

[futursolo]

The biggest issue for struct component for me is that: rendering is controlled manually.

You can argue this is good. But I think this is like manual memory management, you will get it wrong sometimes. And should stay away from it whenever possible. (Also why I use Rust.)

Function components abstract this away from you by making state update managed.

E.g.: I am the culprit of making #2168 when refactoring yew-router and migrate to function component solves it and prevents it by design.

[Xavientois]

TL;DR: We should keep struct components as the underlying implementation, but promote function components as the recommended way to start building Yew apps.

If we do decide to make the switch to having function components be the primary way to define and interact with components, I think that keeping struct components as the underlying basis is the way to go. I personally find struct components easier to reason about and understand in terms of my own mental model.

While I agree that there is a lot of value in presenting a single unified approach to building Yew apps, especially for newcomers to the framework, removing documentation for an equally valid and sometimes preferred approach just introduces friction for those who choose to use struct components. Relegating the relevant docs around struct components to a dedicated section of the docs could be a good compromise, in my opinion. That way, those who are new to Yew can be presented function components as the recommended approach, but those who prefer to use struct components still get documentation to help them with their desired approach.

Removing struct components as the underlying implementation feels premature at this point, at least until some of the above-mentioned concerns with function components are ironed out.

Regarding #2212, it looks like a super useful feature, but not enough to justify only supporting it in function components.

[futursolo]

Unfortunately, even if it’s possible to get #2212 working in struct components, it’s not possible to get other concurrent mode features (useTransition, useDeferredValue) to work in struct components.

And it has some caveats when using struct components patterns (see details in PR) that could cause confusing behaviour. It’s also my intention to make #2212 FC only to promote function components.

[rjmac]

For my part, I basically never use function components. I considered them bad in React, and I consider them bad in Yew as well as well for the same reasons. Once in a while I might use one for a component that's nothing more than literally a pure function from props to HTML, but absolutely never for anything more complex.

Hooks provide a way to interact with the lifecycle in a function component, but there are several rough edges, like dealing with lifetimes of the contained state, or the fact that you have to call them always in the same order.

..and this sort of thing is exactly why. It means that you have mutable state where the parts of that state are named by the order in which they happen to be encountered at runtime and it's mind-boggling to me that anyone considers that anything other than an enormous flashing sign saying "stay away from this!"

[futursolo]

You pretty much have no escape from hooks these days in React.

React Router
Any React GraphQL Client / React Query

Most React Concurrent Mode features are also FC only.

[hamza1311]

..and this sort of thing is exactly why. It means that you have mutable state where the parts of that state are named by the order in which they happen to be encountered at runtime and it's mind-boggling to me that anyone considers that anything other than an enormous flashing sign saying "stay away from this!"

We can solve this Rust (or at least make an attempt). I remember it being mentioned to use macros for hooks so we could sneak in line!() and file!() to avoid the order problem. I'm personally not sure how that would be implemented but I would like it if someone could write up a detailed proposal for enhancing hooks with the code gen capabilities of Rust.

[voidpumpkin]

This discussion is spooky because as @JtotheThree said "I believe one side would feel neglected and eventually just fork off."

I also learned that its possible function components group may be the minority in yew and as a maintainer i have to make sure struct components will not get neglected.

Lets not do any actions of removing either, perhaps given time everything will marinate a bit and actions we need to take will become more clear, be it embracing struct components or functional components.

[hamza1311]

I agree with others have mentioned: struct components won't simply go away. But we should focus on one type of components in examples and documentation.

Also worth noting is that today, function components have an additional cost of initializing global state for hooks to be used. We need to be remove (or at least benchmark/reduce) that before making a decision to fully switch to them. Also, like I mentioned in #2282 (reply in thread) hooks have the potential to benefit from macros and code gen. We should to explore that too. There's many things that should be explored before a concrete decision here can be made.

[bcpeinhardt]

Hello! Just a random person on the internet adding my two cents.
I personally find that it's not at all inconvenient or indecisive to support both struct and functional components. I don't see any reason to commit to one or the other. I find functional components really convenient when most of the "state" gets passed in as props, or for simpler components with just one or two dynamic parts. But when components become more complex, I generally like to refactor them into struct components. I think it's hard to overstate the organizational value of a Msg enum that has a variant describing each and every way the component might update itself, and a trait (which most editors will let the user autofill with required and optional methods via keyboard shortcut) that describes all available lifecycle entry points neatly. Once you do anything remotely complex in terms of the lifecycle with a functional component, like an http request to get the state for the component, you end up either 1. not handling the lifecycle ramifications and end up with awkward blank space and long load times or 2. wiring up your own set of lifecycle methods with hooks and match statements that require more mental overhead to understand than a struct component would. In short, I personally use functional components to express the template nature of components, and struct components to manage components with complex life cycles, and I think that's fine! I think when developers are compiling their frontend to webassembly, they're unlikely to be daunted by the difference between a struct or function component, and folks migrating from react or similar are likely to already have a strong opinion about which approach is better for their use case, and if they're really smart, they'll see the value in both c:

[bcpeinhardt]

P.S. regarding macros as an escape hatch for dealing with clones and lifetimes etc. in function components: I love a good procedural macro, but I think one of the big benefits of rust is that it does force you to be thoughtful about things like clones and lifetimes. I think the compiler is trying to tell us something, and we should probably listen instead of hiding behind a macro.

[intendednull]

I agree documentation and simple examples should focus more on functional components. They are easier to understand initially, and what most developers will recognize coming from frameworks like React.

That said, hooks can easily become an anti-pattern when used for too complex a task. Elm architecture works because it clearly organizes component behavior. Struct components are a vital foundation, which functional builds on top of. Removing them would effectively cut the legs off this project.

[SirVer]

I'd like to provide a different view point. Being mostly a C++/Python/Rust developer, but with quite a bit of foray into frontend, I find struct components much easier to understand and much cleaner to compose. The functional components feel like 80% use cases to me, but I struggle to implement what I need with them some times.

The documentation is frustratingly lacking - right now I am working myself through ContextProvider somewhat between 0.19 and next - and the functional components do not seem to be offering what I need, and the struct way of doing ContextProviders is not even documented in 0.19.

To me, the struct components have more boilerplate, but the design feels cleaner and easier to understand. Functional components are shorter and are full of magic. I understand functional components is the React way and that might appease frontend devs coming in, however struct components feel like the Rust way to me. I personally would have preferred to never have functional components at all and focus on the functional one. Whatever remains, better documentation for both would be highly appreciated.

[futursolo]

I have created a prototype (#2957) to demonstrate what would be possible if function components are the only type supported by Yew.

In summary,

If struct components are removed, we can:

1. remove many allocations. (create is 1 allocation and subsequent lifecycle events are free of allocations.)
2. remove generics from most internal types used in rendering and component lifecycles.
3. remove some workarounds in the codebase (e.g.: priority render on hydration).

This means that without struct components. Yew will have:

1. smaller bundle size. (5~10% reduction)
2. better performance. (SSR benchmark is up to 100% faster)
3. a cleaner codebase.
4. a smaller public API.

Whilst I do not expect that struct components to actually become removed at anytime soon, I think a function component-only Yew does provide some significant advantages than being compatible with both component variants.

[intendednull]

I don't think struct components should ever be removed. There are already promising alternatives that do functional very well.

For me Yew's allure has always been elm architecture support. Hooks are not the answer to everything, and forcing everyone to wholly depend on them is a bad idea.

[allan2]

That's awesome! I'm curious to see how this affects bundle size and performance in larger apps.

[futursolo]

I don't think struct components should ever be removed.

At this moment, this is more to help the community to understand why I think struct components are holding back the internal architecture of Yew significantly and what would otherwise be possible if Yew foregoes struct components.

Sometimes we have to add workarounds in code simply to keep the current architecture working (especially with hydration).
I personally hope there is a solution to this even if this ultimately means we have to remove struct components.

[intendednull]

I think struct components are holding back the internal architecture of Yew significantly and what would otherwise be possible if Yew foregoes struct components.

Would it be possible to instead rework struct components to fit better? I'm more concerned about preserving elm architecture. If struct components (as they are now) are holding the project back, maybe there's a better way to fill their role?

[hamza1311]

What if we feature-gated struct components? Those who want it can enable it. Every one can get benefit from function component only Yew

…

On Wed, Nov 9, 2022, 5:50 PM Kaede Hoshikawa ***@***.***> wrote: I have created a prototype (#2957 <#2957>) to demonstrate what would be possible if function components are the only type supported by Yew. In summary, If struct components are removed, we can: 1. remove many allocations. 2. remove generics from most internal types. 3. remove some workarounds in the codebase (e.g.: priority render on hydration). This means that without struct components. Yew will have: 1. smaller bundle size. 2. better performance. 3. a cleaner codebase. 4. a smaller public API. Whilst I do not expect that struct components to actually become removed at anytime soon, I think a function component-only Yew does provide some significant advantages than being compatible with both component variants. — Reply to this email directly, view it on GitHub <#2282 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALJJ7WIYTUCIEJSCDNZI6EDWHOMZNANCNFSM5KKVLVKA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[intendednull]

How would this work? Functional still uses the same trait. Is separating the two is maintainable?

[futursolo]

Based on the experiment, the biggest benefit of removing struct component comes from removal of scheduler.
Lifecycle events are now called directly as normal functions so the runtime cost are much lower.
The rendering process is fundamentally different from what's present in the master branch.

Feature gating struct components would require feature flags to be applied to many different locations adding to existing ones.
It also means that Yew would work differently with and without struct components.
This would be difficult to maintain and may introduce bugs that only presents in one mode.

However, I think it might be possible to build struct components with function components, inverting the relationship between function components and struct components. This might require Properties: PartialEq + Clone.

[WorldSEnder]

Based on the experiment, the biggest benefit of removing struct component comes from removal of scheduler.
Lifecycle events are now called directly as normal functions so the runtime cost are much lower.

I'd have to have a deeper look at #2957 to see where the performance gains are coming from. The removal of the scheduler is a big and convenient part of the change and I don't immediately see why this couldn't be done with struct components present - be it by reworking or replacing the messaging API. But I also would want to see a deeper look into this scheduler-less mode. Which order of operations is guaranteed, which is incidental from the implementation?

Further, with function components and use_state, a re-occurring pattern I see is Rc::make_mut in some reducible. I think this is just a poor-man's hack around a lack of mutability and exactly the trade-off that avoids a scheduler by trading it for additional clones (in the case the Rc is held somewhere else).

Instead of measuring the PR on examples that already were implemented mainly as function components, how about comparing an example implemented mainly in struct components and re-implementing it with function ones (as a challenge do game_of_life, since that one is rather stateful)? That's more work, but the comparison is fairer to everybody else who'd have to migrate.

I also think that a feature gate would be incredibly hard to maintain.

[intendednull]

I don't immediately see why this couldn't be done with struct components present - be it by reworking or replacing the messaging API

Yes! An internal rework of struct components could be super beneficial, and maybe solve a lot of the feature segregation? As long as we can clearly organize component messages and lifecycle events (outside of view logic), I'm sure innovation here would be welcome.

[futursolo]

The primary reason why the architecture in #2957 does not work with struct component is due to the any parent component will keep to be mutably borrowed until all children is rendered and all effects executed. APIs like Scope::get_component() will not work.

In addition, as function components are essentially a function with signature of fn(&Props) -> Html, this allows many generics (e.g.: Scope<...>) to be removed, resulting in a smaller bundle size.

For SSR, as we no longer have to call Component::create(...) and Component::destroy(...), we don't have to initialise ComponentState which makes Scope to be usable, we can simply call function components's main function in a loop until it returns Html instead of suspending. This improves performance of SSR drastically.

The lifecycle of function components is simpler, we only need to provide 2 guarantees (essentially 1 as child components are not known until parent is rendered):

1. Parent components are rendered before child components. (first render)
2. Child effects are executed before parent components. (effect)

I do expect #2957 to have issues as it is nothing more than a PoC. However, I do not see any design issues that would prevent it from being fixed. In a final design, we might have to keep a single queue in the scheduler as we might still want to always guarantee parent events being executed before child components in automatic message batching, however, still, only the topmost component event will need to be queued in the scheduler to guarantee this as render is side-effect free which should not result in state updates.

During effect stages, we need to execute all pending effects first before render can happen again.

[ta32]

I feel struct components are easier to understand - as a beginner. I am still getting used to functional components

[dynamoRando]

I wanted to say that I agree with this. For reason I can't pin down yet, I have tried and repeatedly failed to make function components work with the app that I'm starting off with.

[AsbjornOlling]

+1 - I'm coming to Yew from Elm, and I strongly prefer struct components.

[skoe]

Even if "me too" posts are usually not useful: I also find struct components much more cleanly structured (pun was not intended :) ) and easier to grasp. The reason may be that I value less voodoo more than fewer lines of code - just a personal preference. I was already quite frustrated about the handstands I have to do to use contexts in struct components (examples/contexts/src/), or maybe I just don't understand it yet.