1. 18 Mar, 2021 1 commit
    • Eduardo Sanz García's avatar
      Increased number of threads per page in notebook · 5f0c5dc6
      Eduardo Sanz García authored
      We have done a little investigation on the number of threads that are
      visible on a pages in notebook:
      - on mobile: up to 4 threads
      - on tables: up to 7 threads
      - on mobile: up to 8 threads
      
      These numbers are just rough estimates since zoom level and screen
      orientation affects these numbers.
      
      Our aim: we want to display the larger number of threads without forcing
      users to do excessive scrolling.
      
      We are going to test with 25 threads per page and see what are users
      think about that.
      5f0c5dc6
  2. 16 Mar, 2021 12 commits
    • Robert Knight's avatar
      Rename `pageSize` => `getPageSize` · 5ae245d8
      Robert Knight authored
      Per PR feedback, rename the `pageSize` option to something that sounds more like a
      function/callback, which is what this value now is.
      5ae245d8
    • Robert Knight's avatar
      Optimize perceived loading time by varying /api/search page size · 9c96e1fe
      Robert Knight authored
      When fetching annotations from the backend there is a trade-off between
      the time taken to generate a page (less if the page size is smaller) and
      the time taken to fetch all pages (less if the page size is larger).
      
      To optimize the perceived loading time we can pick a smaller page size
      for the first page, enabling the first screenful of annotations/threads
      to appear quickly, and then use a larger page size for the remaining
      pages.
      
       - Change the `pageSize` option for `SearchClient` from a fixed number
         to a callback that returns the page size for a given page index
      
       - Set the default value for the `pageSize` option to use a small page
         size (50) for the first page and a larger size (200) for remaining
         pages
      9c96e1fe
    • Robert Knight's avatar
      Use "page" rather than "chunk" or "batch" in SearchClient · 0727d13b
      Robert Knight authored
      Consistently use the term "page" to refer to a subset of results fetched
      from the search API instead of "batch" or "chunk". This is more
      consistent within the rest of the client code and also consistent with
      the API documentation.
      
       - Rename `chunkSize` constructor argument to `pageSize`
       - Change internal references to "batch" or "chunk" in SearchClient to
         "page"
      0727d13b
    • Eduardo Sanz García's avatar
      Improved string formatting of the client's version · d53e4c34
      Eduardo Sanz García authored
      Reordered fields according to the UI and capitalised properties.
      d53e4c34
    • Eduardo Sanz García's avatar
      Preserve line breaks on copy command · 1e202a16
      Eduardo Sanz García authored
      I have tested successfully on the latest version of Chrome, Safari and
      Firefox. I also tested successfully on an Android and iOS devices.
      
      I couldn't tested more exhaustively on other desktop/mobile browser
      versions because SauceLabs didn't allowed me to retrieve the pasted
      text.
      
      Closes https://github.com/hypothesis/product-backlog/issues/1180
      1e202a16
    • Robert Knight's avatar
      Reword comment about optimistically set group ID · 23a84ffa
      Robert Knight authored
      Reword this comment to try and make the intent of the code clearer.
      23a84ffa
    • Robert Knight's avatar
      Improve comments for `load` method in `loadAnnotationsService` · 5445ad58
      Robert Knight authored
      It is safe to call `load` while annotations are already being loaded,
      in that it does all the necessary cleanup/interruption of the existing
      fetch. However it wasn't immediately clear to me from the code that this
      was the case.
      5445ad58
    • Robert Knight's avatar
      Fetch annotations in parallel with groups and profile where possible · 1d00a99b
      Robert Knight authored
      Currently both the sidebar and notebook wait until the user's profile and groups are
      fetched before fetching annotations. This is because the search query to
      fetch annotations depends on the focused group. The groups query may
      take several hundred ms to complete, so this ends up delaying the
      initial fetch and display of annotations by that amount of time.
      
      In the notebook the common case is that the user is already logged in
      and the notebook is configured to display a specific group ("the direct
      linked group"): whatever the user had previously selected in the sidebar.
      In this scenario it is very likely that the direct-linked group will end
      up being the focused one after groups are fetched.
      
      Based on these assumptions, we can speed up the initial annotation by
      loading annotations from the direct-linked group. If the focused group
      ends up being different, annotations will just be re-fetched from the
      correct group once that is known.
      1d00a99b
    • Robert Knight's avatar
      Remove obsolete references to `offset` query param · 8d237661
      Robert Knight authored
       - Remove unused references to `offset` search query param
       - Add JSDoc to clarify what the `searchAfter` param is
      8d237661
    • Robert Knight's avatar
    • Robert Knight's avatar
      Add additional SearchClient test for search params · c336a814
      Robert Knight authored
      - Add an additional test that checks the query params sent for each of the
        pages sent for a simple single-URI query.
      
      - Refactor the remaining SearchClient tests which still use
        promise-chains to use async/await instead for readability and
        consistency
      c336a814
    • Robert Knight's avatar
      Use cursor-based pagination through search API results · b68dae47
      Robert Knight authored
      Optimize fetching pages of results from the backend by using
      cursor-based paging (via `search_after`) rather than offset-based paging
      (via `offset`, `limit`). Cursor-based paging is more efficient to handle in
      the backend as the starting position of a page within the overall result set increases.
      
      This also fixes a race condition where results at the boundary between
      pages might be fetched twice or not fetched if new matches for the query
      become available while results are fetched.
      b68dae47
  3. 15 Mar, 2021 27 commits