Infinite Scroll for User and Items Part 2
Description
Environment
Potential Workaround
Attachments
blocks
relates to
Checklist
hideTestRail: Results
Activity

John Coburn June 9, 2017 at 2:10 PM
Filed Infinite Scroll Pt 3 to collect a number of to-do's while I'm in heavy bug-fix mode on this. We can break out separate issues as analysis proves necessary.

Cate Boerema June 9, 2017 at 11:57 AM
I do notice some wonkiness. If you click around in the list and sort via column headers you can generate a state where (1) more than one record is highlighted and (2) there is a blue box appearing around the component (3) there is a double vertical scrollbar and the outermost one flickers. Should we file an Infinite Scroll Part 3? Or maybe just file specific bugs for those issues? What do you think, ?

Cate Boerema June 9, 2017 at 8:16 AM
This looks great, !

John Coburn June 9, 2017 at 3:37 AM
Under the hood, it's different mark-up. I had to switch away from HTML tables due to virtualization completely breaking their vertical scroll-ability in Firefox - not to mention cases when the data on certain rows was longer than others which caused the width of the table to fluctuate. That was the very ugly beta-phase of this - it had a horizontal scroll bar appearing below the headers and was quite a bit of nasty due-diligence in research of people who have already done something like this.
There's also minor difference in the data being rendered - patron-groups getting full strings now as opposed to a column of ?'s that existed previously. Names are there in all of their glory, as well as email addresses and everything else that should be present in a functioning system. The gutters are a bit wider than before - but that wouldn't make the winning difference in the worst case of column-overload that this component could endure.
Horizontal scrolling is the fallback that should happen once some space-saving solutions are in place such as truncation and hiding of columns that are too wide to fit. It's at the threshold between what can be accomplished at the application level and what should the reasonably generic component do automatically *or with some hints from props) when it's fed a monstrous number of data columns as prescribed by someone who thinks it's useful to pile everything all at once. The ground gets even shakier when we've got pane-resizing - even window resizing - to contend with.
Already, there are some things it can do that just have yet to be taken advantage of:
'visibleColumns' - can specify which columns of the data are rendered and in what order - could possibly switch this depending on whether or not there's a selected row (when the details are open) - even build it out to let the user decide what columns are rendered (something Filip and I have discussed previously)
'columnWidths' - a new one where the width can be carved in stone or proportional. - this also can be changed at runtime, based on whatever conditions the module developer can code up.
'formatter' and now 'rowFormatter' - these don't just have to hold strings - they can hold components of their own that can do things like truncation or create accordion/expandable rows.
Please bear with this - we've got two good use cases on-hand that we can work with and a solution to this 'problem' isn't so far off.

Mike Taylor June 8, 2017 at 11:47 PM
I had never seen this horrible horizontal scrolling before the present version. Why has it now suddenly appeared?
Purpose: To fine tune infinite scroll as-needed.
Possible A/C:
List pane should occupy full screen to left (in demo, it took up just a narrow middle pane)
Horizontal scrollbar should be able to be disabled
Others?