These bindings can be replaced wholesale with the more idiomatic
alternative: aliases.
In addition, avoid passing in user to components where it can be injected directly.
One of the perceived downsides of dependency injection can be
that it can make debugging feel more difficult because it's not
immediately clear where the value is coming from, which the explicit
variant we previously used does not suffer from. It might also be
argued that we also lose out on a seam that could be useful in the
future where a component doesn't care about the specific type of
user, just that one is passed in.
While explicitness is often a virtue, it comes at the cost of increased
noise that pervades multiple layers of components. I'd argue this makes
the parent components more difficult to understand, given they are
littered with unnecessary references to data they themselves do not
need.
This decreases the noise/ceremony around accessing
userPermissions/auth data and restricts access to that data to
the child components that actually need to know about it.
As to losing a seam, it appears 1) that this isn't
currently necessary and 2) we can use an internal computed
property should the need arise in the future.
When a user restarts a job, we should not try fetching the log again. In
order to do this I added a guard in job-log component, which checks if
attributes changed in didReceiveAttrs callback. If the old job value is
the same as the new value, we don't need to do anything.
