WIP: elm-ui-widgets 2.0

Request Feedback
1

Hello everyone. Over the easter holidays I started rewriting my package. Here’s the last post about it:

This post will be a quick explanation of the ideas I had so far and where I want to go. This package is starting to get too much to handle on my own. If someone wants to help, I would love to collaborate. (@aforemny are you still interested?)

Goal

The long time goal is to have a universal tool for creating UI-frameworks natively in Elm, in particular a native Material Design implementation. It should allow easy customizability and also extendability of existing widgets.

Example: Button

A good example, how I image the package to work is the button:

button: ButtonStyle msg
    ->
        { text : String
        , icon : Element Never
        , onPress : Maybe msg
        }
    -> Element msg

In comparison to Elm-Ui’s button, we see two new things:

  • List (Attribute msg) has changed into
    type alias ButtonStyle msg =
    { container : List (Attribute msg)
    , labelRow : List (Attribute msg)
    , ifDisabled : List (Attribute msg)
    , ifActive : List (Attribute msg)
    }
  • We can display an icon, besides the text. Just like the Material Design specification describes it.
    Actually there is also a type for the button:
    type alias Button msg =
    { text : String
    , icon : Element Never
    , onPress : Maybe msg
    }

There are also a few different implementations of the button, like the Icon without text:

iconButton :
    ButtonStyle msg
    ->
        { text : String --for screen readers
        , icon : Element Never
        , onPress : Maybe msg
        }
    -> Element msg

or a Button with no icon

textButton :
    ButtonStyle msg
    ->
        { textButton
            | text : String
            , onPress : Maybe msg
        }
    -> Element msg

Concept

Here are the reasons why I implemented it that way:

  • The core of Elm-Ui-Widgets are independend widgets (no components), that can be used without knowing anything else about the package.
  • Each widget comes with a Widget Type and a Style Type. The Widget Type is an abstract representation of the widget and the Style Type has all styling attributes.
  • Style Types should be definable without knowing implementation details
  • Widget Types can be use for a Master View Type (Elm-Ui-Widgets might provide some master view types, for example for elm-Markup support)
  • Widget Types can be used as building Blocks for more complicated Widgets
    (Button → Select Buttons → Menu → Layout)

You can check out the current demo here. The source code can be found in the unstable branch of the github repos.

Contribution

My next goal is to release 2.0 which contains the following:

  • A preselected list of Widgets (see the current roadmap), following the Material design specifications.
  • A implementation of Material Design as Style-Types
  • A website that has nice example code (I’m thinking of having isolated Elm-Apps and using Elm-Spa to stitch them together. Once the package is released, we can turn the isolated Elm-Apps into Ellies)

I need help with all of them.

Discussion

Should I do something differently? Am I missing something? Or do you have any feature request? Feedback would be great.

8 Likes
2

I’m not sure I’ll be able to contribute much myself, but I really love the idea of having a nice set of widgets for elm-ui to make it easy to put together a decent-looking app quickly. Something like that would be really helpful in introducing Elm at my company, since we tend to make a lot of internal tools where it’s more important to be able to build something decent-looking quickly than being able to fully customize every single aspect of the UI. Building a set of elm-ui widgets seems like a great approach since it should make it pretty easy to put something together quickly but also be able to easily add in custom widgets where necessary.

2 Likes
3

This is fantastic! I was just toying with a UI pass on a project and decided to check Elm Discourse for any recent UI work the community’s been up to. The stateless Collapseable view was something I’d wanted to make but ruled out ten minutes ago as too complex for tonight! Thanks for sharing!

4

I have a similar case to @ianmackenzie, in my current job most of the projects doesn’t care much about having a unique design, but to be developed fast, so pure elm-ui would not be the best option. I am glad someone is exploring widgets, this is definitively a path that must be explored!

1 Like
5

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.