Closed heathwinning closed 4 years ago
I wanted to ask the same question for a few weeks now ;) Thanks for taking the initiative!
@heathwinning (CC: @oxc )Thank you for your question!
I think it's more appropriate to implement it as a library in another repository along with the original. This repository is basically focused on handling @material-ui/core features in Kotlin/JS.
I think I'll get some time in the first week of May, so I'll try to build a repository of Material-UI Pickers for Kotlin/JS 😎
Correct me if I'm wrong, but I think a lot of the builders/utility classes from this project would be reusable for the pickers (since they are based on @material-ui/core as well), but are internal to this module.
@oxc The most important MaterialElementBuilder class is defined as a public class, so a separate repository shouldn't be a fatal problem.
However, I thought about it a bit, and it seems to be easier to maintain if it's defined as a separate module in the same repo, given the commonality of build scripts.
A second time module also makes sense to me.
As for implementation; I'm not sure how essential the wrapper MuiPickersUtilsProvider is, but the support for different date providers seems to pose some complexity.
As far as I understood, it's quite essential. But it should not cause any problems, I don't think we need externals for any of the date libraries, so the user can basically just pick the one they are using and have specified in their dependencies.
I'd like to use material pickers. I've had a little look under the hood of kotlin-material-ui and it looks set up to handle the pickers. Does this fit within the scope of this library?