SPIKE: How to scroll to a location on the correct page

[birchamp]

We need to develop a way to position (not just filter) the file at a particular record.

Break into small issues. Broken into:

1088

1089

[mandolyte]

@birchamp what are your thoughts on this: https://mui.com/components/data-grid/rows/#infinite-loading

I have found a number of articles to read on this topic...

Actually, not sure that our "datatable" is based on this component. But conceptually, it is a nice illustration of what "infinite scrolling" is and it is very nice to know that MUI supports it (we use a a lot of their components)

Found: we use https://www.material-ui-datatables.com/; if we stay with it (avoiding massive refactoring), it will likely get down to lots of math...

[mandolyte]

@Joel-C-Johnson here is some reading to do as part of the spike:

• https://uxplanet.org/ux-infinite-scrolling-vs-pagination-1030d29376f1
• https://crocoblock.com/blog/pagination-vs-infinite-scroll/
• https://www.uxmatters.com/mt/archives/2018/11/paging-scrolling-and-infinite-scroll.php
• https://www.knowband.com/blog/ecommerce-blog/pagination-vs-infinite-scrolling/
• https://uxdesign.cc/ui-cheat-sheet-pagination-infinite-scroll-and-the-load-more-button-e5c452e279a8
• https://webo.digital/blog/pagination-vs-infinite-scroll-which-is-better-for-your-content/
• https://www.oneupweb.com/blog/infinite-scroll-pagination-better/

[mandolyte]

@Joel-C-Johnson let's chat about doing a PoC. What I'm thinking of is something like this:

• A main workspace containing two infinite scrolling windows, divided horizontally, top and bottom
• The top window is a scripture window with divided into 3 or more columns
• The bottom window is the TSV (say Translation Notes)

Both using the MUI data-grid component; and both synced on scroll and some provision to sync on demand (in the case where they scroll manually to some location and need to "re-center", if you will)

[mandolyte]

@klappy @mannycolon @PhotoNomad0 @ancientTexts-net I have been searching for data table implementations that can support large tables/datasets. I have found some that might work, but I thought I'd describe an ideal component and wondered if you had ever seen like it. So here are my thoughts...

The goals would be to minimize overhead of rendered data and make the amount of data available essentially unbounded. This means the DOM would be constantly updated as it scrolled, rendering the rows on the fly; enough to fill the display space plus perhaps one row overflow at top and bottom (outside the view port).

• First, there is a data source defined by an interface. So that whether the data is actually stored in-memory, in indexedDB, proskomma, then a function, say getRow(n), will get the nth row of data.
• Second, the UI has "callbacks" that will fire when a row scrolls out of view or into view. The callbacks would reconstruct the viewport on they fly. In other words, the viewport and the rendered data are nearly the same.
• Third, no pagination... the user can scroll wherever they wish (and then sync back up with the below feature)
• Fourth, must support the "scroll to view" function so that multiple tables can be synced with each other

I should note, that this is only one alternative I'm considering for this spike.

If you have suggestions, please reply here!

(I am keeping notes over here)

[mannycolon]

@mandolyte I would suggest taking a look at react-table https://react-table.tanstack.com/

[mandolyte]

@birchamp I have made a little demo that shows what I have found so far.

If we keep pagination...

1. Unable to programmatically move to a page (at least, I haven't figured out how to).
2. Given all references, we could save the references to an array which could be used to move to page, then the reference (if we could move to the page, see preceding).

If we eliminate pagination...

• Then we may run into memory, performance issues.
• Would not be too hard to try and find out.

Since:

1. Not all verses have a translation note, and,
2. Some verses have multiple notes, then a "verse chooser" would have to only show those that actually exist; and the scroll would always be to the first one.

[Joel-C-Johnson]

@mandolyte, After going through the given articles and the above chats, I will share my suggestion that might fit into this issue, here are my thoughts. According to our need, pagination would be better than scrolling as we need a filter/search function (better work with pagination) so,

1. Find/Select a good data table that fits our data.
2. keep an "id" for each row.
3. On clicking a row (for editing in translation mode), save the row id.
4. if the user use the filter option and wants to come back to the previous location(edited word),
5. On clearing/resetting the filter, add a function(scrollIntoView()) and pass the row id and it might take to the location.

Please ignore this comment if it is wrong. I haven't tried yet.

[mandolyte]

@Joel-C-Johnson I think you are spot on. I have a created demo showing this, since I have come to the same conclusion.

[mandolyte]

To run the demo:

1. Clone datatable-translatable locally
2. Switch to branch scroll-demo-cn-1075
3. yarn install && yarn start
4. Point browser to localhost:6060 to show styleguidist
5. In the side navigation, click "Scroll to Verse Example" (or better, go fullscreen with http://localhost:6060/#/Scroll%20to%20Verse%20Example)
6. Instructions are shown on how to work the demo
7. I did a PR to show what changes I made (but do not merge!!): https://github.com/unfoldingWord/datatable-translatable/pull/82

[ancientTexts-net]

@Joel-C-Johnson @birchamp LOOKIN' GOOD in the SG demo!

[mandolyte]

Hey @birchamp! @Joel-C-Johnson has made some progress on studying the problem. Before we break down this spike into issues, I think we need a goal (or goals). Here are examples I thought of. Can you review and adjudicate for us? Thanks!

We need to position the file at a particular location because:

1. when the user uses the search, they want to position the file at one of the search results
2. when the user uses the search and then closes it, they want to return to where they were before they searched
3. the user needs to be able to bookmark one or more locations in the file and easily re-position the file at those bookmarked locations

@birchamp @ancientTexts-net

[birchamp]

@mandolyte @Joel-C-Johnson @ancientTexts-net

1. Yes they want to be able to position the file at one of the search results.
2. This is not typical, but one solution that I can think of is: a. If the user clicks and places the caret inside a record then that is the result to center on. b. if the user doesn't click then they return to their previous location
3. I can see bookmarks being useful but it hasn't been requested yet.

[mandolyte]

@Joel-C-Johnson Looks like item 1 is the goal. And item 2 is pretty much what your were trying to do already. Here are my thoughts on a list of spike issues:

Add Go To button to row header

This button would typically be clicked on a row in search results. When clicked:

• Search is closed (programmatically) (if open)
• The row Id (row number??) is noted (does datatable-translatable know there is a row id and which column it is in??)
• The data table is positioned is positioned at that row (top of page/viewport?)
• Possible complicating factors:
  • how will a generic datatable uniquely identify a row?
  • does pagination interfere with how positioning works?

Return to last edited row

If the search is closed by the user, then either:

1. If the user has unsaved changes, it will return to where the user was last working
2. Otherwise, it will return to the "page" that the user was last viewing

[birchamp]

@birchamp break down in to issues