This change allows SegmentedControl to no longer needs to take a record
with all icon assets. It's the construction of the `IconType` that now
requires an asset, which one depends on the icon being constructed.
The purpose of this change is to allow each icon to list its asset
dependencies separately. This allows services consuming the icon library
to only provide those icons that are actually used.
Not sure what this .gitignore entry was for though. Happy to change this
commit for a narrower .gitignore rule that whitelists our Icon modules
but keeps ignoring whatever files it was ignoring before.
This version is like `Nri.Ui.SegmentedControl.V1` with the icon changes.
It has the fix for `box-sizing`.
All the other caveats from `Nri.Ui.SegmentedControl.V1`
(if there were any) apply here as well.
The recommendation is to break the styles API rather than the view API
when moving something out of the monolith into this repo.
`Nri.Icon` is not really setup for that sort of breakage.
If we would prefer to have the styles break rather than the view,
that will take more work.
Work that can be done independent of the extraction.
The transition in the monolith ought to look something like:
```elm
module Nri.Icon exposing (..)
import Html exposing (Html)
import Nri.SvgSprite
import Nri.Ui.Icon.V1 exposing (Assets, IconType)
icon : { alt : String, icon : IconType } -> Html msg
icon config =
Nri.Ui.Icon.V1.icon assets
assets : Assets {}
assets =
{ activity = Nri.SvgSprite.activity
, arrowDown = Nri.SvgSprite.arrowDown
, attention_svg = Nri.Assets.attention_svg
...
}
```
So hopefully, the change is still very small on the monolith side.
There's maybe a bigger concern than which API breaks.
`Nri.Icon` has some behavior for a11y.
We could definitely change the internals over during the extraction.
But, since all of these changes are value-level changes,
it's very likely that we'll break something in the process.
That's a bigger concern because instead of affecting
the handful of Engineers working at NRI,
we would be affecting the millions of people using the site.
We shouldn't fear making those kinds of changes.
However, we should make them when we can give them the appropriate
attention they deserve.
Not when one person is trying to move as fast as possible to avoid
race conditions of moving modules between repos.
Travis can't determine what node_modules will be if it doesn't exist
yet, so it fails and has to retry. No need for that, so we'll just put
it where we know it will be.
