Closed In-line closed 4 years ago
There has been some work before on this, most notably yewstrap, but they tend to stall after a while.
Recent changes to how Html
works should make sure that there is an ergonomic payoff to creating these libraries. Before now, you wouldn't be saving a huge amount of effort by making these libraries due to how callbacks/Html worked.
These kinds of libraries are sensitive to breaking changes, and yew has been making plenty of those over the last few months. Ideally the next release will be the last big one before a 1.0.0, so now (basing off of master) might be a nice time to start.
Is it possible that components could be made interoperable between compatible Rust-based frameworks? https://github.com/rustwasm/gloo may be a useful coordination nexus.
Given how each framework/library has their own component implementation and VDom representation, I think it is hard or impossible to define some common standard for component definitions.
https://github.com/Follpvosten/yew-mdc (work in progress)
I believe @trivigy is also working on a material design component library. Maybe the two efforts can be combined?
Missing labels:
@trivigy @Follpvosten @gmorus y'all have any thoughts on how we could better coordinate efforts here? I think more visibility could help. Building a component library is quite a large endeavour.
So, yew-mdc is very much a work in progress right now, and its development currently also very focused on our internal usage - I'm only implementing the functionality we need, when we need it, and formal releases don't really fit into this development model I think.
I'm also not sure how external contributors would fit into this, but I would definitely be interested in some coordinated efforts. Not entirely sure how to initiate tho; maybe we could start increasing visibility by providing some example projects and linking them from the yew repo's README? The currently linked project templates are severly outdated anyways.
@Follpvosten I just created a "Github Project" to help organize efforts here: https://github.com/yewstack/yew/projects/4
Here are some ideas:
We could start off by sprucing up the Yew examples as you suggested to use yew-mdc
. Then, when some needed components don't exist, contributors can create and fix issues on yew-mdc
.
It would be great to continue development with yewstrap
. @gmorus what do you think about moving the project to the yew organization?
Yew used to have a "Select" component in the yew::components
module. I moved it to yew-components
crate for now but I haven't published it yet. Maybe we don't need it? Or maybe it can be for unstyled components?
Should also note that https://github.com/yewstack/yewtify is in development now
I don’t think this should be attempted until functional components and hooks land. Throwing everything into stateful components and sharing functionality in a non-hooks way will become obsolete for a lot of components in the library.
What should be focused on right now are core things like
@thinkpadder1 I'm not necessarily sold that this depends on functional components but I do very much agree that we should be focusing on points you've outlined.
I think we really need someone to help scope functionality and then apply that to one of the nascent component libraries we have started.
I know of some good design systems. Let me know and I’ll get them for you since I’m currently on my phone.
That'd be great if you shared those 👍
@thinkpadder1 I'm not necessarily sold that this depends on functional components but I do very much agree that we should be focusing on points you've outlined.
Sorry, I meant the Hooks API.
That'd be great if you shared those 👍
https://baseweb.design/ Specifically, look at their override system: https://baseweb.design/guides/understanding-overrides/
I'm going to wind down this discussion. We had some good discussion in this issue on how to better promote community libraries which should help 👍
Like React material-ui, reactstrap and so on.