search

material-components / material-web

Material Design Web Components
https://material-web.dev
Apache License 2.0
9.23k stars 883 forks source link

Create demos that demonstrate usage inside different frameworks #1330

Open ghost opened 4 years ago

ghost commented 4 years ago

Is your feature request related to a problem? Please describe. The date of first release from this repo is May 09, 2018, Its almost 2 years now. I know all contributors might have worked with some limitations. but still it's a long time. Here is my few suggestions to help developers to make their life easier.

Describe the solution you'd like We can do following things to make developers life easier. 1st Kindly release all completed components to 1.0 (production Ready) and then work for remaining so developer can start experimenting with it, right now what happens repo shows its not production ready so no one is trying to use it. And it will also help them to get familiar with such new and powerful technology. 2nd Add some examples in repo or in docs like how to use it with other frameworks like angular, react & vue. Which will help new developers to get started. 3rd Add components from this repo so more developers can have an idea that what can be done with lit powered components. 4th All this things will help them to build their own in house design system on top of this lit powered technology with this components so it will be very useful for small teams and for new developers also to get started.

So without delaying now all contributors of this repo are requested to release all completed components to V1.0. And now as per current situations with corona days and remote work it will also help developers to achieve more and faster

Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.

Additional context Add any other context or screenshots about the feature request here.

ghost commented 4 years ago

@asyncLiz @e111077 @dfreedm @aomarks Any consideration for this guys?

e111077 commented 4 years ago

Hello, the reason we have not tagged this as 1.0 is because it is very much not ready for production. There are large scale refactors and changes coming very soon so it would not make sense to tag as 1.0 then make those changes.

Your second point can probably stand as a feature request on its own.

Third point includes components that are not related to Material Design, and this repository is to showcase our Material Design components not LitElement.

ghost commented 4 years ago

@e111077 ok, thanks for response.

cintaccs commented 4 years ago

There are large scale refactors and changes coming very soon

@e111077 Thanks for all the work you are doing on the components! Can you, by any chance elaborate a bit on the refactoring and changes coming soon? I believe a lot of developers are already depending on the Material Components and it would be nice to know whether we should expect fundamental changes?

e111077 commented 4 years ago

There will be fundamental changes. Likely to custom element naming, package names, and repo location. Likely place we will live in is in the MDC repo at

https://github.com/material-components/material-components-web

Also large API changes to support deeper theming and future SSR integration (think start up state on every component be describable via declarative props). OS consumer-side SSR will be way later down the road; we are only starting with internal Google SSR and working our way to external from there.

ghost commented 4 years ago

There will be fundamental changes. Likely to custom element naming, package names, and repo location. Likely place we will live in is in the MDC repo at

https://github.com/material-components/material-components-web

Also large API changes to support deeper theming and future SSR integration (think start up state on every component be describable via declarative props). OS consumer-side SSR will be way later down the road; we are only starting with internal Google SSR and working our way to external from there.

@e111077 I think you guys should update Readme with roadmap so other developers can have some idea that what is going on and what's has been planned. OR make new roadmap file and link it to readme, its ok if everything is with no ETA. This will really help new developers to take decisions easily and also will help to keep patience from developer side. If roadmap is detailed and well explained then developers can start playing with such new, powerful and cutting edge technology like lit-html & lit-element also.

And can't you release first all components without SSR and production ready so developers can start their projects with that? Rest of the features you can develop later, not possible?

Because developer community is waiting from last few years for this.

cintaccs commented 4 years ago

There will be fundamental changes. Likely to custom element naming, package names, and repo location. Likely place we will live in is in the MDC repo at

https://github.com/material-components/material-components-web

Also large API changes to support deeper theming and future SSR integration (think start up state on every component be describable via declarative props). OS consumer-side SSR will be way later down the road; we are only starting with internal Google SSR and working our way to external from there.

Thanks a lot for more details! I appreciate the effort!!! As SSR seems to be a bigger thing on lit development too - do you have somewhere a desciption / youtube video / something that explains why SSR should be such a big thing for Web component implementations? I am not sure it is super clear why the server side pre-rendering is a benefit ...? and with the current functionality attrbutes of Array and Object types can already be delivered on the components - so I don't see why SSR eventually wouldn't be just delivering the components together with such attributes and properties set?

e111077 commented 4 years ago

One main reason is that we went to build webcomponents that fit into anything anywhere which means any framework. Quite a lot of frameworks implement SSR which means that despite their code being in the client, sometimes it lives in the server (see NEXT js for a real interesting mix of client and server). So if WCs want to live everywhere with 0 compromise, they must also find a way to live in the server.

The problem is that each SSR implementation is unique to its framework. Unlike client-side where they all rely on the same thing, the browser. This makes it a difficult problem and is reason why our progress has been slow. Therefore we are going with an internal google framework first which we think is likely the "hardest-case" scenario.

cintaccs commented 4 years ago

@e111077 thanks a lot for explaining - much appreciated!!!

manian-kumaran commented 4 years ago

Web component is supposed to be usable in any framework. But the readme only shows for plain HTML and javascript.

There is short guide: https://reactjs.org/docs/web-components.html on how to use web component.

Simply importing material-components-web-components in create-react-app

import '@material/mwc-button';

...

<mwc-button ..../>

works in development environment, which is great!

But building it to production environment fails to run with error:

(node:4556) UnhandledPromiseRejectionWarning: node_modules/@material/mwc-button/mwc-button.js:1

import { __decorate } from "tslib"; ^^^^^^

SyntaxError: Cannot use import statement outside a module

It seems create-react-app's webpack fails to build mwc-button module into the bundles.

Short README into how to include material-components-web-components in create-react-app will be good starting point for developer adoption of this module.

