Hi all. I'm curious to hear your thoughts on these...

# kmdc

[Big Chungus]

Hi all. I'm curious to hear your thoughts on these two design choices:
1. KMDC API to match MDC api (component/element wise) 1:1 with occasional and few exceptions to be more idiomatic for kotlin consumption
2. KMDC API to introduce its own components that makes some assumptions on the structure and only matches and extends the top-level MDC component to better utilise the fact that it's rendered by Kotlin and not direct HTML.
3. Full support for #1 with DSL to get #2

[Kiryushin Andrey]

Can you give an example of #2?

[Big Chungus]

https://github.com/mpetuska/kmdc/blob/master/kmdc/kmdc-select/src/jsMain/kotlin/MDCSelect.kt

[Big Chungus]

It deviates from mdc api quite substantially to provide item type safety

[Big Chungus]

We've tried to avoid #2 so far, but with it items could be made part of select opts to render entire component with options.

[Kiryushin Andrey]

I’m trying to imagine how select component could look like with #1… So selected text container and list items all would have been separate components, nested inside the select component, right? being in 1:1 correspondence with mdc api, but loosing the invariant that selected text should be the text of one of the items

[Big Chungus]

Well it would look exactly like MDC and would be uncontrolled. Plus all values would have to be strings or Any

[Greg Steckman]

Something to consider is the long-term objective of kmdc: is it to a) wrap material-components-web (https://github.com/material-components/material-components-web), or b) provide material design components for Kotlin/Compose on the web platform (that is, components following the design system laid out in https://material.io/). If "a", then option 1 is probably the right approach. If "b", then utilizing material-components-web can be thought of as a pragmatic approach to quickly getting a functional implementation in place, while long term it may be desirable to write additional components, replace some or all with Kotlin for enhanced functionality, type safety, etc., and extend or enhance the components with more idiomatic APIs. That leads you to option 2 or 3 which is a bigger undertaking but also more valuable. I believe option 2 (or 3) will require more effort on the documentation because if kmdc is only a simple wrapper you can easily rely on the material-components-web documentation to figure out how to use it.