Allow column resize and auto-resize on browser resize

[thadguidry]

A community request was mentioned on our mailing list https://groups.google.com/d/topic/openrefine/H3FAf5DSHPk/discussion

This example demonstrates the basic need of having resize-able columns and also auto-resizing the columns if the user changes the size of their browser window.
http://6pac.github.io/SlickGrid/examples/example15-auto-resize.html

[jackyq2015]

there is one for AugularJS. just for the records:
https://tympanix.github.io/angular-table-resize/

[kushthedude]

@thadguidry I would like to work on the following

[thadguidry]

@kushthedude This is a baby step issue, to the larger goal of having a better grid technology that supports many features we would like such as draggable re-orderable columns, resizable columns, etc. But sure, if you want to isolate on only the "resize columns" feature that's fine. But how you do it and which technology chosen will impact the larger goal later (or you'll have to refactor/redo).

[kushthedude]

@kushthedude This is a baby step issue, to the larger goal of having a better grid technology that supports many features we would like such as draggable re-orderable columns, resizable columns, etc. But sure, if you want to isolate on only the "resize columns" feature that's fine. But how you do it and which technology choosen will impact the larger goal later (or you'll have to refactor/redo).

@thadguidry Hmm, I was first thinking to introduce table-layout property to our container and then go for column resize property for each column. But I just looked into code and saw the table is bound differently, All the column headers are coming from the DataTableHeader Container and the table data is coming from TableDataContainer which renders the data on row basis by labelling them with odd/even id.

[wetneb]

Yes, it's a big mess! Resizing is done in JavaScript explicitly, which is massively inefficient since it triggers many DOM reflows. Also the size of the headers often get out of sync with the size of the grid.

[kushthedude]

I was thinking to reimplement the tables and bind the content to a single table container. If this can be done efficiently, then the goal of having a better grid technology will be much more easier as we can directly apply our styling to the container rather worrying about how it would affect other columns and their headers.

[thadguidry]

Myself and @wetneb are not exactly front-end wizards. So we are depending on folks like you, maybe your peers or others in your circle that do have that experience to set the right course forward. I think this is going to take a bit of experimentation to see what works best. Have you looked at how agGrid with Vue works? https://www.ag-grid.com/vuejs-grid/ or others? This might serve useful to your experiments. (FYI, we can only use the MIT version and not Enterprise licensed) For features in any framework that does not have a compatible license, we would have to roll our own or find compatible licensed components to fill in the gap, or just code our own missing features eventually.

[kushthedude]

@thadguidry I will do the experiment to try bind the table to a single container for a staft and see how it goes. Coming to the Vue.js point, since the data-table is one of the biggest component of OpenRefine introducing vue.js directly into it may do more harm than good. I am looking to migrate the dialogues to vue.js for a start and if it looks good, we can look for migration of other components to Vue.js in summer, also once the data-table is converted into any progressive framework, introducing infinityLoader will be much more easier in them.

[kushthedude]

@thadguidry Rather than going for a complete rewrite for the part of the table, I tweaked the UI a bit and got the complete data-table under a single table container. Since a complete rewrite in vue.Js will need an opinion from more users. Now I am trying to add a resizable feature to the current container and will keep you posted with the progress.

…

On Fri, 13 Mar, 2020, 07:26 Thad Guidry, ***@***.***> wrote: Myself and @wetneb <https://github.com/wetneb> are not exactly front-end wizards. So we are depending on folks like you, maybe your peers or others in your circle that do have that experience to set the right course forward. I think this is going to take a bit of experimentation to see what works best. Have you looked at how agGrid with Vue works? https://www.ag-grid.com/vuejs-grid/ or others? This might serve useful to your experiments. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1312 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKQMTLWUZADSP56G2GPIXK3RHGHEPANCNFSM4ECZYX5Q> .

[thadguidry]

@kushthedude great! looking forward to seeing your progress!

[kushthedude]

Since the following was to be solved with the migration to a new data-grid while looking at chances of Vue.js. I think the GSoC candidates may resolve it during the work at infinityScroll.

[lisa761]

I can take this up once infinite scrolling is implemented. However, for the gsoc project, there hasn't been any plans to migrate the table to a new data-grid library, as of now.

[ignaciomartin]

Can anyone report any progress on this much needed request?