Expose icons dictionary

[1602]

Addresses #12

[1602]

@lzrski thanks for validating this API. It is a valid concern you are raising regarding dead code elimination. Indeed in elm 0.19 it should not be a problem, only icons used will remain in production code.

Unfortunately this new API we are about to add will not be able to take advantage of this feature of elm 0.19, because usage of icons is a usage of all the icons, compiler wouldn't be able to know which subset of icons is needed.

I did not plan to update https://1602.github.io/elm-feather-icons/, because it currently serves another purposes:

• to use very new feathericons before I catch up with elm library after master package released
• to use same api for customised or new icons (which are not part of feather icons), as a test drive for example

So, given that dead code elimination will not work with "icons" api it might be a good idea to add this option to https://1602.github.io/elm-feather-icons/ to generate a subset of icons as dictionary. I will create a separate issue about that.

[1602]

Published feathericons/elm-feather@1.2.0

[tad-lispy]

Good point about importing the icons dictionary "breaking" the dead code elimination.

Perhaps you could leave it to the end-user though. If the consumer cares about the bundle size, she can simply create her own dictionary using the functions that were already there, like this:

module IconsDict exposing (main)

import Dict
import FeatherIcons
import Html exposing (..)
import Html.Attributes exposing (..)

icons =
    Dict.empty
        |> Dict.insert "arrow-up" FeatherIcons.arrowUp

main : Html msg
main =
    icons
        |> Dict.get "arrow-up"
        |> Maybe.map (FeatherIcons.withSize 64)
        |> Maybe.map (FeatherIcons.toHtml [ style "color" "pink" ])
        |> Maybe.withDefault (text "Icon not found")

That way I believe the dead code elimination will still kick in and only one icon will get imported. Using FeatherIcons.icons will remain an option when consumer needs all the icons or simply doesn't care about the bundle size.

Of course the other two use cases you mentioned remain valid.