New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: Frozen columns #26

Open
at88mph opened this Issue Feb 15, 2016 · 35 comments

Comments

Projects
None yet
@at88mph

at88mph commented Feb 15, 2016

I've been using this branch of SlickGrid for the past couple of years:
https://github.com/JLynch7/SlickGrid/tree/2.0-frozenRowsAndColumns

But I would like to keep the underlying SlickGrid up to date with yours. The idea is that one can set the first n columns to be frozen and would remain in place while scrolling. Perhaps more of a spreadsheet feature, but useful when selecting rows.

Many thanks for keeping this current.

@6pac

This comment has been minimized.

Show comment
Hide comment
@6pac

6pac Feb 16, 2016

Owner

It's always a challenge keeping things updated across multiple forks.
Hopefully my patches are fairly small and atomic, and will merge easily (that's the idea, anyway).
Let me know if there's anything I can help with. Also interested to see how you approach it (eg. a new fork for the merged version?)

That said, I'm cautious about 'officially' supporting the frozen column forks because that feature does seem to modify some of the core render code. There seem to be a few options for frozen column implementations out there. It would be good to identify one (if that's even possible!) that's stable and has a good range of features. I've called out in my Wiki for anyone to submit knowledge and experience of the different forks out there. Feel free to submit what you know.

Owner

6pac commented Feb 16, 2016

It's always a challenge keeping things updated across multiple forks.
Hopefully my patches are fairly small and atomic, and will merge easily (that's the idea, anyway).
Let me know if there's anything I can help with. Also interested to see how you approach it (eg. a new fork for the merged version?)

That said, I'm cautious about 'officially' supporting the frozen column forks because that feature does seem to modify some of the core render code. There seem to be a few options for frozen column implementations out there. It would be good to identify one (if that's even possible!) that's stable and has a good range of features. I've called out in my Wiki for anyone to submit knowledge and experience of the different forks out there. Feel free to submit what you know.

@fortesl

This comment has been minimized.

Show comment
Hide comment
@fortesl

fortesl Jul 12, 2016

So will frozen columns be implemented in the 6pac fork? I'm also using the JLynch7 fork for the frozen columns feature. Thank you

fortesl commented Jul 12, 2016

So will frozen columns be implemented in the 6pac fork? I'm also using the JLynch7 fork for the frozen columns feature. Thank you

@6pac

This comment has been minimized.

Show comment
Hide comment
@6pac

6pac Jul 18, 2016

Owner

I think officially, no. However, I'd be happy to be a part of taking a look at the fork to see how the differences between the two forks could be minimized. This would maximize the portability of future updates to my repo.

Owner

6pac commented Jul 18, 2016

I think officially, no. However, I'd be happy to be a part of taking a look at the fork to see how the differences between the two forks could be minimized. This would maximize the portability of future updates to my repo.

@CSTufts

This comment has been minimized.

Show comment
Hide comment
@CSTufts

CSTufts commented Oct 6, 2016

+1

@mpetkov

This comment has been minimized.

Show comment
Hide comment
@mpetkov

mpetkov Oct 28, 2016

I am also switching to the JLynch7 branch beacuse I need fixedColumns. It would be great to implemet that feature in this repo which is up to date.

mpetkov commented Oct 28, 2016

I am also switching to the JLynch7 branch beacuse I need fixedColumns. It would be great to implemet that feature in this repo which is up to date.

@6pac

This comment has been minimized.

Show comment
Hide comment
@6pac

6pac Oct 29, 2016

Owner

been on the 'to do' list for a while. i'm just too busy.
if anyone is keen to do the main parts of the merge, i'd be happy to test and troubleshoot to get it to standard. my main problem is actually disentangling out what the changes are for that feature.

Owner

6pac commented Oct 29, 2016

been on the 'to do' list for a while. i'm just too busy.
if anyone is keen to do the main parts of the merge, i'd be happy to test and troubleshoot to get it to standard. my main problem is actually disentangling out what the changes are for that feature.

@at88mph

This comment has been minimized.

Show comment
Hide comment
@at88mph

at88mph Oct 29, 2016

No kidding. I tried it once and the frozen code from that branch is interwoven quite nicely. Perhaps a new implementation is in order?

Thanks for the replies, Ben.

at88mph commented Oct 29, 2016

No kidding. I tried it once and the frozen code from that branch is interwoven quite nicely. Perhaps a new implementation is in order?

Thanks for the replies, Ben.

@6pac

This comment has been minimized.

Show comment
Hide comment
@6pac

6pac Oct 30, 2016

Owner

In some ways I'm thinking rather than try to integrate JLynch7's changes to my repo, it might be a lot easier to just fork JLynch7's repo and apply my changes to it.
Would also depend on at what point JLynch7 forked from MLeibman and how well it was kept up to date after that. Any intel on that, anyone?

