When router is not set up yet sending events to it will fail. If that's
the case, we can just swallow the error, because afterSignIn will take
effect only if we are already in some state in the router.
Previously we were checking if we should display an error message by
adding if statements in a template. This is not the best way to do
it, because it clutters a template and makes code harder to follow.
In this commit I move rendering error templates to the router. Code for
rendering error when there is no builds is not the best way to do it
either, but it can be improved when new router changes are merged to
Ember's master and a way Ember Data is handling promises is revised and
improved.
Till now, when switching between different views, we were switching
different bindings on repo controller. This was quite innefficient,
because then we needed to add bindings also from other controllers and
it's hard to manage such structure when we would like to add specialized
controllers (like LogController).
The new setup is more declarative, meaning that we do such things on the
router and set things on proper controllers. The only drawback is that
now we need to setup a few observers instead of bindings for "current"
views (ie. when viewing the newest repo or when viewing the last build
in current repo).
At this point it may not look like huge improvement, but it will open a
way to more refactorings.
When user has Travis CI's web page open in the background we should not
process pusher events immediately, because she will not see the changes
on a page anyway. During peak hours we can get several messages per
second, which requires some CPU work almost all the time. By using
visibility API we can detect if the tab with Travis CI is in the
background and if that's the case we will process pusher messages in
batches every 5 minutes. This is much better for the CPU, because it
means one bigger spike every few minutes and additionally some of the
updates don't have to be done (for example if we get several job:started
events, Ember's run loop will process only last one when it comes to
rendering 'current' build).
Visibility.js provides a thin wrapper over page visibility API, which
allows to detect if page is currently visible by user. This allows us to
stop live updates when it's not needed. This is especially easy in case
of timers, because Visibility.js provides setInterval replacement, which
runs given code only when page is visible.
A lot of ❤️ for @tchack, who showed me visibility.js!
It seems that running Ember.run.later periodically can cause CPU usage
to increase over time. Such increase adds up to already increasing CPU
usage because of data amount growing.
This commit tries to mitigate the issue by using setTimeout instead
This will make them look nicer on Retina screens. We may want to make
them even bigger if people are increasing the size of the page on
Travis, but doing that causes all kinds of alignment issues, so it's not
necessary to do now, I think.
In general, the "light" on web pages come from directly above, so
shadows should be directly below things. This isn't really a shadow,
though, but rather a way to make it seem like the text is "embossed"
into the surface by giving it a slight sheen on the bottom edge, in
which case the shadow definitely shouldn't be shifted left or right.
