Has anyone tried using compose-web with mdc yet?

Not that I know of, but it should totally work. Let us know if you run into any issues. Assuming you do try, and assuming you wrap the widgets in composable functions, please do share those functions on github so we can point others to your wrappers!

Couldn't figure out how to setup webcomponents wrappers as a klib, so just did a regular mdc wrapper here. Only TextButton with optional Ripple side-effect, but works like a charm so far.

@Big Chungus that link 404s for me

the file moved to here

Yeah, force-pushed some updates that overridden commit history 😅

@Big Chungus This looks really nice. I noticed that the styles injected into the served page had base64 encoded text appended to them - I think webpack is encoding the sourcemaps referenced from the CSS. Adding sourceMaps = false in the commonWebpackConfig section of build.gradle.kts prevents that.

I was looking how to theme, thanks!

Additional variables are described here

6 months later, any updates to this? Has anyone gotten a start on wrapping MDC components for compose-web?

I've made some progress with kmdc, but it's still not even halfway there. Feel free to copy what I have and wrap the missing components that you need by example

For reference, here is that code: https://github.com/mpetuska/kamp/tree/feature/compose/lib/kmdc/src/jsMain/kotlin

If anyone wants to collab on this, ping me and I will extract that module into its own repo prematurely to facilitate that. At this point it's just shitloads of dumb and tedious code to write. All the quirks are already ironed out...

@Big Chungus My team and I would be interested in that

Sweet, I'll prepare the repo tomorrow. We can then have a quick chat/call to bring you up to speed on lessons learned so far with wrapping.

You could also take a look at: https://github.com/JetBrains/kotlin-wrappers/tree/master/kotlin-mui

Oh nice, thank you

Yes, but a good start

Ok, here it is. Also released it to mavenCentral as a preview with what I got under 0.0.1

I'm a bit late to the party, but I'm also interested in Compose+MDC. I had already extracted kamp/kmdc stuff into a local library, but so far it was merely experimental. To use this productively in forms-based scenarios, it seems that I'll need more flexibility, which currently only Sass-based customization provides. For example, I need to set the density scale for text fields, which can be accomplished via the

density($density-scale)

mixin: https://material.io/components/text-fields/web#api I'll be happy to drop my local experimental library, switch to KMDC and test what's already there. Additionally, I'll be happy to contribute whatever I might come up with, though it might take some time to bubble up my priority list.

Hmm, sass support might be hard with current kmdc implicit loading. I'll see if I can unlock it somehow over the weekend.

Regarding additional components, my first idea would be to create some documentation on how to create those manually. As I'm not too familiar with the details of style-loader and such, I might be a good guinea pig to question some stuff (and discuss possible explanations), like: Why is there a style variable referenced at the beginning of each component (like

MDCTextFieldStyle

)? Probably to make the loader aware. Why is the unused variable not eliminated by the Kotlin compiler? – The idea is that some additional documentation might make it easier for others to contribute, and thus attract more contributors. Does that sound reasonable? Regarding Sass, here is one density example that illustrates what I'm looking for: https://material-density.glitch.me/. A working Sass-based implementation would be excellent, so I'd appreciate your efforts towards this goal. Please let me know if I can assist with testing. Additionally, I have been looking at generator-based approaches like kotlin-mui for React-MUI. I'm not sure whether that might be feasible here (probably it's not).

Lots of good points! Gonna be a busy weekend 😄 To answer some of your queries now: • Style variable referenced in each component are required to load "side effects" as kotlin has no build-in way to do it properly and unused variables are removed by DCE. So this is basically a hack to load css via style-loader if that component is used. • Generator aproach for mui (and other react frameworks) works nicely, because both, react and compose, are declarative frameworks so APIs can match quite closely. This is not the case for MDC, unfortunatelly, as it is imperative framework and there's a lot of edge-cases to handle when mapping that to declarative compose (Have a look at MDCTopAppBar if you're curious) I'll try to document my approach so far in some .md to hopefully make it a bit more transparent.

@Oliver.O I've got the sass integration with kmdc working, if you are still interested.

I'm interested too. Can you share your setup?

Me too! 😄

If it can be simplified to require minimal input from consumer projects, I'd love to switch kmdc to scss altogether.

I’m definitely still interested! 😃

Ok, here goes. First, in

webpack.config.d

, add

sass.js

to inject this configuration into the webpack setup for Kotlin/JS:

config.module.rules.push({
  test: /\.(scss|sass)$/,
  use: [
    /**
     *  fallback to style-loader in development
     *  "style-loader" creates style nodes from JS strings
     */
    "style-loader",   // translates CSS into CommonJS
    "css-loader",   // translates CSS into CommonJS
    "sass-loader"   // compiles Sass to CSS, using Node Sass by default
  ]
});

In

build.gradle.kts

, in the JS dependencies, add:

// for theming mdc
implementation(npm("@material/theme", "^13.0.0"))
// for sass support
implementation(devNpm("sass", "^1.42.1"))
implementation(devNpm("sass-loader", "^12.3.0"))

Add `scss`/`sass` files in the JS resources, and then

require

them in your Kotlin/JS code:

external fun require(o: String)
// resources contains `ccs/whatever.scss`
require("./css/whatever.scss")

Thanks for sharing! I'll be looking into it. Will be interesting to find a way of integrating Sass into the kmdc library with as little configuration as possible on the library consumer side. Maybe it boils down to just another Gradle plugin.