e111077 commented 4 years ago

This seems unrelated to the framework and more about your build system. If it works in development but not in production it seems as if type="module" was removed from the script tag or this imported component was not properly bundled. This isn't something to do specifically with react (or web components for that matter) but rather your bundler / DOM transformer between production and prod

manian-kumaran commented 4 years ago

Thanks @e111077 Webpack was used to build for production. I only see Rollup in the readme to build for production. Is there instruction to build using Webpack for production?

e111077 commented 4 years ago

IIRC the default config for webpack should already resolve modules inside the node_modules folder unlike rollup. Please refer to the module resolution documentation for webpack in case your resolve config has been customized:

https://webpack.js.org/concepts/module-resolution/#module-paths

https://webpack.js.org/configuration/resolve/

mangelozzi commented 1 year ago

The date of first release from this repo is May 09, 2018, Its almost 2 years now. I know all contributors might have worked with some limitations. but still it's a long time.

Now 5 years later, can you believe it! Anyone else reading this probably also loves web components, and material design, and wishes Google has some big product using this to drive it forward. I think lack of web component adoption means this is a "nice to have".

It looks like to me Material design 2 based on native web components never reached version 1, and was abandoned because MD3 came out. Will this project ever be finished before MD4 comes out? Will it also be abandoned?

e111077 commented 1 year ago

Heya, I'm sorry about the frustration, I've felt the same for 5 years, you gotta believe me. I think a bit of history about our big corp experience can help put things into perspective; this repo was made at the announcement of Material 2.0. Objectives have shifted quite a lot since then. Since inception:

Component completion is targeted in 4 sprints from now, and Material 4 is not anywhere close to existing at all, but the messy rollout of Material 3 across google has brought the concerns we've had about migrations into perspective higher up the chain. Material 4 is expected to have a clearer migration path, and smaller scope ambition.

Please know that the engineers on this project have always been on the side of our users and have pushed for better third party DX, development speed, and prioritization every step of the way, but have had to deal with shifting direction from above. We're really proud of the huge amount of work we've been able to ship in just the last 4 months of 1st party deprioritization despite layoffs, and we think the library is finally starting to shape up, and so do our internal dogfooders. I hope you will too, especially once we free up headcount to work on docs + demos.

We've been hoping to include framework wrappers in this package starting with React using @lit-labs/react. There is a broader effort for FW integration in the core Lit side, but we might ship before those are ready. Additionally, WC integration on other FWs tends to be generally good, so wrappers may not be necessary, just examples.

Post 1.0 would include SSR support, but our 1.0 MVP is shipping all the components first to client-side and ship across ChromeOS for industry battle-testing.

christophe-g commented 1 year ago

@e111077, thanks a lot for the background info (that anyone monitoring this repo was kind of guessing). Putting it clearly into perspective is appreciated and somehow a relief.

JWess commented 1 year ago

Heya, I'm sorry about the frustration, I've felt the same for 5 years, you gotta believe me. I think a bit of history about our big corp experience can help put things into perspective; this repo was made at the announcement of Material 2.0. Objectives have shifted quite a lot since then. Since inception:

  • we were re-orged from Chrome to be under material design and had to align with their tech stack
  • leadership prioritized first party project requiring lots of rewrites for internal google stack alignment and degradation of our third party DX
  • those delays led to material 3 releasing before mwc 2.0 was in a better state
  • leadership requiring a material 3 implementation
  • design tokens not there yet due to the large scope and complexity of Material 3, so delays

  • leadership de-prioritized first party infrastructure

    • this is actually good
    • velocity has increased significantly
    • we spend time slashing out useless cruft
    • component completion targeted 4ish sprints from now
  • layoffs and we've lost a few engineers :(

Component completion is targeted in 4 sprints from now, and Material 4 is not anywhere close to existing at all, but the messy rollout of Material 3 across google has brought the concerns we've had about migrations into perspective higher up the chain. Material 4 is expected to have a clearer migration path, and smaller scope ambition.

Please know that the engineers on this project have always been on the side of our users and have pushed for better third party DX, development speed, and prioritization every step of the way, but have had to deal with shifting direction from above. We're really proud of the huge amount of work we've been able to ship in just the last 4 months of 1st party deprioritization despite layoffs, and we think the library is finally starting to shape up, and so do our internal dogfooders. I hope you will too, especially once we free up headcount to work on docs + demos.

We've been hoping to include framework wrappers in this package starting with React using @lit-labs/react. There is a broader effort for FW integration in the core Lit side, but we might ship before those are ready. Additionally, WC integration on other FWs tends to be generally good, so wrappers may not be necessary, just examples.

Post 1.0 would include SSR support, but our 1.0 MVP is shipping all the components first to client-side and ship across ChromeOS for industry battle-testing.

Very helpful context! Any chance you might have another update like this, now that it's been another 6 months? Thanks

e111077 commented 1 year ago

1.0 Release date is set for September 25th. We are doing a concerted burndown of launch blockers which is a very slim list. Personal high confidence of hitting that date. In the meantime lots of breaking changes so that we don't have to do them post 1.0.

What 1.0 means

Take this as a preliminary meaning for 1.0. We will have an official blogpost somewhere by launch solidifying what is 1.0

What is not in 1.0:

What not supported:

TechQuery commented 7 months ago

What is not in 1.0:

  • Official React / JSX wrappers

@e111077 I have rendered MD Web components v1 successfully on WebCell v3 & DOM Renderer v2 without any extra JSX wrapper: EasyWebApp/material-cell#2

SaadBazaz commented 3 months ago

We (Grayhat) have created a demo for React, which is in-sync with this repository. It's in its early stages, we'd appreciate any help.

https://github.com/grayhatdevelopers/material-web-react