luxolus
/
open-consul
2
0
Fork 0
Code Issues 1 Pull Requests Packages Releases Wiki Activity
open-consul/ui/packages/consul-ui/app/templates/dc/services/instance/metadata.hbs

31 lines
683 B
Handlebars
Raw Normal View History

ui: Accessibility scan improvements (#9485) * ui: Remove all vestiges of role=tabpanel * Switch out tablist role for a label, default to Secondary * Move healthcheckout-output headers to h2, ideally these would be outside the component * Add aria-label for empty button * Fix up non-unique ids in topology component * Temporarily fixup h2 in KV > LockSession * Fixup dl with no dt * h3 > h2 * Fix up page objects that were reliant on ids
2021-01-05 10:05:59 +00:00
<div class="tab-section">
ui: Create Tags & Meta tab (#7954)
2020-05-26 15:52:32 +00:00
<section class="tags">
ui: Re-organize our %h* placeholders (#9584) We've always had this idea of being able to markup up information semantically without thinking about what it should look like, then applying our %h* placeholder styles to control what the information should look like. Back when we originally made our set of %h* placeholders, we tried to follow Structure as much as possible, which defined the largest header (which we thought would have been the h1 style) as a super large 3.5rem. Therefore we made our set of %h* placeholders the same as Structure beginning at a huge 3.5 size. We then re-overwrote those sizes only in Consul specific CSS files thinking that this was due to us existing before Structure did. Lately we saw an extra clue in Structure - the extra large 3.5 header was called 'h0'. This commit moves all our headers to use a zero based scale, and additionally uses our 3 digit scale as opposed to 1 digit (h1 vs h100), similar to our color scales (note we don't use a hypen, which we can alter later if need be), which means we can insert additional h150 etc if need be. Additional we stop styling our headers globally (h1 { @extend %h100; } ). This means there is no reason not to use headers for marking up content depending on what it is rather than what it should look like, and as a consequence means we can be more purposeful in ordering h* tags. Lastly, we use the new scale over the entire codebase and update a couple of places where we were using using header tags due to what the styleing for them looked like rather than what the meaning/order was.
2021-01-26 17:53:45 +00:00
<h2>Tags</h2>
ui: Create Tags & Meta tab (#7954)
2020-05-26 15:52:32 +00:00
{{#if (gt item.Tags.length 0) }}
<TagList @item={{item}} />
{{else}}
ui: Use empty-state for our small empty states (#8262)
2020-07-08 13:34:57 +00:00
<EmptyState>
<BlockSlot @name="body">
<p>
There are no tags.
</p>
</BlockSlot>
</EmptyState>
ui: Create Tags & Meta tab (#7954)
2020-05-26 15:52:32 +00:00
{{/if}}
</section>
<section class="metadata">
ui: Re-organize our %h* placeholders (#9584) We've always had this idea of being able to markup up information semantically without thinking about what it should look like, then applying our %h* placeholder styles to control what the information should look like. Back when we originally made our set of %h* placeholders, we tried to follow Structure as much as possible, which defined the largest header (which we thought would have been the h1 style) as a super large 3.5rem. Therefore we made our set of %h* placeholders the same as Structure beginning at a huge 3.5 size. We then re-overwrote those sizes only in Consul specific CSS files thinking that this was due to us existing before Structure did. Lately we saw an extra clue in Structure - the extra large 3.5 header was called 'h0'. This commit moves all our headers to use a zero based scale, and additionally uses our 3 digit scale as opposed to 1 digit (h1 vs h100), similar to our color scales (note we don't use a hypen, which we can alter later if need be), which means we can insert additional h150 etc if need be. Additional we stop styling our headers globally (h1 { @extend %h100; } ). This means there is no reason not to use headers for marking up content depending on what it is rather than what it should look like, and as a consequence means we can be more purposeful in ordering h* tags. Lastly, we use the new scale over the entire codebase and update a couple of places where we were using using header tags due to what the styleing for them looked like rather than what the meaning/order was.
2021-01-26 17:53:45 +00:00
<h2>Meta</h2>
ui: Create Tags & Meta tab (#7954)
2020-05-26 15:52:32 +00:00
{{#if item.Meta}}
ui: Remove unused helpers or swap for helpers in ember-string-fns (#9294) * ui: Remove unused helpers or swap for helpers in ember-string-fns * starts-with > string-starts-with
2020-11-30 17:19:44 +00:00
<Consul::Metadata::List @items={{entries item.Meta}} />
ui: Create Tags & Meta tab (#7954)
2020-05-26 15:52:32 +00:00
{{else}}
ui: Use empty-state for our small empty states (#8262)
2020-07-08 13:34:57 +00:00
<EmptyState>
<BlockSlot @name="body">
<p>
This instance has no metadata.
</p>
</BlockSlot>
</EmptyState>
ui: Create Tags & Meta tab (#7954)
2020-05-26 15:52:32 +00:00
{{/if}}
</section>
ui: Add tab navigation to the browser history/URLs (#7592) * ui: Add tab navigation to the browser history/URLs This commit changes all our tabbed UI interfaces in the catalog to use actual URL changes rather than only updating the content in the page using CSS. Originally we had decided not to add tab clicks into the browser history for a variety of reasons. As the UI has progressed these tabs are a fairly common pattern we are using and as the UI grows and stabilizes around certain UX patterns we've decided to make these tabs 'URL changing'. Pros: - Deeplinking - Potentially smaller Route files with a more concentrated scope of the contents of a tab rather than the entire page. - Tab clicks now go into your history meaning backwards and forwards buttons take you through the tabs not just the pages. - The majority of our partials are now fully fledged templates (Octane :tada:) Cons: - Tab clicks now go into your history meaning backwards and forwards buttons take you through the tabs not just the pages. (Could be good and bad from a UX perspective) - Many more Route and Controller files (yet as mentioned above each of these have a more reduced scope) - Moving around the contents of these tabs, or changing the visual names of them means updates to the URL structure, which then should potentially entail redirects, therefore what things that seem like straightforwards design reorganizations are now a little more impactful. It was getting to the point that the Pros outweight the Cons Apart from moving some files around we made a few more tiny tweaks to get this all working: - Our freetext-filter component now performs the initial search rather than this happening in the Controller (remove of the search method in the Controllers and the new didInsertElement hook in the component) - All of the <TabNav>'s were changed to use its alternative href approach. - <TabPanel>s usage was mostly removed. This is th thing I dislike the most. I think this needs removing, but I'd also like to remove the HTML it creates. You'll see that every new page is wrappe din the HTML for the old <TabPanel>, this is to continue to use the same HTML structure and id's as before to avoid making further changes to any CSS that might use this and being able to target things during testing. We could have also removed these here, but it would have meant a much larger changeset and can just as easily be done at a later date. - We made a new `tabgroup` page-object component, which is almost identical to the previous `radiogroup` one and injected that instead where needed during testing. * Make sure we pick up indexed routes when nspaces are enabled * Move session invalidation to the child (session) route * Revert back to not using didInsertElement for updating the searching This adds a way for the searchable to remember the last search result instead, which changes less and stick to the previous method of searching.
2020-04-08 09:56:36 +00:00
</div>