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.
After recent refactorings status images popup started to fetch branches
info whenever a repo page was opened, resulting in additional HTTP
requests. Furthermore, because of a way we load branches, it could
result in builds view displaying very old builds, because in API V2 we
essentially download last build for each branch for branches request.
This commit fixes the situation in 2 ways:
1. We wait with downloading branhes till the popup is open
2. We use a V3 requests to download branches and we don't put that data
into the store