From ec8005aed809b9c633afadf17c585168782cbd01 Mon Sep 17 00:00:00 2001 From: Unknown Date: Thu, 26 Mar 2020 13:53:23 +0100 Subject: [PATCH] Updated Readme --- README.md | 21 +++++++++++++++------ 1 file changed, 15 insertions(+), 6 deletions(-) diff --git a/README.md b/README.md index 97cf6fe..fcdff6f 100644 --- a/README.md +++ b/README.md @@ -15,12 +15,21 @@ These include: * Validated Input * 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 -2. There are a lot of reusable views out there, all trying to reinvent the wheel, - and all do it differently. This packages tries to keep the complexity at a minimum and all the widgets consistent with eachother. \ No newline at end of file +* 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.) +* 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. + +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). \ No newline at end of file