Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-37233

Switch to a responsive table component

    Details

    • Similar Issues:
    • Epic Link:
    • Sprint:
      pacific

      Description

      This looks pretty excellent and we will want this kind of functionality https://facebook.github.io/fixed-data-table/example-filter.html

      In Scope

      • Can you please investigate the feasibility of this?
      • How well would this work on mobile?
      • If it looks good and we don't think it will take a long time lets switch? (have a chat with Michael before starting)

        Attachments

          Issue Links

            Activity

            Hide
            jamesdumay James Dumay added a comment -

            Cliff Meyers would switching help with things like JENKINS-35996?

            Show
            jamesdumay James Dumay added a comment - Cliff Meyers would switching help with things like JENKINS-35996 ?
            Hide
            cliffmeyers Cliff Meyers added a comment -

            James Dumay more than likely, yes. The reason the row animation was a problem is that you can't animate the height or max-height of TR elements (and our JDL Table is indeed based on HTML table / tr / td elements). Before we jump into using any particular React data table I think we should do a quick evaluation of the different tables just to make sure we are picking the right one.

            Show
            cliffmeyers Cliff Meyers added a comment - James Dumay more than likely, yes. The reason the row animation was a problem is that you can't animate the height or max-height of TR elements (and our JDL Table is indeed based on HTML table / tr / td elements). Before we jump into using any particular React data table I think we should do a quick evaluation of the different tables just to make sure we are picking the right one.
            Hide
            jamesdumay James Dumay added a comment -

            Cliff Meyers go for it

            One thing that I like about this is filtering, sorting and mobile responsiveness.

            Show
            jamesdumay James Dumay added a comment - Cliff Meyers go for it One thing that I like about this is filtering, sorting and mobile responsiveness.
            Hide
            cliffmeyers Cliff Meyers added a comment -

            James Dumay the API looks pretty decent, in particular it's crucial that the grid allows custom JSX for each cell so that we can customize it with anything we dream up. I tested it on my Nexus 6P and it seems decent, although some oddities:

            • Sorting did not work at all; would need to debug to find out why. Maybe it's not listening for the right gesture events.
            • Since the grid is virtualized, you can only command-F against the visible data. This will be an issue with any virtualized grid of course.
            • Filtering is not really "baked in"; they're just writing a bunch of custom logic and updating the data provider to the grid. This is the same amount of code you'd write for any filtered list.
            • Need to see how the dimensions work. They want explicit pixel dimensions for the width and height of the grid. It doesn't seem to support percentages, strangely. That seems... very unresponsive to me. Although we could write a JSX component we use to wrap the grid and specify appropriate width or height based on browser's resize event.

            I'd say this might be worth spiking a POC on a single screen, perhaps pipelines or activity? Maybe we can touch base on it when you are back next week and I whip something together real quick. I suspect I could adapt one of our screens in a few hours.

            Show
            cliffmeyers Cliff Meyers added a comment - James Dumay the API looks pretty decent, in particular it's crucial that the grid allows custom JSX for each cell so that we can customize it with anything we dream up. I tested it on my Nexus 6P and it seems decent, although some oddities: Sorting did not work at all; would need to debug to find out why. Maybe it's not listening for the right gesture events. Since the grid is virtualized, you can only command-F against the visible data. This will be an issue with any virtualized grid of course. Filtering is not really "baked in"; they're just writing a bunch of custom logic and updating the data provider to the grid. This is the same amount of code you'd write for any filtered list. Need to see how the dimensions work. They want explicit pixel dimensions for the width and height of the grid. It doesn't seem to support percentages, strangely. That seems... very unresponsive to me. Although we could write a JSX component we use to wrap the grid and specify appropriate width or height based on browser's resize event. I'd say this might be worth spiking a POC on a single screen, perhaps pipelines or activity? Maybe we can touch base on it when you are back next week and I whip something together real quick. I suspect I could adapt one of our screens in a few hours.
            Hide
            cliffmeyers Cliff Meyers added a comment -

            The grid does handle horizontal scrolling pretty well, when the grid's width is larger than the viewport.

            Show
            cliffmeyers Cliff Meyers added a comment - The grid does handle horizontal scrolling pretty well, when the grid's width is larger than the viewport.
            Hide
            cliffmeyers Cliff Meyers added a comment -

            Some more detail from initial spike on this grid:

            1. The grid requires an explicit height and width. I wrote a wrapper component that listens for resize events and then updates the props on the FDT, and that seems to work well. If the wrapper could be sized using CSS top/bottom constraints then the grid would behave nicely. This would be easy for Activity / Branches / PR's screens but the main Pipelines screens and variable height Favorites / ExtensionPoint area.
            2. For width - especially on mobile - we could probably allow the grid to exceed the size of the wrapper and leverage its built-in horizontal scroll capability. So the wrapper would probably have a "minGridWidth" property that we could set to maybe something like 800 or 1000px and on mobile the user could scroll left/right. On larger screens the grid would just be stretched to fill the available space.
            3. Columns also require an explicit width. We could allow the wrapper to define something more flexible - like percentages - and then translate that pixel values that are passed down to the columns.
            4. There's a desire to hide certain columns on mobile; normally would be done with media queries. I am not sure the grid would respond well to that based on how it measures itself; again we might be able to leverage something in the wrapper that could do some tricks and then turn certain columns on and off.
            Show
            cliffmeyers Cliff Meyers added a comment - Some more detail from initial spike on this grid: The grid requires an explicit height and width. I wrote a wrapper component that listens for resize events and then updates the props on the FDT, and that seems to work well. If the wrapper could be sized using CSS top/bottom constraints then the grid would behave nicely. This would be easy for Activity / Branches / PR's screens but the main Pipelines screens and variable height Favorites / ExtensionPoint area. For width - especially on mobile - we could probably allow the grid to exceed the size of the wrapper and leverage its built-in horizontal scroll capability. So the wrapper would probably have a "minGridWidth" property that we could set to maybe something like 800 or 1000px and on mobile the user could scroll left/right. On larger screens the grid would just be stretched to fill the available space. Columns also require an explicit width. We could allow the wrapper to define something more flexible - like percentages - and then translate that pixel values that are passed down to the columns. There's a desire to hide certain columns on mobile; normally would be done with media queries. I am not sure the grid would respond well to that based on how it measures itself; again we might be able to leverage something in the wrapper that could do some tricks and then turn certain columns on and off.
            Hide
            cliffmeyers Cliff Meyers added a comment -

            We decided to shelve any further work on this and let Brody Maclean instead do a more comprehensive assessment of the app on mobile, which will drive out requirements and lead us to a better solution.

            For reference: Brody also dropped this link which contains an interesting example of a single scrollbar that handles scrolling through two different lists of data. Might be useful for how we decide to handle the layout of favorites and pipelines list. https://codepen.io/jgx/pen/wiIGc

            Show
            cliffmeyers Cliff Meyers added a comment - We decided to shelve any further work on this and let Brody Maclean instead do a more comprehensive assessment of the app on mobile, which will drive out requirements and lead us to a better solution. For reference: Brody also dropped this link which contains an interesting example of a single scrollbar that handles scrolling through two different lists of data. Might be useful for how we decide to handle the layout of favorites and pipelines list. https://codepen.io/jgx/pen/wiIGc

              People

              • Assignee:
                cliffmeyers Cliff Meyers
                Reporter:
                jamesdumay James Dumay
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: