Orasund/elm-ui-widgets
1
1
Fork 0
mirror of https://github.com/Orasund/elm-ui-widgets.git synced 2024-11-22 22:33:33 +03:00
Code Issues Projects Releases Wiki Activity

Updated Readme

Browse Source
This commit is contained in:
Unknown 2020-03-26 13:53:23 +01:00
parent 3b6f8998c3
commit ec8005aed8
1 changed files with 15 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

21
README.md
View File

@ -15,12 +15,21 @@ These include:
* Validated Input * Validated Input
* Scrolling Nav * Scrolling Nav
Check out the [examples](https://orasund.github.io/elm-ui-widgets/) Examples of all widgets can be found [here](https://orasund.github.io/elm-ui-widgets/). For styling, I used my own [Orasund/elm-ui-framework](https://package.elm-lang.org/packages/Orasund/elm-ui-framework/latest/).
## Why was this package created ## Why create such a package?
There are two reasons I created this package. After looking at the current packages that implement various reusable views (and components) I noticed two things:
1. There are no reusable views written from Elm-Ui * There are (nearly) no widgets for Elm-Ui, and that's a problem because while going from `Element` to `Html` is easy, the opposite is not always possible (as a lot of styling in Elm-Ui would not be adapted to the `Html` element.)
2. There are a lot of reusable views out there, all trying to reinvent the wheel, * There is collection of widgets, all in one place. A lot of components get reimplemented over and over again. It's hard to keep track of what package is currently the best.
and all do it differently. This packages tries to keep the complexity at a minimum and all the widgets consistent with eachother.
This package tries to solve both of these problems.
## Why does this package also include components?
I wrote a component whenever the boilerplate of a similar reusable view is less than just include the wiring in the package.
## Where will it go from here
I really would like to write a native material-design implementation in Elm. But after doing this package as a first step, (Which I already wrote while having the material.io docs as reference) I am not quite sure how I can avoid a lot of boilerplating. It seems like a [Master View Type](https://www.freecodecamp.org/news/scaling-elm-views-with-master-view-types/) would be the solution, but I'm not quite sure how I can ensure the customizability when my entire page can be described as a single type. (I don't want to know how many parameters such a type would need).