Svelte Material UI fork (Typescript + MDC 7+)

[raythurnevoid]

Hi,
I open this issue to announce that i'm actively working on a rewrite of this library to accomplish these goals:

• Make this library Typescript first (it's awesome and allows complete integration with vscode and svelte intellisense)
• Upgrade to MDC 7.0.0 and add missing MDC components
• Upgrade APIs in order to make it simpler

Here you can check my progress:
https://github.com/monkeythedev/svelte-material-ui/tree/typescript_4+material_7

I'm still deeply working on it every day, i'm around 1/2 month away for a first preview release.

My focus is on make the API as simpler as possible to allows easy integration without even reading the docs but keeping and expand current features.

There are actually 3 other libraries that implements material in svelte, i hope this to become the community favorite because using MDC underneath it implements correctly Material guidelines.

I hope @hperrin you're still alive 😅 to discuss about this and eventually for a pull request.

Important notes

Here i write some statements that i propose for the future of smui.
I'm open for discussion of any kind.

Deprecated MDC Components

In my version i'm dropping support for deprecated components (as "standard" textfields, only filled and outined will be supported) because i think that this library must be Material guidelines compliant and when google drops a component this library should drop it too.
Moreover keeping support for deprecated components is heavy time consuming over time and there are no real pro about it.

However in the future it would be possible to reintroduce deprecated components through integrating with external packages. They just wouldn't be in the core of smui.

use$* and on$* props

I'm dropping these props because i don't find it to follows actual svelte design.
I'm replacing on$ with regular svelte on:
For use$ since svelte is never going to support actions for components, i designed something that reminds React hooks that will in some ways replace this feature.

Hooks

Demo

<Use effect hook={logAfterMount}></Use>
<Use hook={() => logOnClick(() => count)}></Use>

{label}: <button on:click={() => count++}>Cllick me to log</button>

My Roadmap

• Preview/beta release (I wish @hperrin allows it to pull request it here) - November/December
• Website restyling - starting from January going on indefinitely
• Stable release - February / March

After i've stabilized the library i can start to discuss about adding new components and features!

[userquin]

Please, add passive events if you can

[userquin]

see #83 (comment)

[maku]

@monkeythedev from my point of view, it is (by far) the best way, to build a layer on top https://github.com/material-components/material-components-web . This is also the path that the Angular Material team has taken, although they have already made a huge effort to create the components themselves. It is very important that "production ready" UI libraries are available because otherwise the use of Svelte cannot be argued. A key point would be to make it easy possible that people can contribute....

[maku]

@monkeythedev can your work be used already?

[raythurnevoid]

@monkeythedev can your work be used already?

I would suggest not yet, i'm still doing core changes every day

[maku]

@monkeythedev I am curious how do you "organize" your work - You forked https://github.com/hperrin/svelte-material-ui and https://github.com/hperrin/svelte-material-ui is not very active. Do you plan an independent project ?

[raythurnevoid]

@monkeythedev I am curious how do you "organize" your work - You forked https://github.com/hperrin/svelte-material-ui and https://github.com/hperrin/svelte-material-ui is not very active. Do you plan an independent project ?

I hope the original author would return at some times, if not, i'll see

[abdatta]

This is exactly what I was looking for! Thanks a lot @monkeythedev , will be eagerly waiting for your release! Lemme know if I can help you with anything!

[kayakyakr]

This sort of library probably should be communitized so there's really just a single library. Helps us svelte newbs know what to use. This one gets the SEO, so I hope you're successful @raythurnevoid. Maybe @hperrin would be able to make an appearance and select a few additional maintainers to help out.

[raythurnevoid]

This sort of library probably should be communitized so there's really just a single library. Helps us svelte newbs know what to use. This one gets the SEO, so I hope you're successful @raythurnevoid. Maybe @hperrin would be able to make an appearance and select a few additional maintainers to help out.

I agree, it would be great to join forces and speed up development... Svelte really needs one safe material library option.

Actually i'm still working on it. I hope to being able to release a beta version by december.

[KCErb]

@raythurnevoid What's the status on this? I'm new to svelte and have been really enjoying this library but noticing some cobwebs forming. Your fork looks interesting and so does smelte: https://github.com/matyunya/smelte.

I'm having trouble getting a read on what the pros and cons are and what "the community" is leaning towards/away from or why.

[raythurnevoid]

@raythurnevoid What's the status on this? I'm new to svelte and have been really enjoying this library but noticing some cobwebs forming. Your fork looks interesting and so does smelte: https://github.com/matyunya/smelte.

I'm having trouble getting a read on what the pros and cons are and what "the community" is leaning towards/away from or why.

Hi, i'm working on it everyday, i moved on from the repository linked above.
You check my actual progress here: https://github.com/svelte-material-ui-test
"core" is the library itself while "website" is what you find under sveltematerialui.com today.

From the moment the first beta will be release, a lot of work must be done before an actual release. There are some topics i want to give a great relevance to: Theming (and so integration with google mixins via svelte), intuitive API, Performance.

At the current state of work i finalized the main API of 19/30 components, and implemented a rough configurator for each of them.
After all components as been rewritten i'll need to find a good way to handle events and i'll have to do some optimization to enhance overall performance, then i'll be able to publish the first beta.

This is a preview:

I hope to being able to keep this roadmap:

• Finalize API and website components configurators
• Find a good way to handle events
• Performance improvements
• First beta release (hope by the end of the year)
• Theming support
• Website enhancements and docs update
• First stable release (Probably March/April)

[KCErb]

Awesome, thanks for updating this thread with a link to the new repo and glad to hear you're working on it every day. I hope to be getting some miles into Svelte again with MUI, if that goes well I'll have the motive and means to contribute too!

I guess looking at Smelte the important difference between the two which may lead to separate efforts staying separate in the long run is whether to start from google's components or scratch. If I understand correctly, your design goal is to work from what google provides and smelte's goal is to implement the spec from scratch (with tailwind). Is that a fair summary?

[raythurnevoid]

Awesome, thanks for updating this thread with a link to the new repo and glad to hear you're working on it every day. I hope to be getting some miles into Svelte again with MUI, if that goes well I'll have the motive and means to contribute too!

I guess looking at Smelte the important difference between the two which may lead to separate efforts staying separate in the long run is whether to start from google's components or scratch. If I understand correctly, your design goal is to work from what google provides and smelte's goal is to implement the spec from scratch (with tailwind). Is that a fair summary?

I don't think this is what really matters at the end, since whatever is the implementation the goal should be to provide a library that people actually like to use. I personally think that starting from google's components makes easier to keeping update to material specs updates.
I think the main difference between the two are the way API are served. Some smelte components need you to input big chunk of json as props, while i prefer keep props as primitive types and in the other hand give you different components tags to compose.
Eg:
smelte

smui

[KCErb]

Wow, thanks for illustrating. That is much clearer now.

[raythurnevoid]

Hi, for everyone who was waiting this issue to be completed, i'm closing this.
@hperrin is working on his own version 2 for his library but i'll continue working on a Typescript version here: https://github.com/svelte-material-design

[marekdedic]

Hi,
thanks for the work of everyone involved! Is there no way to get these two projects merged? I had the feeling that that was the original idea...

Looking at the current v2 changelog of this repo, it seems like a much more modest change. However, I'd guess that a lot of people are looking forward to TS support mainly out of a future version.

Also, can't not link https://xkcd.com/927/ :D

[Florian-Schoenherr]

@marekdedic about the link: let the best standard win. If the maintainer doesn't maintain, well.

[hperrin]

@marekdedic I've looked over @raythurnevoid's code, and it looks like the two libraries have diverged a considerable amount, so merging them would be extremely difficult.

My latest version, v3, is focused on migrating to the "Advanced Approach" of integrating MDC-Web (the upstream Google library), which puts Svelte completely in charge of maintaining the state of the DOM. This simplifies the code quite a bit and likely resolves a number of unknown edge-case bugs. It also makes it easier to upgrade to future versions of MDC-Web and add additional features on top of MDC-Web's feature set. I also upgraded to the latest version of MDC-Web, v10. Since those were the goals for this version, migrating to Typescript has been pushed to the next version, v4.

That being said, migrating to Typescript will be the main focus of the next version.

[hperrin]

Also, regarding @raythurnevoid's original post:

• Standard textfields aren't a deprecated component from MDC-Web, they are an additional variant that SMUI provides.
• I'm not sure what you mean by "use$* and on$* props". The "$" props in SMUI are for adding props to lower level elements within a component. Event bindings use Svelte's "on:" syntax and always have. Actions are provided through a "use" prop (no "$").

[hperrin]

@userquin, Btw, as of the latest SMUI beta, (3.0.0-beta.8), you can now bind to events passively. In fact, you can use every modifier from Svelte (except for self). And you can bind to any event. And it will only add an event listener if you bind to it.

[hperrin]

SMUI v5 now supports TypeScript. :)