julianjelfs / ef-gud-elm

EF GUD Elm Components

This is a representation of the EF design system implemented using Elm 0.19.

It also includes a set of "Stories" a la Storybook to explain and demonstrate example usage (probably this should be split into two projects in the end).

The project is bootstrapped using Create Elm App.

To gets things up and running locally you will need to clone the repo and make sure that you have create-elm-app installed globally:

npm install -g create-elm-app

To run a local development server run:

elm-app start

This will launch the app on http://localhost:3000 with hot reloading enabled.

To create a release build run:

elm-app build

Design Principles

These components try to offer a very thin wrapper around straight html. The intention is to make use of the GUD css as-is in order to stay in line with future updates more easily and to reduce the complexity of the implementation.

Furthermore the dsl used is designed to mirror the dsl for standard html creation within Elm. This means that in general we use the same form: a function with the name of the component we are creating which accepts a list of properties and then a list of child components (where appropriate). We add value by adding a layer of type safety to ensure that only valid properties can be added to each component and by adding types to constrain simple values within the ranges dictated by the GUD.

There are pros and cons to this approach. On the plus side it results in a very familiar pattern of usage which is very similar to the generation of standard html in Elm. On the downside it is not as type safe as it could possibly be since the properties are represented as a list rather than an algebraic type (which would allow us to exclude all invalid combinations. This seemed like a good compromise as the ADT approach does make the library less convenient to use.

Contribution

With the design considerations given above, contributions are welcome via PR. If you add a component, please also add a story and wire it up in the Main.elm module. For a roadmap of what needs doing, have a look at http://code.ef.design. If you want to add something that is not part of the GUD or you feel like it makes sense to deviate from the design principles adopted so far then it's probably worth a discussion before you begin.

ef-gud-elm's Issues

Add a radio group component

Create footer component

Add more useful validator categories to the forms

min length
between (combines max and min)
etc

Add a range slider component

Create breadcrumb component

Create a card component

Add valid states to form as well as invalid

Create pagination component

Add custom validation error messages to the form

Create header component

Add switch component

Create full bleed component

Add spacing support to main layout components

The spacing module provides helper functions for most aspects of padding and margin. For each component that wants to provide padding and margin these features need to be wrapped with the relevant component's props wrapper. This is a bit of a pain. There could be a better way, but this is possibly just Elm's curse. It is not the best when it comes to abstraction. The end result will be nice for the user though.

Create accordion component

Further exploration of phantom types

Seems like it might be an idea to implement all possible props for all components inside a single module and type them all using a phantom type. Then have each component expose just the properties they support tagged with an opaque type representing themselves.

e.g.

type ComponentProp a msg = ComponentProp (Attribute msg)

disabled : ComponentProp Radio msg
disabled = Component.disabled

Need to be sure that we can handle the differing structure of each component before we embark on this, although even if it doesn't work for all components it might be good for those that share a lot (input, text area, select, checkbox, radio etc)

Validation of fieldsets

form, fieldset and formgroup are all groups of fields and I think the the validation can probably treat them the same. This needs to be harmonised so that the validity of each one is just the validity of all of the controls that they contain.

We may benefit from some sort of FieldContainer abstraction that can handle this for all three things.

Make sure that the forms work correctly with other kinds of input apart from text

This might involve making the validators polymorphic rather than String-y which is probably a good thing.

Create carousel component

Create table component

Investigate a better way to store fields internally in the form

storing fields in a list means we have to do a lot of list iteration which sucks. It would be better to store them on a dictionary but that can't obviously be done because they are keyed on branches of a sum type. Are there packages that can help with this?

Repeating form groups

This might be a bit tricky