UI: Adds blocking query support to the service detail page #5479
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds blocking query support to the new Service Detail page (new in that it now lists Service Instances instead of Nodes, and lets you click into the Instances to visit a new third level/detail page)
Additionally here we always wanted to provide functionality to warn the user of the deregistration of a Service if you are on the Service Detail page at the time of deregistration. This PR includes functionality via blocking queries to detect Service deregistration and show a warning message to the user, but also keep the old data visible incase the user still needs the information on the Service.
A visual walkthrough of this can be seen in the GIF here #5070 (comment) on deletion of the
cdn
Service (the page is now slightly different due to the Service Instance work)It essentially looks like this if you are viewing a service as it is deregistered:
Notes:
Meta Data
In #4946 we used JSON-API's meta data for
X-Consul-Index
. It turns out thatember-data
only supports JSON-API meta data usage on collections currently, not on single records/responses. There are various GH issues around that discuss this, so it seems to be a fairly common issue.Instead of doing anything too complicated, we simply added a
meta
property to the Servicemodel
.An interesting 'saviour' here is related to the fact that the Consul API uses capital case for all its properties. A lot of Consul entities/nouns/models already have a
Meta
property, so it seems like due to a piece of historical pragmatism/accident we were able to have both aMeta
property, which is actual Consul meta data, and also ameta
property which is more temporary JSON-API meta data (not used within templates).Despite the fact that capital case feels a little strange in JS land, we've always liked having the capital case API data as its immediately apparent what's coming from the API and what isn't, which is especially useful whilst editing templates. But now, this fact is enabling us to add functionality without having to jump through too many hoops.
Computed Properties /
listen
/setProperties
In order to achieve a lot of what we are doing here 'transparently' (so without having to delve too much in amending templates). We've used a lot of work from #5079 to prevent us from having to change the names of view properties/data. So for example, we continue to use
item
/items
for names whilst taking advantage of the extra error listening functionality provided byEventSource
s. We continue to usesetProperties
here also and there is some information on the ins and outs of that here #4789 (comment), and I'm still hoping to move away from usingsetProperties
in the future and replace it with our own custom 'I'm ready to render now' method. Oh lastly here, thanks @meirish for helping me to figure out the correct usage ofmetaForProperty
here.Misc
CONSUL_UI_DISABLE_REALTIME
) to globally disable blocking queries, this probably should have gone in a past PR.ember-data
specific errors rather than a default javascript error (reasons here: we currently try to keep any ember-data imports out of the repositories and only use the providedember-data
APIs). This currently works fine but I guess it would be best for it to throw anember-data
error.consul-api-double
at some point to talk about 'instances' rather than 'nodes' its not really required at the moment though so we've done whats needed here instead ('instances' equalsCONSUL_NODE_COUNT
).catch
as a name for for the error catching method. At some point there will be a usecase to have other events likeadd
,delete
etc to provide finer grained functionality for specific types or property changes rather than just 'change' - the wordcatch
probably wouldn't work as well here. Its fine for the moment so I left as is.Lastly, there'll be very similar yet smaller PRs coming soon for the Nodes detail page and the Service Instance Detail page, which will take the exact same approach here, but I left these out of the PR so its easier to digest.
Another implementation of this for the service instance detail page is in a PR here: #5487