ui: Use structure-icons as much as possible

[johncowen]

This PR removes as many as our old icons as possible, in favour of structure-icons, and is partly as a result of working too far on icons during #6639.

Preview Link

Once both #6639 and this PR is merged down, we should be 100% using our base CSS - which is almost 100% structure-icons. For outstanding icons that we have in base but not in structure-icons we'll work to get them integrated.

Following merge of this and #6639 we should be able to get rid of our project components/icons/index.scss file 🎉

P.S. This makes use of CSS mask-image which has no IE11 support. There is no polyfill included here.

[hannahhearth]

I noticed the inputs on multiple pages are janky now:

And the alignment of a few icons in titles and subtitles is inconsistent in its vertical alignment.

[johncowen]

Hey @opihana !

Ok I rebased #6843 onto here which was the fix for the first 2 screengrabs.

The other two screengrabs were not changed at all in this PR and have been like that for a while:

• External Service Icons.
  I remember originally wondering how this should be lined up, eventually I went with the bottom on the baseline as this also happens to line the top of the icon up with the top of a lowercase letter and lines up 'ok' with the proxy label:

I can't find these icons in the Sketch designs anymore, but maybe we should get those back in there (or could you point me to them if they are somewhere I've not seen) and I can follow whatever you do there. We should definitely decide how this entire line should be vertically positioned (P.S. I found an old design with these in, but the design doesn't have the proxy label in which is why I think this troublesome when I first did it)

• Info icons. I think I might have changed these a while ago (so not in this PR), and the (i) in that screengrab does actually look bigger than it should be. But it has always been in a 'superscript' position.

Actually looking at it more closely, there seems to be a Chrome bug in play here. If you resize the browser window the (i) icon occasionally jumps to be a pixel or so larger than it should be even though no CSS changes. I checked in FF and Safari but it doesn't happen there. Looks to be a little browser bug, but I'd probably look at that in a separate PR if at all.

[codecov]

Codecov Report

Merging #6851 into ui-staging will decrease coverage by 0.02%.
The diff coverage is n/a.

@@              Coverage Diff               @@
##           ui-staging    #6851      +/-   ##
==============================================
- Coverage       65.64%   65.61%   -0.03%     
==============================================
  Files             443      443              
  Lines           53312    53312              
==============================================
- Hits            34994    34981      -13     
- Misses          14095    14100       +5     
- Partials         4223     4231       +8

Impacted Files	Coverage Δ
command/catalog/list/nodes/catalog_list_nodes.go	80.34% <0%> (-3.42%)	⬇️
agent/cache/watch.go	78.75% <0%> (-2.5%)	⬇️
agent/consul/replication.go	85.71% <0%> (-2.39%)	⬇️
api/watch/funcs.go	74.61% <0%> (-2.08%)	⬇️
agent/consul/config_replication.go	75.51% <0%> (-2.05%)	⬇️
agent/kvs_endpoint.go	75.44% <0%> (-1.2%)	⬇️
agent/testagent.go	72.83% <0%> (-1.14%)	⬇️
agent/consul/leader_connect.go	70.15% <0%> (-0.88%)	⬇️
agent/service_manager.go	82.47% <0%> (-0.86%)	⬇️
command/debug/debug.go	66.56% <0%> (-0.6%)	⬇️
... and 11 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update aa680d5...77984c5. Read the comment docs.

[johncowen]

This is currently on hold pending a rebase of ui-staging and then re-checking.

[johncowen]

This has been rebased and is ready again for review. We also added one last commit (now that we have rebased from other feature work) to remove the remaining CSS in our app level icons/index file. 100% of our icons are now provided by base. The only thing that is icon related is our %external-source-icon helper, which we've moved to %app-view for the moment pending a rename.

base still contains some extra svg icons that are either using our old way of colorizing icons (just duplicating the svg and hardcoding the color), or icons that don't yet exist in @hashicorp/structure-icons. We'll be working to move all our old style icon coloring to move everything to use masking in a future PR and also working to try to get icons that don't exist in @hashicorp/structure-icons integrated into that module.

[hannahhearth]

@johncowen Does the preview link in the original comment stay valid? If so, I noticed that there are a few issues:

There's no content on the Settings page

And the intentions were doing this weird swapping of the name when I click on it. Watch carefully!

[johncowen]

There's no content on the Settings page

Rebased #6965

And the intentions were doing this weird swapping of the name when I click on it. Watch carefully!

This is a mix of our mocks and ember:

1. Are mocks are partly random and there is no state. So when you click on an intention with the id of 05b1c5f2-4729-5647-122d-7042372ca72f on the intention listing, when you arrive on the edit page you'll notice that the values to edit are different. This is because the mocks are stateless and everything is generated 'randomly but consistent' (using a salt).
2. Despite point 1. Ideally you still shouldn't see this little flicker as ember/ember-data/the framework should teardown the listing view before it loads any data for the next view, therefore you wouldn't see the little flicker/change when you click the item. What causes the flicker is that the different values for the intention that you clicked on are loaded in before it gets chance to teardown the list view and setup the edit view. This is something I've seen before in other ember apps.

As point 1 is unlikely to happen in production you are unlikely to see this in reality (there is a chance that the intention could be edited by other means before you've clicked on it, therefore you would see this, but if this does happen this problem is has been in the UI since the start and I'd guess we are unlikely to look into it - one suggestion would be that we use something other than ember-data to see if that resolves the issue. I'm not sure if this exact thing is inherent with ember or ember-data.

P.S. Yeah the preview link does stay valid! 😄

All in all this PR only has CSS changes (and one tiny HTML change) just to replace icons, so anything javascript-y like this won't have been added via this PR.

[johncowen]

@opihana are you ok to re-review this, or would you rather I add someone else to review this?

[kaxcode]

One suggestion, but not a required action. 😸

[kaxcode]

I can't find %with-exit-icon. Is it stored in app/styles/base/icons files?

[kaxcode]

Found. Please disregard.

[johncowen]

You make a good point here though. If we imported base/icons here it would provide a clue for where the %with-exit-icon is coming from, even though its not required (we import it higher up at a more global level). I've tried to do that in other areas but as I'm not 100% on whether we are ok relying on global imports I've not been entirely consistent. Definitely something we can look at and both decide upon though 👍

[kaxcode]

Should we extend the with-external-source-icon that already exists and leave the TODO? I suggest this since there's no change between this one and the one that already exists, for now.

[johncowen]

If I follow what you are saying here, that would be a great idea for if there were other places that we don't own that were using these CSS files:

%app-view-brand-icon {
  @extend %with-external-source-icon;
}

then both placeholders would do the same thing, and we could gradually deprecate the old one.

As we own the entire source here it probably just as good to search/replace the instances where we use %external-source-icon with the new name, might be something you could PR if you fancied it?

All that ^ is if I've understood correctly - we can go over it later.