-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ui: fix navigation for namespaced jobs in search and job version #15906
Conversation
const fullId = JSON.stringify([model.id, model.namespace]); | ||
this.store.findRecord('job', fullId).then((job) => { | ||
this.router.transitionTo('jobs.job', job.idWithNamespace); | ||
}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we extract the logic to generate the proper namespaced job ID into a helper function we could avoid this store query, but I think it's fine this way?
Ember Asset Size actionAs of fb73b61 Files that got Bigger 🚨:
Files that stayed the same size 🤷:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice find, and this solves the bug well. I think you're safe to remove gotoJobsForNamespace
in gutter-menu also.
Ember Test Audit comparison
|
Ok, I found where |
The only place where this function was being used was removed in commit 9239168
@philrenaud the Percy failure seems flaky so I'm going to merge this one. |
this.router.transitionTo('jobs.job', model.id, { | ||
queryParams: { namespace: model.namespace }, | ||
const fullId = JSON.stringify([model.id, model.namespace]); | ||
this.store.findRecord('job', fullId).then((job) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit
: I think this API call is unnecessary here and we can't guarantee when the router
transition will occur now. It could happen > ~150ms
later. When we use then
we don't guarantee when the JavaScript scheduler (event loop) will dispatch the callback.
I think we might have been able to get away with:
job.belongsTo('namespace').id()
This would have been synchronous.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah interesting. Yeah, I thought about the added network request but I thought it would OK in this case since we're redirecting to the job page so we would need to fetch it anyway. If the job is not in the state store is the user impact a delay between the click and the redirect?
I think we might have been able to get away with:
job.belongsTo('namespace').id()
I think this would have the same problem? job
is only available after the this.store.findRecord('job', fullId)
call. We we could do to avoid this is to have something like:
this.router.transitionTo('jobs.job', `${model.id}@{model.namespace}`);
But that duplicates the logic in idWithNamespace()
. We could extract the logic to a shared helper function but that seemed a bit much in this case, but maybe not?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few things to chew on here:
- Super subtle yet important difference between
model.namespace
and.belongsTo('model').id()
. The prior makes a network request, the latter is synchronous. - What happens under the hood when you use
.then
? Our.then
syntax is a misnomer..then
is really a setter function that says add this function to the array on my Promise object (that we can just callonComplete
). So we dispatch a network request, continue the thread of execution, when the call stack is cleared, we'll check our callback queue where ourjob
will be and then execute the callback function ofrouter.transitionTo
, then navigate to thejob
page and dispatch the same network request when we're on thejobs.job.index
route to get fresh data.
The key thing worth noting here is when router.transitionTo
will execute. A decent way of testing this behavior would be opening up your Developer Tools, go to the Network tab, simulate a slow network.
You did a great job on this PR and I'm really looking forward to more contributions from you! I figured you would just like to nerd out on what's actually happening under the hood.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh yeah, I'm taking this opportunity to learn more 😄
One thing to note is that this component doesn't user Ember Data (or didn't prior to this PR). The variable names model
is not actually a model, it's just an object like this: https://github.com/hashicorp/nomad/blob/v1.4.3/ui/app/components/global-search/control.js#L69-L74, so model.namespace
is just accessing a string in the object.
The .then
part is interesting. There could be a ghost redirect in a slow connection where the user clicks a search result, then clicks somewhere else, and it's then redirected to the search result. Something to keep an eye on. Would making the action async
and await
the fetch prevent the early return until the promise finishes?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great job! I think we could have avoided the API call, however, that's not a real blocker here.
Use the new URL structure for navigating to a job page.
I started in the global search, but did a quick search to find other places with the same problem. I found this
gotoJobsForNamespace
function that I think it's also wrong, but it doesn't seem to be called from anywhere so maybe we can delete it?Closes #15893