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/nodes/show/services.hbs

71 lines
1.9 KiB
Handlebars
Raw Normal View History

ui: Search/filtering 'Filtered by:' search status (#9442) Adds a 'status' for the filtering/searching in the UI, without this its not super clear that you are filtering a recordset due to the menu selections being hidden once closed. You can also use the pills in this status view to delete individual filters.
2021-01-25 18:13:54 +00:00
{{#let
(hash
value=(or sortBy "Status:asc")
change=(action (mut sortBy) value="target.selected")
)
(hash
status=(hash
value=(if status (split status ',') undefined)
change=(action (mut status) value="target.selectedItems")
)
source=(hash
value=(if source (split source ',') undefined)
change=(action (mut source) value="target.selectedItems")
)
searchproperty=(hash
value=(if (not-eq searchproperty undefined)
(split searchproperty ',')
searchProperties
)
change=(action (mut searchproperty) value="target.selectedItems")
default=searchProperties
)
ui: New search/sort/filtering bar for Node > ServiceInstances (#9326) * Model layer changes to turn Node:ServiceInstances into hasMany We tried to make something that feels a little like ember-data yet not leave our approach of re-shaping the JSON directly from the response. 1. We added transformHasManyResponse for re-shaping JSON for hasMany relationships. we avoided the normalize word as ember-data serialize methods usually return something JSON:API shaped and we distinctly don't want to do that. Transform was the best word we could think of. 2. The integration tests across all of our models here feel very much like those types of tests that aren't really testing much, or assert too much to an extent that they get in the way rather than be of any use. I'd very much like to move a lot of this to unit tests. Currently most of the fingerprinting functionality is unit tested and these integration tests were originally to give confidence that IDs and related properties were being added correctly. 3. We've added a hasMany relationship, but not the corresponding belongsTo - yet at least. We don't require the belongsTo right now, and if we do we can add it later. * Integrate ServiceInstance search bar for Node:ServiceInstances * Hide Node.Meta when on the Node:ServiceINstance page We use a little string replace hack here for a human-like label, this is soon to be replaced with proper i10n replacement * Always ensure that a Namespace is set, and add comment explaining
2020-12-09 13:08:30 +00:00
)
ui: Search/filtering 'Filtered by:' search status (#9442) Adds a 'status' for the filtering/searching in the UI, without this its not super clear that you are filtering a recordset due to the menu selections being hidden once closed. You can also use the pills in this status view to delete individual filters.
2021-01-25 18:13:54 +00:00
(reject-by 'Service.Kind' 'connect-proxy' item.Services)
as |sort filters items|}}
ui: New search/sort/filtering bar for Node > ServiceInstances (#9326) * Model layer changes to turn Node:ServiceInstances into hasMany We tried to make something that feels a little like ember-data yet not leave our approach of re-shaping the JSON directly from the response. 1. We added transformHasManyResponse for re-shaping JSON for hasMany relationships. we avoided the normalize word as ember-data serialize methods usually return something JSON:API shaped and we distinctly don't want to do that. Transform was the best word we could think of. 2. The integration tests across all of our models here feel very much like those types of tests that aren't really testing much, or assert too much to an extent that they get in the way rather than be of any use. I'd very much like to move a lot of this to unit tests. Currently most of the fingerprinting functionality is unit tested and these integration tests were originally to give confidence that IDs and related properties were being added correctly. 3. We've added a hasMany relationship, but not the corresponding belongsTo - yet at least. We don't require the belongsTo right now, and if we do we can add it later. * Integrate ServiceInstance search bar for Node:ServiceInstances * Hide Node.Meta when on the Node:ServiceINstance page We use a little string replace hack here for a human-like label, this is soon to be replaced with proper i10n replacement * Always ensure that a Namespace is set, and add comment explaining
2020-12-09 13:08:30 +00:00
<div class="tab-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
{{#if (gt items.length 0) }}
<input type="checkbox" id="toolbar-toggle" />
ui: New search/sort/filtering bar for Node > ServiceInstances (#9326) * Model layer changes to turn Node:ServiceInstances into hasMany We tried to make something that feels a little like ember-data yet not leave our approach of re-shaping the JSON directly from the response. 1. We added transformHasManyResponse for re-shaping JSON for hasMany relationships. we avoided the normalize word as ember-data serialize methods usually return something JSON:API shaped and we distinctly don't want to do that. Transform was the best word we could think of. 2. The integration tests across all of our models here feel very much like those types of tests that aren't really testing much, or assert too much to an extent that they get in the way rather than be of any use. I'd very much like to move a lot of this to unit tests. Currently most of the fingerprinting functionality is unit tested and these integration tests were originally to give confidence that IDs and related properties were being added correctly. 3. We've added a hasMany relationship, but not the corresponding belongsTo - yet at least. We don't require the belongsTo right now, and if we do we can add it later. * Integrate ServiceInstance search bar for Node:ServiceInstances * Hide Node.Meta when on the Node:ServiceINstance page We use a little string replace hack here for a human-like label, this is soon to be replaced with proper i10n replacement * Always ensure that a Namespace is set, and add comment explaining
2020-12-09 13:08:30 +00:00
<Consul::ServiceInstance::SearchBar
ui: Add External Sources Filter to Node > Service Instances (#9368) * Add service collections to get all ExternalServices * Add a basic collection helper * Use the collections to get all ExternalSources * Remove old Controllers
2020-12-14 14:25:33 +00:00
@sources={{get (collection items) 'ExternalSources'}}
ui: New search/sort/filtering bar for Node > ServiceInstances (#9326) * Model layer changes to turn Node:ServiceInstances into hasMany We tried to make something that feels a little like ember-data yet not leave our approach of re-shaping the JSON directly from the response. 1. We added transformHasManyResponse for re-shaping JSON for hasMany relationships. we avoided the normalize word as ember-data serialize methods usually return something JSON:API shaped and we distinctly don't want to do that. Transform was the best word we could think of. 2. The integration tests across all of our models here feel very much like those types of tests that aren't really testing much, or assert too much to an extent that they get in the way rather than be of any use. I'd very much like to move a lot of this to unit tests. Currently most of the fingerprinting functionality is unit tested and these integration tests were originally to give confidence that IDs and related properties were being added correctly. 3. We've added a hasMany relationship, but not the corresponding belongsTo - yet at least. We don't require the belongsTo right now, and if we do we can add it later. * Integrate ServiceInstance search bar for Node:ServiceInstances * Hide Node.Meta when on the Node:ServiceINstance page We use a little string replace hack here for a human-like label, this is soon to be replaced with proper i10n replacement * Always ensure that a Namespace is set, and add comment explaining
2020-12-09 13:08:30 +00:00
@search={{search}}
ui: Remove WithSearching mixin, use helpers instead (#7961) * ui: Remove WithSearching mixin, use composable helpers instead
2020-05-29 15:42:46 +00:00
@onsearch={{action (mut search) value="target.value"}}
ui: New search/sort/filtering bar for Node > ServiceInstances (#9326) * Model layer changes to turn Node:ServiceInstances into hasMany We tried to make something that feels a little like ember-data yet not leave our approach of re-shaping the JSON directly from the response. 1. We added transformHasManyResponse for re-shaping JSON for hasMany relationships. we avoided the normalize word as ember-data serialize methods usually return something JSON:API shaped and we distinctly don't want to do that. Transform was the best word we could think of. 2. The integration tests across all of our models here feel very much like those types of tests that aren't really testing much, or assert too much to an extent that they get in the way rather than be of any use. I'd very much like to move a lot of this to unit tests. Currently most of the fingerprinting functionality is unit tested and these integration tests were originally to give confidence that IDs and related properties were being added correctly. 3. We've added a hasMany relationship, but not the corresponding belongsTo - yet at least. We don't require the belongsTo right now, and if we do we can add it later. * Integrate ServiceInstance search bar for Node:ServiceInstances * Hide Node.Meta when on the Node:ServiceINstance page We use a little string replace hack here for a human-like label, this is soon to be replaced with proper i10n replacement * Always ensure that a Namespace is set, and add comment explaining
2020-12-09 13:08:30 +00:00
@searchproperties={{searchProperties}}
@sort={{sort}}
@filter={{filters}}
/>
{{/if}}
{{! filter out any sidecar proxies }}
<DataCollection
@type="service-instance"
ui: Search/filtering 'Filtered by:' search status (#9442) Adds a 'status' for the filtering/searching in the UI, without this its not super clear that you are filtering a recordset due to the menu selections being hidden once closed. You can also use the pills in this status view to delete individual filters.
2021-01-25 18:13:54 +00:00
@sort={{sort.value}}
ui: New search/sort/filtering bar for Node > ServiceInstances (#9326) * Model layer changes to turn Node:ServiceInstances into hasMany We tried to make something that feels a little like ember-data yet not leave our approach of re-shaping the JSON directly from the response. 1. We added transformHasManyResponse for re-shaping JSON for hasMany relationships. we avoided the normalize word as ember-data serialize methods usually return something JSON:API shaped and we distinctly don't want to do that. Transform was the best word we could think of. 2. The integration tests across all of our models here feel very much like those types of tests that aren't really testing much, or assert too much to an extent that they get in the way rather than be of any use. I'd very much like to move a lot of this to unit tests. Currently most of the fingerprinting functionality is unit tested and these integration tests were originally to give confidence that IDs and related properties were being added correctly. 3. We've added a hasMany relationship, but not the corresponding belongsTo - yet at least. We don't require the belongsTo right now, and if we do we can add it later. * Integrate ServiceInstance search bar for Node:ServiceInstances * Hide Node.Meta when on the Node:ServiceINstance page We use a little string replace hack here for a human-like label, this is soon to be replaced with proper i10n replacement * Always ensure that a Namespace is set, and add comment explaining
2020-12-09 13:08:30 +00:00
@filters={{filters}}
@search={{search}}
ui: [BUGFIX] Ensure namespace is used for node API requests (#9410) Nodes themselves are not namespaced, so we'd originally assumed we did not need to pass through the ns query parameter when listing or viewing nodes. As it turns out the API endpoints we use to list and view nodes (and related things) return things that are namespaced, therefore any API requests for nodes do require a the ns query parameter to be passed through to the request. This PR adds the necessary ns query param to all things Node, apart from the querying for the leader which only returns node related information. Additionally here we decided to show 0 Services text in the node listing if there are nodes with no service instances within the namespace you are viewing, as this is clearer than showing nothing at all. We also cleaned up/standardized the text we use to in the empty state for service instances.
2021-01-04 16:42:44 +00:00
@items={{items}}
ui: New search/sort/filtering bar for Node > ServiceInstances (#9326) * Model layer changes to turn Node:ServiceInstances into hasMany We tried to make something that feels a little like ember-data yet not leave our approach of re-shaping the JSON directly from the response. 1. We added transformHasManyResponse for re-shaping JSON for hasMany relationships. we avoided the normalize word as ember-data serialize methods usually return something JSON:API shaped and we distinctly don't want to do that. Transform was the best word we could think of. 2. The integration tests across all of our models here feel very much like those types of tests that aren't really testing much, or assert too much to an extent that they get in the way rather than be of any use. I'd very much like to move a lot of this to unit tests. Currently most of the fingerprinting functionality is unit tested and these integration tests were originally to give confidence that IDs and related properties were being added correctly. 3. We've added a hasMany relationship, but not the corresponding belongsTo - yet at least. We don't require the belongsTo right now, and if we do we can add it later. * Integrate ServiceInstance search bar for Node:ServiceInstances * Hide Node.Meta when on the Node:ServiceINstance page We use a little string replace hack here for a human-like label, this is soon to be replaced with proper i10n replacement * Always ensure that a Namespace is set, and add comment explaining
2020-12-09 13:08:30 +00:00
as |collection|>
<collection.Collection>
<Consul::ServiceInstance::List
@node={{item}}
@routeName="dc.services.show"
@items={{collection.items}}
@checks={{checks}}
/>
</collection.Collection>
<collection.Empty>
ui: Use empty-state for our small empty states (#8262)
2020-07-08 13:34:57 +00:00
<EmptyState>
<BlockSlot @name="body">
<p>
ui: [BUGFIX] Ensure namespace is used for node API requests (#9410) Nodes themselves are not namespaced, so we'd originally assumed we did not need to pass through the ns query parameter when listing or viewing nodes. As it turns out the API endpoints we use to list and view nodes (and related things) return things that are namespaced, therefore any API requests for nodes do require a the ns query parameter to be passed through to the request. This PR adds the necessary ns query param to all things Node, apart from the querying for the leader which only returns node related information. Additionally here we decided to show 0 Services text in the node listing if there are nodes with no service instances within the namespace you are viewing, as this is clearer than showing nothing at all. We also cleaned up/standardized the text we use to in the empty state for service instances.
2021-01-04 16:42:44 +00:00
This node has no service instances{{#if (gt items.length 0)}} matching that search{{/if}}.
ui: Use empty-state for our small empty states (#8262)
2020-07-08 13:34:57 +00:00
</p>
</BlockSlot>
</EmptyState>
ui: New search/sort/filtering bar for Node > ServiceInstances (#9326) * Model layer changes to turn Node:ServiceInstances into hasMany We tried to make something that feels a little like ember-data yet not leave our approach of re-shaping the JSON directly from the response. 1. We added transformHasManyResponse for re-shaping JSON for hasMany relationships. we avoided the normalize word as ember-data serialize methods usually return something JSON:API shaped and we distinctly don't want to do that. Transform was the best word we could think of. 2. The integration tests across all of our models here feel very much like those types of tests that aren't really testing much, or assert too much to an extent that they get in the way rather than be of any use. I'd very much like to move a lot of this to unit tests. Currently most of the fingerprinting functionality is unit tested and these integration tests were originally to give confidence that IDs and related properties were being added correctly. 3. We've added a hasMany relationship, but not the corresponding belongsTo - yet at least. We don't require the belongsTo right now, and if we do we can add it later. * Integrate ServiceInstance search bar for Node:ServiceInstances * Hide Node.Meta when on the Node:ServiceINstance page We use a little string replace hack here for a human-like label, this is soon to be replaced with proper i10n replacement * Always ensure that a Namespace is set, and add comment explaining
2020-12-09 13:08:30 +00:00
</collection.Empty>
</DataCollection>
ui: Move routes to use data-sources (#8321) * Add uri identifiers to all data source things and make them the same 1. Add uri identitifer to data-source service 2. Make <EventSource /> and <DataSource /> as close as possible 3. Add extra `.closed` method to get a list of inactive/closed/closing data-sources from elsewhere * Make the connections cleanup the least worst connection when required * Pass the uri/request id through all the things * Better user erroring * Make event sources close on error * Allow <DataLoader /> data slot to be configurable * Allow the <DataWriter /> removed state to be configurable * Don't error if meta is undefined * Stitch together all the repositories into the data-source/sink * Use data.source over repositories * Add missing <EventSource /> components * Fix up the views/templates * Disable all the old route based blocking query things * We still need the repo for the mixin for the moment * Don't default to default, default != ''
2020-07-17 13:42:45 +00:00
</div>
{{/let}}