preact-material-components: Dont be a thin opionionless wrapper over `mdc-web`

This library started as a thin opinion-less wrapper over mdc-web. Which meant that we were just a declarative preact layer above whatever mdc-web ships.

Also this was my personal decision because mdc-web was/is a great lib to build modern web apps. They had extensive set of UI components, all served separately which was superb for perf. They had gestures and every thing and seemed the perfect fit.

Overtime however they have jumped over many breaking changes due to

a.) because they never said to be stable b.) because may be they are prepping for material 2.0

In past I have tried to stick as close to mdc-web as possible because frankly I never wanted to be an author of a gigantic UI lib alone, that too when our weekly downloads are ~600ish. But now we have a decent set of contributors to the lib

Now I see the frustrations of going through breaking changes every now and then(renamed components, renamed props etc etc) and also mdc-web has decided to remove gestures from the lib. I always wanted this lib to be a tool for modern web and without gestures its a no go.

Ideally I would want to keep this lib based on but not restricted to mdc-web.

We need to have gestures and a stable developer experience if not available by mdc-web, and also should polyfill any super obvious components if not available, say spinner.

But before I push the entire codebase on this journey I’d like to ask and see what the core team members think

a.) is it worth the time with the https://github.com/material-components/material-components-web-react getting more mature?

b.) does every one still feel enthusiastic and have enough free cycles to go over a major pmc2.0 release?

If it turns out that this all might not be worth it, I’d be happy to retire this repo in favor of material-components-web-react and make sure it works with preact so that the users of our lib are not left in limbo.

About this issue

  • Original URL
  • State: open
  • Created 6 years ago
  • Reactions: 3
  • Comments: 18 (5 by maintainers)

Most upvoted comments

tumblr_oeblsgtp1p1v1qzojo1_500 Ok let’s rip this thing open and make it better. Here’s a few things I’d want to do.

  • create a project and clear tasks for 2.0
  • make this a monorepo and lerna
  • release the current update in hand
  • write a public blog post about the change
  • stop further updates till 2.0 unless super important
  • decide a goal for increase in average installs per week.

I think we should go forward with this. Even though it might take a lot of work. I think it will be worth it in the end.

a) that sounds like a good idea first, but if you try to use typescript and preact with react libs you can simply give up b) I mean it won’t be up to date after a day, but I can work on it. Maybe we could pin the versions and just update from time to time. Like every few months.

Also I’m in favor to just sometimes be not a direct wrapper of mdc-web, but to invent components based on them and the material guidelines

I get your feeling, i am also wrapping some material components on my company frontend, as our design is mostly based on Material, it helps allot to use their css to base our components, and it’s frustrating that many updates just break most of my code. I hated when they decided to remove the non boxed version of textfield, my designer hated it even more 😞 so i had to override some styles to get the old look back, keeping the new features.

Actually i am not working at the moment in any project with preact-material-components. I hope material-components-web-react get more mature, supporting more components and preact. Maybe we can help with that.

It would be good to have a rough guideline like “PMC implements material design, using material-components-web where possible”.

I’m extremely supportive of this direction. This library is important for Preact’s ecosystem and community, and we haven’t done enough to highlight that. PMC should have it’s own Guide section on the Preact site, and we should promote it in our boilerplates. We should feature it on the getting started page alongside Preact CLI.

I just started a masters degree and run a company on the side, so honestly I don’t think that I’ll have time for this project, sorry. 🙁

I can still handle the infrastructure / Travis part of things, but that’s pretty much it, maintaining or reviewing PR would probably be a bit too time consuming.

Also we should consider breaking down the components into single packages like many packages do these days, because then we fix and release them individually.

Also we should consider writing some documentation on our structure and strategy before refactoring and document breaking changes and how to fix them in the future in some kind of documentation so we can just point people to that.