Owner

6pac commented Oct 30, 2016

In some ways I'm thinking rather than try to integrate JLynch7's changes to my repo, it might be a lot easier to just fork JLynch7's repo and apply my changes to it.
Would also depend on at what point JLynch7 forked from MLeibman and how well it was kept up to date after that. Any intel on that, anyone?

@chhunchha

This comment has been minimized.

Show comment
Hide comment
@chhunchha

chhunchha Nov 30, 2017

No intel on that 6pac, but I have been using that fork for frozen column which is very critical feature for me. I worry that in future might have to switch to some other alternative as it is behind in jquery upgrade also.

chhunchha commented Nov 30, 2017

No intel on that 6pac, but I have been using that fork for frozen column which is very critical feature for me. I worry that in future might have to switch to some other alternative as it is behind in jquery upgrade also.

@6pac

This comment has been minimized.

Show comment
Hide comment
@6pac

6pac Nov 30, 2017

Owner

The sad fact is that SlickGrid needs months of work put into it to integrate a lot of the branched code, including the post-jQuery branch, etc. I will never have time to do that.

The only hope is if it is adopted by a project that is generating cash and considers it critical enough to put some effort into. I have a project that might fill that role, but too early to tell. I keep getting distracted by having to make a living!

Owner

6pac commented Nov 30, 2017

The sad fact is that SlickGrid needs months of work put into it to integrate a lot of the branched code, including the post-jQuery branch, etc. I will never have time to do that.

The only hope is if it is adopted by a project that is generating cash and considers it critical enough to put some effort into. I have a project that might fill that role, but too early to tell. I keep getting distracted by having to make a living!

@karmis

This comment has been minimized.

Show comment
Hide comment
@karmis

karmis Dec 6, 2017

@6pac its very sad =( ; Frozen columns is very necessary feature;
+1 for it

karmis commented Dec 6, 2017

@6pac its very sad =( ; Frozen columns is very necessary feature;
+1 for it

@6pac

This comment has been minimized.

Show comment
Hide comment
@6pac

6pac Dec 11, 2017

Owner

OK, so I was on a long plane flight, and downloaded the JLynch repo before I left. I have found that the changes are not really that extensive, although they do complicate the rendering code a lot. Also, the Jlynch branch has not been maintained for about 4 years.

Using WinMerge (an awesome tool) I have been able to reformat the my current and the JLynch slick.grid.js to highlight the differences. It's probably only a day's work to go through and copy the relevant bits over.

slick-jlynch-compare

Is anyone interested in helping with this task?

It's also worth a conversation about exactly what frozen columns means.

Owner

6pac commented Dec 11, 2017

OK, so I was on a long plane flight, and downloaded the JLynch repo before I left. I have found that the changes are not really that extensive, although they do complicate the rendering code a lot. Also, the Jlynch branch has not been maintained for about 4 years.

Using WinMerge (an awesome tool) I have been able to reformat the my current and the JLynch slick.grid.js to highlight the differences. It's probably only a day's work to go through and copy the relevant bits over.

slick-jlynch-compare

Is anyone interested in helping with this task?

It's also worth a conversation about exactly what frozen columns means.

@6pac 6pac referenced this issue Dec 12, 2017

Closed

Lock the columns #1174

@at88mph

This comment has been minimized.

Show comment
Hide comment
@at88mph

at88mph Dec 18, 2017

The JLynch design as I understood it was to create two separate, scrollable viewports, where the viewport on the left represented the n number of columns to lock. We could just port over the code from JLynch, but what if there were a better way to do it now? It could warrant some investigation, especially since much of the code is in conflict with the current @6pac master.

As for what's expected from it, I see it working like this animation. The identifier or row selection mechanism is in the first column typically, unless someone has a different use case, so optionally locking the first column would be sufficient, I think.

Thoughts?

at88mph commented Dec 18, 2017

The JLynch design as I understood it was to create two separate, scrollable viewports, where the viewport on the left represented the n number of columns to lock. We could just port over the code from JLynch, but what if there were a better way to do it now? It could warrant some investigation, especially since much of the code is in conflict with the current @6pac master.

As for what's expected from it, I see it working like this animation. The identifier or row selection mechanism is in the first column typically, unless someone has a different use case, so optionally locking the first column would be sufficient, I think.

Thoughts?

@ghiscoding

This comment has been minimized.

Show comment
Hide comment
@ghiscoding

ghiscoding Dec 18, 2017

Collaborator

I would say that the locking of first column is a good start, but in some cases I also like to use the last column frozen as well (for example I would put the edit icon in 1st column but the delete icon in last column, so that they never interfere with each other).

EDIT
I was using UI-Grid with AngularJS and they have a demo that you can take a look at. They call it Pinning instead of column freeze but it's the same concept. They allow to pin any number of columns at the beginning (1 or more) and at the end (1 or more) but never in the middle because it's way too complex and there's no usage for that anyway. So take a look at their demo

Collaborator

ghiscoding commented Dec 18, 2017

I would say that the locking of first column is a good start, but in some cases I also like to use the last column frozen as well (for example I would put the edit icon in 1st column but the delete icon in last column, so that they never interfere with each other).

EDIT
I was using UI-Grid with AngularJS and they have a demo that you can take a look at. They call it Pinning instead of column freeze but it's the same concept. They allow to pin any number of columns at the beginning (1 or more) and at the end (1 or more) but never in the middle because it's way too complex and there's no usage for that anyway. So take a look at their demo

@6pac

This comment has been minimized.

Show comment
Hide comment
@6pac

6pac Dec 19, 2017

Owner

Well, making three viewports would be not much more difficult than two!
I was thinking it might be a good idea to use if statements to keep the current single-viewport code as-is and just use the multi-viewport sections for when the feature is switched on.
While it would duplicate code, it's often useful to have the simpler version available as an easy-to-understand template, and then just mirror any changes to the more complex version. It's a tricky line to tread.

In this case, I think the additional advantage of the much simpler HTML, leading to presumably significantly less work for javascript and the browser, makes this approach compelling.

Owner

6pac commented Dec 19, 2017

Well, making three viewports would be not much more difficult than two!
I was thinking it might be a good idea to use if statements to keep the current single-viewport code as-is and just use the multi-viewport sections for when the feature is switched on.
While it would duplicate code, it's often useful to have the simpler version available as an easy-to-understand template, and then just mirror any changes to the more complex version. It's a tricky line to tread.

In this case, I think the additional advantage of the much simpler HTML, leading to presumably significantly less work for javascript and the browser, makes this approach compelling.

@6pac

This comment has been minimized.

Show comment
Hide comment
@6pac

6pac Dec 19, 2017

Owner

Had a look for recent HTML/CSS solutions to this problem, drew a blank :-(

Owner

6pac commented Dec 19, 2017

Had a look for recent HTML/CSS solutions to this problem, drew a blank :-(

@ghiscoding

This comment has been minimized.

Show comment
Hide comment
@ghiscoding

ghiscoding Dec 19, 2017

Collaborator

If I look at the UI-Grid, it looks like concept wise it's actually 3 viewports (left, center, right) which are set with an overflow horizontal (no vertical). These 3 viewports are inside a bigger container which has an overflow vertical so that it controls the 3 viewports while scrolling up/down. You can pin 1 or more column inside each viewport (with this pinnedLeft: true, which you can apply to multiple columns of the left and the same goes for pinnedRight:true).

They also seem to calculate margin left and right to center the middle viewport. I guess we could do it too since we know the width of each columns. Consider that your full container has 1000px wide, and you pinned 2 on the left and none on the right and that your columns are 100px wide, that you mean that the middle viewport has a margin-left: 200px and margin-right: 0px. That part is done with jQuery.

That is just what I seem to understand from the UI-Grid html code, is that even doable with SlickGrid, I seriously don't know but it's a start.

Collaborator

ghiscoding commented Dec 19, 2017

If I look at the UI-Grid, it looks like concept wise it's actually 3 viewports (left, center, right) which are set with an overflow horizontal (no vertical). These 3 viewports are inside a bigger container which has an overflow vertical so that it controls the 3 viewports while scrolling up/down. You can pin 1 or more column inside each viewport (with this pinnedLeft: true, which you can apply to multiple columns of the left and the same goes for pinnedRight:true).

They also seem to calculate margin left and right to center the middle viewport. I guess we could do it too since we know the width of each columns. Consider that your full container has 1000px wide, and you pinned 2 on the left and none on the right and that your columns are 100px wide, that you mean that the middle viewport has a margin-left: 200px and margin-right: 0px. That part is done with jQuery.

That is just what I seem to understand from the UI-Grid html code, is that even doable with SlickGrid, I seriously don't know but it's a start.

@kjn2

This comment has been minimized.

Show comment
Hide comment
@kjn2

kjn2 Mar 16, 2018

Hi, I am not a coding expert, but from what I learned about slickgrid, my 5cents of input would be to not compromise the performance of this branch by solving the problem in html/css vs. the underlying canvas technology. We're planning on using slickgrid primarily because of it's awesome performance and memory footprint. Let's not compromise that just to get a feature implemented quick&dirty so to speak... and again, not implying anybody is trying to do that, only 'product development' feedback.

Somebody was asking for some help in coding... I possibly have someone who could help out a bit. Clearly, the person needs some intro and guidance, but is familiar with Canvas and js and others.

kjn2 commented Mar 16, 2018

Hi, I am not a coding expert, but from what I learned about slickgrid, my 5cents of input would be to not compromise the performance of this branch by solving the problem in html/css vs. the underlying canvas technology. We're planning on using slickgrid primarily because of it's awesome performance and memory footprint. Let's not compromise that just to get a feature implemented quick&dirty so to speak... and again, not implying anybody is trying to do that, only 'product development' feedback.

Somebody was asking for some help in coding... I possibly have someone who could help out a bit. Clearly, the person needs some intro and guidance, but is familiar with Canvas and js and others.

@6pac

This comment has been minimized.

Show comment
Hide comment
@6pac

6pac Mar 17, 2018

Owner

Yep, thanks, @kjn2. The pinned column functionality is ready to be integrated, and in this case I don't think there even is a 'quick and dirty' option. We just don't have anyone at present who has the 10 hours or so required to transfer the feature from the (quite outdated) @jlynch repository to this one. I don't think it would be too hard, with the right tools, but it's just a time issue.

Owner

6pac commented Mar 17, 2018

Yep, thanks, @kjn2. The pinned column functionality is ready to be integrated, and in this case I don't think there even is a 'quick and dirty' option. We just don't have anyone at present who has the 10 hours or so required to transfer the feature from the (quite outdated) @jlynch repository to this one. I don't think it would be too hard, with the right tools, but it's just a time issue.

@kjn2

This comment has been minimized.

Show comment
Hide comment
@kjn2

kjn2 Mar 17, 2018

kjn2 commented Mar 17, 2018

@atifsyedali

This comment has been minimized.

Show comment
Hide comment
@atifsyedali

atifsyedali Apr 5, 2018

@6pac Any updates? Would love to have the pinned column feature, even if it is only for one leftmost column.

There was some discussion earlier about how the pinned column should interact in the presence of row grouping. Have you seen airtable.com? It basically combines the row grouping portion with the pinned column viewport.

image

You can also make ag-grid behave somewhat similarly. For example, try the following with their demo: https://www.ag-grid.com/example.php

image

atifsyedali commented Apr 5, 2018

@6pac Any updates? Would love to have the pinned column feature, even if it is only for one leftmost column.

There was some discussion earlier about how the pinned column should interact in the presence of row grouping. Have you seen airtable.com? It basically combines the row grouping portion with the pinned column viewport.

image

You can also make ag-grid behave somewhat similarly. For example, try the following with their demo: https://www.ag-grid.com/example.php

image

@Steve192

This comment has been minimized.

Show comment
Hide comment
@Steve192

Steve192 Apr 20, 2018

I am also very intrested in this frozen columns feature. I am in a project where we need to render huge tables with the functionality of fixed columns (~ 1000 lines and ~1000 columns ). SlickGrid is one of the only frameworks we could use, that have the performance to render that many data without lagging and still have a lot a features for a nice display of data. So I can invest some time in the project.

Sadly I am not a very experienced javascript developer regarding rendering, canvas and such and have no overview of the internals of slick grid. Do you think I can help you anyway ?

By the way, JLynchs implementation still has a bug:
If you scroll all the way to the right and scroll down a bit, the content of the fixed columns is not rendered anymore, even though they are visible.

Steve192 commented Apr 20, 2018

I am also very intrested in this frozen columns feature. I am in a project where we need to render huge tables with the functionality of fixed columns (~ 1000 lines and ~1000 columns ). SlickGrid is one of the only frameworks we could use, that have the performance to render that many data without lagging and still have a lot a features for a nice display of data. So I can invest some time in the project.

Sadly I am not a very experienced javascript developer regarding rendering, canvas and such and have no overview of the internals of slick grid. Do you think I can help you anyway ?

By the way, JLynchs implementation still has a bug:
If you scroll all the way to the right and scroll down a bit, the content of the fixed columns is not rendered anymore, even though they are visible.

@chhunchha

This comment has been minimized.

Show comment
Hide comment
@chhunchha

chhunchha Apr 20, 2018

@Steve192 I forked JLynchs - 2.0-frozenRowsAndColumns branch and did some bug fixes and it works perfectly. Wasn't that hard. Let me know if I can help anyway

chhunchha commented Apr 20, 2018

@Steve192 I forked JLynchs - 2.0-frozenRowsAndColumns branch and did some bug fixes and it works perfectly. Wasn't that hard. Let me know if I can help anyway

@bellma-lilly

This comment has been minimized.

Show comment
Hide comment
@bellma-lilly

bellma-lilly Apr 24, 2018

@Steve192 @chhunchha I think you are referring to JLynch7#56
I have a bug fix for this and some other issues as well, should JLynch's code be integrated here.

bellma-lilly commented Apr 24, 2018

@Steve192 @chhunchha I think you are referring to JLynch7#56
I have a bug fix for this and some other issues as well, should JLynch's code be integrated here.

@6pac

This comment has been minimized.

Show comment
Hide comment
@6pac

6pac Apr 25, 2018

Owner

OK, so the kind of changes I'm thinking of are:

  1. start with the JLynch repo and the modified current slickgrid (from which I've removed all the changes not relevant to the pinned columns feature)

  2. Add additional variables for the extra viewports etc. A sample from JLynch:

     var $headerScrollerL;
     var $headerScrollerR;
     var $headerL;
     var $headerR;
    
     var $viewportTopL;
     var $viewportTopR;
     var $viewportBottomL;
     var $viewportBottomR;
    
     var $canvasTopL;
     var $canvasTopR;
     var $canvasBottomL;
     var $canvasBottomR;
    

I would leave the original object and name the extras accordingly, eg. $viewport, $viewportR, $viewportL Note JLynch has four objects because he supports top row and left side column splitting. If we were to support left and right sided column and top and bottom row splitting, we would need nine!

  1. Go through the code diff between the two files (see screenshot above), keeping the existing code but adding the new code, eg:

     if (pinnedFeatureIsActive) {
       //existing code
     } else {
       // JLynch code
     }
    

This has the following advantages:

  • it would allow the original code to be kept stable
  • it would mean any performance issues introduced by the more complex rendering would be able to be limited only to the cases where it is used
  • it would also preserve it as a simpler example of the core render code free of the pinned feature complications.

There have been some good offers, particularly from @kjn2.
The thing that worries me is that this is a bit like brain surgery. It's straightforward enough if you can copy and paste from one side to the other while understanding and investigating the implications of each decision. But if you can't walk that tightrope, it's possible that the end code might take more time to fix than to start again.
I don't think it's necessary to have great familiarity with the code, but it would be necessary to have an advanced understanding of javascript.

As I have said, I personally don't need this feature and can't justify the time to do it right now. Especially given that it will probably lead to further complications, as illustrated by @atifsyedali

Owner

6pac commented Apr 25, 2018

OK, so the kind of changes I'm thinking of are:

  1. start with the JLynch repo and the modified current slickgrid (from which I've removed all the changes not relevant to the pinned columns feature)

  2. Add additional variables for the extra viewports etc. A sample from JLynch:

     var $headerScrollerL;
     var $headerScrollerR;
     var $headerL;
     var $headerR;
    
     var $viewportTopL;
     var $viewportTopR;
     var $viewportBottomL;
     var $viewportBottomR;
    
     var $canvasTopL;
     var $canvasTopR;
     var $canvasBottomL;
     var $canvasBottomR;
    

I would leave the original object and name the extras accordingly, eg. $viewport, $viewportR, $viewportL Note JLynch has four objects because he supports top row and left side column splitting. If we were to support left and right sided column and top and bottom row splitting, we would need nine!

  1. Go through the code diff between the two files (see screenshot above), keeping the existing code but adding the new code, eg:

     if (pinnedFeatureIsActive) {
       //existing code
     } else {
       // JLynch code
     }
    

This has the following advantages:

  • it would allow the original code to be kept stable
  • it would mean any performance issues introduced by the more complex rendering would be able to be limited only to the cases where it is used
  • it would also preserve it as a simpler example of the core render code free of the pinned feature complications.

There have been some good offers, particularly from @kjn2.
The thing that worries me is that this is a bit like brain surgery. It's straightforward enough if you can copy and paste from one side to the other while understanding and investigating the implications of each decision. But if you can't walk that tightrope, it's possible that the end code might take more time to fix than to start again.
I don't think it's necessary to have great familiarity with the code, but it would be necessary to have an advanced understanding of javascript.

As I have said, I personally don't need this feature and can't justify the time to do it right now. Especially given that it will probably lead to further complications, as illustrated by @atifsyedali

@ghiscoding

This comment has been minimized.

Show comment
Hide comment
@ghiscoding

ghiscoding May 15, 2018

Collaborator

Alright everyone, I decided to take the 10 hours needed and I use a tool to compare (ExamDiff), it was painful and there's a LOT of code change. There will be also a lot to review and possibly some changes here and there... However I'm happy to say that... it works!!!

The source I used X-Slickgrid
The branch you can test it all out is feature/frozen-grid

Why X-Slickgrid and not JLynch/frozenGrid? From my understanding X-Slickgrid was a fork of JLynch - frozenRowsAndColumns and is more recent (last commit 2016 vs 2013), which is why I based myself on X-Slickgrid.

instructions / notes

  • you can test all the files that start with the filenames "example-frozen", there's 7 in total
  • I'm not sure if it works with jQuery 3.x, I updated all the examples to use the same version as the current slickgrid, which is jquery-1.11.2.min.js (same goes for jQuery UI)
    • it might fail with jQuery 3.x, I see there's a few jQuery call that are different and they will have to be reviewed. There's a lot of DOM element call with elm[0] instead of elm in current SlickGrid version, is that related to jQuery 3.x? I don't know, maybe... if you know please shed some light
  • feedback are welcome, however I am not the author of the code per say. I have done my best to merge (over 2 days) as much as possible but someone (most probably a few peoples) will have to review it all out

Final Note

  • The X-Slickgrid is not only column freeze, it also support row freeze. You can see the multiple examples provided
    • column freeze seems to always start from the left but row freeze is more flexible
  • Please don't ask when that will be merged to master. If you want to make it happen, then please provide feedback, test it out and help us make it happen.
  • There is a possibility that it will never get merged... hopefully not but I'm saying this because it's probably the biggest PR touching the core grid.js file in current SlickGrid fork.
  • This is the last biggest feature requested in this fork, let's make it happen!

You're welcome ;)

Collaborator

ghiscoding commented May 15, 2018

Alright everyone, I decided to take the 10 hours needed and I use a tool to compare (ExamDiff), it was painful and there's a LOT of code change. There will be also a lot to review and possibly some changes here and there... However I'm happy to say that... it works!!!

The source I used X-Slickgrid
The branch you can test it all out is feature/frozen-grid

Why X-Slickgrid and not JLynch/frozenGrid? From my understanding X-Slickgrid was a fork of JLynch - frozenRowsAndColumns and is more recent (last commit 2016 vs 2013), which is why I based myself on X-Slickgrid.

instructions / notes

  • you can test all the files that start with the filenames "example-frozen", there's 7 in total
  • I'm not sure if it works with jQuery 3.x, I updated all the examples to use the same version as the current slickgrid, which is jquery-1.11.2.min.js (same goes for jQuery UI)
    • it might fail with jQuery 3.x, I see there's a few jQuery call that are different and they will have to be reviewed. There's a lot of DOM element call with elm[0] instead of elm in current SlickGrid version, is that related to jQuery 3.x? I don't know, maybe... if you know please shed some light
  • feedback are welcome, however I am not the author of the code per say. I have done my best to merge (over 2 days) as much as possible but someone (most probably a few peoples) will have to review it all out

Final Note

  • The X-Slickgrid is not only column freeze, it also support row freeze. You can see the multiple examples provided
    • column freeze seems to always start from the left but row freeze is more flexible
  • Please don't ask when that will be merged to master. If you want to make it happen, then please provide feedback, test it out and help us make it happen.
  • There is a possibility that it will never get merged... hopefully not but I'm saying this because it's probably the biggest PR touching the core grid.js file in current SlickGrid fork.
  • This is the last biggest feature requested in this fork, let's make it happen!

You're welcome ;)

@6pac

This comment has been minimized.

Show comment
Hide comment
@6pac

6pac May 15, 2018

Owner

This is awesome! I'll check it out on the weekend.
I'll do everything I can to commit this to the main repo, but you are correct, it may take a little while.

Owner

6pac commented May 15, 2018

This is awesome! I'll check it out on the weekend.
I'll do everything I can to commit this to the main repo, but you are correct, it may take a little while.

@ghiscoding

This comment has been minimized.

Show comment
Hide comment
@ghiscoding

ghiscoding May 15, 2018

Collaborator

To do the review, I strongly suggest to use a diff tool, I just found this tool MeId and I wish I had it when I started, this tool also highlight addition not just the entire line change (my previous one was highlight the entire line). It seems WinMerge (previously known as WinDiff I think) also does addition/removal highlight which is great.

I will do a second review myself, because there's a lot of code that was replaced through this process and looking at it with this new tool, I can see right away that I forgot some variables (see screenshot)
var $preHeaderPanel, $preHeaderPanelScroller, $preHeaderPanelSpacer;

I didn't see this with my previous tool and I wish I had search for such tool prior.

grid_diff

@6pac
Question for you, I can see that the $preHeaderPanel was something added only in your fork, is that taking the entire width on the top or should also be separated Left/Right like all the other variables for the frozen grid? I mean if it takes the entire width at all time, it won't be split by a frozen grid, then I will leave your code as is. I would prefer that actually, that would be 1 less thing to think about, I don't think the pre-header would split but you can confirm.

Collaborator

ghiscoding commented May 15, 2018

To do the review, I strongly suggest to use a diff tool, I just found this tool MeId and I wish I had it when I started, this tool also highlight addition not just the entire line change (my previous one was highlight the entire line). It seems WinMerge (previously known as WinDiff I think) also does addition/removal highlight which is great.

I will do a second review myself, because there's a lot of code that was replaced through this process and looking at it with this new tool, I can see right away that I forgot some variables (see screenshot)
var $preHeaderPanel, $preHeaderPanelScroller, $preHeaderPanelSpacer;

I didn't see this with my previous tool and I wish I had search for such tool prior.

grid_diff

@6pac
Question for you, I can see that the $preHeaderPanel was something added only in your fork, is that taking the entire width on the top or should also be separated Left/Right like all the other variables for the frozen grid? I mean if it takes the entire width at all time, it won't be split by a frozen grid, then I will leave your code as is. I would prefer that actually, that would be 1 less thing to think about, I don't think the pre-header would split but you can confirm.

@6pac

This comment has been minimized.

Show comment
Hide comment
@6pac

6pac May 15, 2018

Owner

I think the $preHeaderPanel should be left alone. One other thing is worth mentioning: the if/then construct. I did give a pretty detailed strategy a few posts up. This was designed so that no core code actually changed except in an if statement.

if (pinnedFeatureIsActive) {
   //existing code
 } else {
   // JLynch code
 }

I know it violates DRY, and could potentially be regarded as a mistake but I think it (a) keeps core code stable (b) possibly makes the grid faster when splitting is NOT used (c) means we have a copy of the 'simple' code to debug basic issues on, which can then be propagated to the more complex case once solved.

Of course this doesn't apply to var declarations and infrastructure, just the active code.

Excuse me if you've done this, I haven't looked yet!

Owner

6pac commented May 15, 2018

I think the $preHeaderPanel should be left alone. One other thing is worth mentioning: the if/then construct. I did give a pretty detailed strategy a few posts up. This was designed so that no core code actually changed except in an if statement.

if (pinnedFeatureIsActive) {
   //existing code
 } else {
   // JLynch code
 }

I know it violates DRY, and could potentially be regarded as a mistake but I think it (a) keeps core code stable (b) possibly makes the grid faster when splitting is NOT used (c) means we have a copy of the 'simple' code to debug basic issues on, which can then be propagated to the more complex case once solved.

Of course this doesn't apply to var declarations and infrastructure, just the active code.

Excuse me if you've done this, I haven't looked yet!

@ghiscoding

This comment has been minimized.

Show comment
Hide comment
@ghiscoding

ghiscoding May 15, 2018

Collaborator

I just tried it with my Angular-Slickgrid which uses jQuery 3.x and it all works, except for 1 grid that uses the pre-header, which might be because of the missing variables that I wrote in my previous post.

Also worth to know, my start was not from your code but instead from the X-Slickgrid code because there was way too many to copy in your grid.js. So I took X-SlickGrid file of grid.js and started copying your grid.js into the X-SlickGrid one.

@6pac
I think the best is if you go directly in the branch and you make any changes directly in there, Using the diff tool is ideal. I can then pull latest code and review it after. I will do another review before the end of the week.

Also just so you know, I did not think about the logic, I really tried to merge and re-use your code as much as possible but at some point it was too complicate and I used the X-Slickgrid code instead. I know that some of your logic got replaced, which is why we need to review and put back some of your logic in there

and we cannot keep some of your code, like viewport for example is now split in 2, viewportL and viewportR. I don't think we have a choice there, if you want to do it like you said, the code will grow exponentially.

EDIT
Some observations of what is not behaving correctly

  • Works with jQuery 3.x
    • tested it with Angular-SlickGrid and apart from the other issues shown below, it mostly works
  • Frozen Grids
    • Frozen Columns
    • Frozen Columns and Rows (with HeaderRow Filter)
    • Frozen Rows Columns Spreadsheet
    • Frozen Rows AutoHeight
    • Frozen Rows Column Tabs (jQuery-UI Tabs)
    • Frozen Rows Reordering
  • Pre-Header is not showing up correctly
  • Editors when clicked are not showing at the correct x/y location
  • Multiple Column Sort / Tristate
  • Header Menu Plugin
  • Header Button Plugin
  • Grouping
  • Grouping with Checkbox
  • Draggable Grouping
  • Grid Menu (hamburger) is not working, clicking on it doesn't do anything
  • Edit with Undo, (editing cell value is not kept after clicking away)
  • jQuery Accordion (doesn't hide when changing tab)
  • Select2 dropdown editor (width of editor is not resized to width of cell)
Collaborator

ghiscoding commented May 15, 2018

I just tried it with my Angular-Slickgrid which uses jQuery 3.x and it all works, except for 1 grid that uses the pre-header, which might be because of the missing variables that I wrote in my previous post.

Also worth to know, my start was not from your code but instead from the X-Slickgrid code because there was way too many to copy in your grid.js. So I took X-SlickGrid file of grid.js and started copying your grid.js into the X-SlickGrid one.

@6pac
I think the best is if you go directly in the branch and you make any changes directly in there, Using the diff tool is ideal. I can then pull latest code and review it after. I will do another review before the end of the week.

Also just so you know, I did not think about the logic, I really tried to merge and re-use your code as much as possible but at some point it was too complicate and I used the X-Slickgrid code instead. I know that some of your logic got replaced, which is why we need to review and put back some of your logic in there

and we cannot keep some of your code, like viewport for example is now split in 2, viewportL and viewportR. I don't think we have a choice there, if you want to do it like you said, the code will grow exponentially.

EDIT
Some observations of what is not behaving correctly

  • Works with jQuery 3.x
    • tested it with Angular-SlickGrid and apart from the other issues shown below, it mostly works
  • Frozen Grids
    • Frozen Columns
    • Frozen Columns and Rows (with HeaderRow Filter)
    • Frozen Rows Columns Spreadsheet
    • Frozen Rows AutoHeight
    • Frozen Rows Column Tabs (jQuery-UI Tabs)
    • Frozen Rows Reordering
  • Pre-Header is not showing up correctly
  • Editors when clicked are not showing at the correct x/y location
  • Multiple Column Sort / Tristate
  • Header Menu Plugin
  • Header Button Plugin
  • Grouping
  • Grouping with Checkbox
  • Draggable Grouping
  • Grid Menu (hamburger) is not working, clicking on it doesn't do anything
  • Edit with Undo, (editing cell value is not kept after clicking away)
  • jQuery Accordion (doesn't hide when changing tab)
  • Select2 dropdown editor (width of editor is not resized to width of cell)
@kahluagenie

This comment has been minimized.

Show comment
Hide comment
@kahluagenie

kahluagenie Jun 28, 2018

This would be so cool to have! I inherited a project that is using JLynch's 2.0-frozenRowsAndColumns branch. Would love to get it on this fork instead!

kahluagenie commented Jun 28, 2018

This would be so cool to have! I inherited a project that is using JLynch's 2.0-frozenRowsAndColumns branch. Would love to get it on this fork instead!

@ghiscoding

This comment has been minimized.

Show comment
Hide comment
@ghiscoding

ghiscoding Jun 28, 2018

Collaborator

I have put a lot of work on this branch and mentioned what is working and not working in previous post. But nobody wanted to help neither provide feedback, so it's kind of paused right now.

Collaborator

ghiscoding commented Jun 28, 2018

I have put a lot of work on this branch and mentioned what is working and not working in previous post. But nobody wanted to help neither provide feedback, so it's kind of paused right now.

@6pac

This comment has been minimized.

Show comment
Hide comment
@6pac

6pac Jun 29, 2018

Owner

Yeah, sorry I haven't been able to be more help. I'm too busy to do anything until at least September. crunch time in two big projects.
I've gotta say, we headed in slightly different directions on this one. It'll take a bit to get my head around it.

Owner

6pac commented Jun 29, 2018

Yeah, sorry I haven't been able to be more help. I'm too busy to do anything until at least September. crunch time in two big projects.
I've gotta say, we headed in slightly different directions on this one. It'll take a bit to get my head around it.

@psvoboda76

This comment has been minimized.

Show comment
Hide comment
@psvoboda76

psvoboda76 Aug 5, 2018

Hi,

I can see a lot of work has been done to provide a frozen columns/row feature. I think the feature would be really good to have. I am willing to help, just let me know how I can. I can either help to review or write the code, do the testing. Also, I can help a bit financially if it would help?

Thanks for the feedback and have a nice day

Petr

psvoboda76 commented Aug 5, 2018

Hi,

I can see a lot of work has been done to provide a frozen columns/row feature. I think the feature would be really good to have. I am willing to help, just let me know how I can. I can either help to review or write the code, do the testing. Also, I can help a bit financially if it would help?

Thanks for the feedback and have a nice day

Petr

@ghiscoding

This comment has been minimized.

Show comment
Hide comment
@ghiscoding

ghiscoding Aug 5, 2018

Collaborator

@psvoboda76
I wrote in earlier comments that I started the work on a different branch

The branch you can test it all out is feature/frozen-grid

So if you download the fork with Git and change branch to that mentioned branch, you'll get the code. There's a big portion already working, and there's also a small list of things that aren't working as expected, you can see the list also in earlier comment

Collaborator

ghiscoding commented Aug 5, 2018

@psvoboda76
I wrote in earlier comments that I started the work on a different branch

The branch you can test it all out is feature/frozen-grid

So if you download the fork with Git and change branch to that mentioned branch, you'll get the code. There's a big portion already working, and there's also a small list of things that aren't working as expected, you can see the list also in earlier comment

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment