Overhaul view and sort behavior

Big changes to view, sort, routing, filtering, etc, etc, etc...

Todo
-------
- [x] stream search -- race between $scope.updater and stream controller, need to send the filter
- [x] page search -- simple matter of fixing the ugly ng-show conditions at the bottom of the viewer template perhaps with more verbose, obvious variables, or scope/controller functions to abstract the route details from the template a bit
- [x] Check on https://github.com/hypothesis/h/pull/1436#discussion_r16705832 (leave as is 2014-08-29)
- [x] Restore "no results for “query”" message.
- [x] Annotations don't watch for changes
- [x] forced login -- a comment about ideas for that [here](https://github.com/hypothesis/h/issues/1020#issuecomment-53400218)

That was left-over from an earlier iteration when there wasn't a 1-1 ratio
between thread and threadFilter directives and I had to track hits. It was
a performance optimization because there was no guarantee of any key for
uniquely identifying the container and I didn't want to iterate a cache
every time.

0f141b93d12c7277fb7f474c6acb5e172ec2856d

On Tue, Sep 16, 2014 at 4:13 AM, Aron Carroll <notifications@github.com>
wrote:

> In h/static/scripts/directives/threadFilter.coffee:
>
> > +    #
> > +    # @description
> > +    # Check whether a message container carries a message matching the
> > +    # configured filters. If filtering is not active then the result is
> > +    # always `true`.  Updates the `hits` property to reflect changes in match
> > +    # status of the container by caching the result is the `__filterResult`
> > +    # property of the container.
> > +    ###
> > +    this.check = (container) ->
> > +      unless container?.message then return false
> > +      if this.active()
> > +        match = !!viewFilter.filter([container.message], @_filters).length
> > +      else
> > +        match = true
> > +      @hits += (match - !!container.__filterResult)
> > +      container.__filterResult = match
>
> This is a bit messy, I don't like how we're adding a property to an
> external object and managing the it over two separate objects (we set here,
> but delete in the directive). Is there a way we can uniquely identify a
> container and define an api within this controller that can be used by the
> directive? e.g. vm.setMatch(container), vm.unsetMatch(container),
> vm.hasMatch(container). Also the coercion of the boolean to a number on
> line 99 is really confusing, I'd rather see this as @hits += (match -
> Number(container.__filterResult)) or the more verbose:
>
> filterResultCount = if container.__filterResult then 1 or 0@hits += (match - filterResultCount)
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/hypothesis/h/pull/1436/files#r17595012>.
>