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.
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.
It's perhaps debateable if all these modules belong there, but it makes
sense as a first step, to avoid conflicts once we start importing this
from the monolith.
This doesn't include the entire spec for the new outline styling, just
the part we currently need for content creation outline draggable
creation. The additions to complete the spec look doable in the current
structure though.
Version 5.0.1 which has just been published widens the acceptable
versions of elm-css to 13, which Elm then promptly wants to pull in.
The problem is we're not compatible with that version.
