Update icons to use blade components, standardize button colors and format

[snipe]

This looks a lot scarier than it is, with all the files it touches. It simply switches to using an icon blade component where we can, so that we can always be sure that the icon is correct, and has the appropriate attributes (aria-hidden, for example).

This will improve our accessibility as well, since in working on this I found a bunch of icons that didn't have the aria-hidden attribute, and it will (hopefully) mean less hunting down icons that we use consistently throughout the system.

As I was poking around in some of the transformers, I also got rid of a stupid way we were handling titles on some of the older ones. I must have missed those when I came up with the better way (using the custom css-blah class.)

Note: There are a few places we cannot use the icon blade components yet. I'm working on those, but some may be unsurmountable - specifically the error messages we include under each form field. It's not really a big deal IMHO, since they always use the same icon, but I bet I can probably work on that too. It breaks because we use {!! !!} for our error messages so that we can use the <span class="alert-msg" to apply the red error color to the error message, but that means the component doesn't get parsed properly. Something I can work around in a different PR I think.

Icons that are only used once were not included in the icon helper.

This PR also standardizes the order and color of the main action buttons (edit, checkout, checkin, etc) across all first-class views.

[what-the-diff]

PR Summary

• Introduction of Icon Helper
  A new utility file, IconHelper.php, was added to our project. This helpful tool generates different icons based on the input it is given.

• Icon Alias Addition
  To facilitate easier use, an alias for the IconHelper was added in the configuration file named config/app.php.

• UI Enhancements Across Views
  Several interface elements across different views were upgraded by replacing conventional icons (denoted <i> tag in HTML) with our custom IconHelper. This allows for better control, flexibility, and maintainability in managing iconography throughout the project.

• Updated UI Components with Icon Helper
  Existing UI components were updated to take advantage of the new IconHelper. The IconHelper was used to replace many instances of icons scattered throughout the project. The change provides more control over the icons without having to edit every individual instance.

• New File Addition to Handle Icons
  A new file, icon.blade.php was introduced to manage the displaying of icons in a more effective and efficient manner.

• Tooltips Addition
  Tooltips with the appropriate icon types were added across several files enhancing the overall user experience.

• Conversion of Icons to Icon Component in Multiple Files
  Many instances of the icon tags <i> were converted to use the new <x-icon> component across multiple files. This change improved consistency and maintainability of the icons.

• Internationalization Enhancement for the Download Button
  The download button now uses an internationalization function trans for label translation which makes the app more accessible to multiple regions/languages.

• Updated Save Button Labels
  The save button labels in various settings files were updated, again using the trans function to translate the labels. Additionally, icon components were added to these buttons improving the aesthetic.

• Replacement of User Icons
  In certain places, the conventional user icon was replaced with the new <x-icon> component providing a uniform and improved look.

[uberbrady]

I think, since the only place the 'Icon helper' is used is right here, that you might be able to directly paste it in above this <i> tag, in a @php block.

Then the thing that spits out the icons is right next to the place we use the icons, right? And you can get rid of some other extra little bits here and there.

[snipe]

There are some other places where we're not directly generating an icon itself though (some transformers, etc) so it seemed better to keep that logic out of the blade component.

[uberbrady]

In fact, you can just make it into a simple PHP array if it makes sense - something like:

$iconmap = [
    /* ..... */
    'caret-down' => 'fa fa-caret-down',
    /* ..... */
];

[snipe]

Again, I didn't want that logic in the blade, since there are other places where it could be useful, specifically when we're trying to determine which icon to use in transformers, even though we're not actually using that icon in those methods, we're passing it elsewhere (sometimes because it's in javascript, etc)

[marcusmoore]

fwiw, I'm for avoiding a giant @php block in the component too.

[marcusmoore]

"blade components" in the title caught my eye. I'm going to add myself as a reviewer to see if I have any other input 😄

[snipe]

@marcusmoore ticktock ticktock :P

[marcusmoore]

There is some slight spacing issues...gonna try to track it down.

[marcusmoore]

fwiw, I'm for avoiding a giant @php block in the component too.

[marcusmoore]

Another note: I think we should avoid using isset in components since that should be handled by @props. If something is in @props without a default value then the component will throw an exception when trying to render and if it does have a value then we don't need to use isset (we could add a conditional around the value if needed of course).

In this case we should be able to remove class from the props list since {{ $attributes->class(...) }} should handle that.

[snipe]

I tried that, but it still threw an error that the variable was not set.

[marcusmoore]

Looks like fa-fw is missing on some of the icons on the left nav bar and also on the ones along the top. Here's a gif of the differences between develop and this branch: