Replies: 3 comments 26 replies
SlickGrid Quirks — Master-Branch TriagePurpose. Every "preserved quirk" the ViewportMgr refactor carries forward exists Method. Area-grouped investigators read master via How to read a row.
Fix-now priority (the actionable list)
Keep-as-is (deliberate): Q14, Q15, Q17, Q25, Q13-adjacent, Q6, Q26, Q32-baseline. Family A — Frozen-row boundary (Q1, Q3, Q20, Q29, Q33)These all concern the Q1 — Frozen-bottom grids never clean up row cells · genuine-bug · high · VERIFIEDThe cell-cleanup exemption in if (this.hasFrozenRows
&& ((this._options.frozenBottom && row > this.actualFrozenRow) // bottom
|| (row <= this.actualFrozenRow))) // top — MISSING !frozenBottom
{ return; }Its sibling
Q3 — Render-side vs lookup-side row-band threshold asymmetry · genuine-bug · highNot one asymmetry but six drifted comparison sites that disagree with each other and
Q20 —
|
|
what is FRC exactly? is that current freezing approach we currently have? too many acronyms... below is my main concern, if you make this calculation it's about 1400, let's remove 400 lines maybe for comments, we're still at 1000 loc. Why so much loc? Considering that the best approach would be to do it as a major version (breaking changes), we could reimplement the entire freezing implementation, I thought that I said Claude should do that, is that what it did? For example, if a better approach is to use something like 
again since we're going to put this on v6 and as breaking changes, there's no reason to do as "non-breaking" because again that increases loc a lot. I don't see any good reasons to keep legacy code (e.g.
yeah well let's do 1 step at a time ;) .. but yeah changing the Formatters signature would be a very big deal, at some I thought of changing to be 1 argument as an object which become easily extendable afterward, but it's so major and would impact pretty much every single user and there's no easy way to search & replace either, so I always avoided changing it. |
|
FRC = frozen rows and columns. I just can't be bothered typing it repeatedly! With your row count, note that LOC in slick.grid.ts has decreased by around 425 lines. That's what I was after - not the LOC decrease per se but the removal of all of the FRC logic throughtout the code. I think the core code will be a lot clearer. All the growth is in slick.core.ts, specifically in the ViewportMgr object, where is has to be to be non breaking, but if it were externalised to a new file (say slick.viewportmgr.ts), we could put a 'stub' file in core instead and maybe get an overall reduction. Then there is also the option of having different slick.viewportmgr.ts version - perhaps one with only 4 panes instead of 9 would be compariable in size to the current repo. Include the version you need. Again, this change is architectural and I think it gives us more options. Re the suggestion to do |
if we were to keep current 3 builds (IIFE=
I'm not sure what you mean by 9, that seems like way too many. I think the max we could or should ever support is 6 like this other lib (SynchFusion) https://ej2.syncfusion.com/demos/#/tailwind3/grid/pinned-rows.html unless you count 9 because of pre-header and footer? by the way, that other lib that I've referenced seems to be using sticky left/right columns since it only shows a single horizontal scrollbar at the bottom. Perhaps that might be cheaper approach in terms of loc!? I mean similar to the sticky approach you proposed couple weeks ago. |
|
different builds: sure, but it amounts to the same thing. The bundler just includes the file in the bundle rather than it being referenced in the web page. I do production bundling with IIFE anyway. at the moment the PR tracks 9 panes which is what you need for all 4 frozen options at once (left/right/top/bottom). One thing I like about the new code is that it only creates a single pane if you don't freeze a column. The HTML is all lazy-created. This puts it ahead of the current code - the LOC are bigger, but the HTML impact is a lot less if not using a specific freeze mode. The sticky grid is a great feature, but it would be a heavy footprint. I'm not sure if making it horizonal-only or vertical-only is a good idea though. |
|
Well again I'm not opposed to this change if we can find ways to decrease this currently large amount of line changes. I agree that the UI would be better, but I'm sure that we can find a much lighter approach and that is what I'm aiming for here. |
|
Also since you're starting to use more and more AI for the project, I think it would be a good idea to finally add real documentation to the project. Can you go on the GitBook website and register it with your GitHub login, I don't remember all the steps that I've done since it was couple years ago, but I think you can follow this link to get started by importing your current Wikis to get started: https://gitbook.com/docs/guides/editing-and-publishing-documentation/import-or-migrate-your-content-to-gitbook-with-git-sync#importing-from-github ideally you should get a link for the docs that should look like this: I pushed a commit c7b23dd that contains the initial structure for GitBook, so when you do the setup, it should hopefully detect and use that setup. Typically, it's simply to create a "docs" folder (which I did) in your project root and make that the GitBook location for all new docs (also when registering to GitBook, it's a good idea to convert existing Wikis to GitBook docs, that is the link I referenced in first paragraph above). When this is all in place, we would then have a markdown file for each table of content and then when you create future PR, you ask the AI to also/create docs for it (that is what I have been doing for a while now after starting to use copilot). oh if you can then try to add me in your GitBook "team members", so that I could help in configuring it and get it all working as expected. When everything is in place and working, we could also ask Claude to compare all my docs with your project and let it copy and rewrite docs according to your project setup... but don't do that part yet, just get started with the basic above would already be great. I also forgot to mention that this is all free for Open Source projects like ours and totally worth using |
|
@ghiscoding yep, have already started the process for documentation. I was heading in a different direction to what you have suggested, but I'll review the above and get back before I proceed. I was specifically wanting a reference secion with a synchronised contents pane, like at https://momentjs.com/docs/ (scroll down and watch the contents panel sync as you scroll). Claude recommeded VitePress for that. Here's the final section of the report, I won't post it in full yet since it's very large. 11. Decisions (locked) & remaining defaultsLocked (confirmed 2026‑07‑25):
Adopted defaults (reasonable unless you say otherwise): |
|
the main reason I tried GitBook was mainly because it supports migrating GitHub Wikis with couple clicks and mainly because we edit the docs via markdown files. But nowadays, there's probably many more apps or websites that support the same kind of things. Any apps would do, as long as we can easily add docs via PRs, it could be anything and yes I'm sure VitePress does support that as well (I just haven't tried that one but feel free to go with whatever works) It would be really good to have docs in place before adding more features without proper docs, it's especially important for new features since users don't know them yet and there's less references on the internet... so again just use whatever you feel like using, GitBook, VitePress, ... the tool name is not important 😉 |
|
OK have asked it to review Gitbook as an option, but it doesn't support a lot of the features I wanted. I'll open up a discussion shortly just for the documentation planning. I'm just doing some internal documentation for my proprietary framework and I want to wait until that's done so I can apply any lessons learned to this. |
|
I heard VitePress mentioned many times (especially by the Vite team), so I'm sure it's a great option. Feel free to go with it and we'll learn how it works, shouldn't be that different :) |
Uh oh!
There was an error while loading. Please reload this page.
Hey @ghiscoding, another general clean up resulting from the FRC rework.
Claude has mentioned that these 'quirks' are carried over in the code with special cases so as to be non breaking.
I think a number are bugs, and some are probably uses of the grid that were never anticipated or are on our radar, and some may be design decisions.
I'm going to post the resulting report after I asked it to give details about these quirks and classify them into the three categories.
I think the logical thing to do is to ask it to make a PR for each including a temporary repro file and a new cypress test. Just running this past you first, since it would be a lot of PRs!
All reactions