(done) Vue support is arrived 🚀

[ghiscoding]

I'm currently working on creating another framework port to support VueJS, the package will be named Slickgrid-Vue and I have just opened a new PR #1753 for this package. The new port is supporting all 42 examples, even Row Detail, found in the other ports (Angular/Aurelia/React). There's still a few things to look into but it's coming along and will probably ship by next week or the week after (it will be under v0.x for some time).

Things to be aware that will eventually come to all other framework ports

• I'm creating a new /frameworks and /demos folders directly within Slickgrid-Universal and that is where the new Vue port will be merged into. Since this will be all hosted under the same repo, it should help for troubleshooting and especially maintenance (I will be able to use pnpm workspace: to get instant access to local code).
• Having all frameworks hosted under the same repo has a lot of advantages but also some challenges
  • Easier to maintain, but since I'm using the fixed version mode of Lerna-Lite, it would require to bump all frameworks (including Vue) to the same version (I'm planning to do these repos move/update of all repos to v9.x in next major around 2025, Q1-Q2)
    • perhaps I could use the independent mode of Lerna-Lite but I think it still makes sense to have everything on the same version and so my preference is towards keeping fixed version mode and align everything to v9 in next major
    • with this new approach, pushing a new release for every framework will actually be a single action in Slickgrid-Universal 🍬
  • Cypress will have to be installed separately in each framework folders (Vue, Angular, ...), I got it working for Vue in PR feat: create new Slickgrid-Vue package to support VueJS framework #1753 and it works pretty well, it's a separate CI workflow that gets added to the list of CI checks. In other words, the new PR includes 2 Cypress workflows (Vanilla and Vue E2E tests, which runs in parallel, awesome!!!). Since pnpm uses node_modules symlinks, having 2 Cypress installs doesn't increase install size (great)
  • pnpm install will be much longer to install though since it will include all frameworks (Angular, Aurelia, React, Vue) but it turns out that we could do targeted install via pnpm install --filter, so it could be interesting for the end user to only install the framework they want to troubleshoot of bring new features (this is only useful for Slickgrid-Universal development though, so that might not be an issue per say)
  • since all framework repos will be dropped, it also mean that I will lose access to GitHub Pages to host live website of all the examples. However, since I will keep all other demo repos (like Angular-Slickgrid-Demos), I could point the user to these live demos instead of current links.
  • finally the Documentation might be a challenge, but GitBook offers GitBook in Monorepo, so I'll have to give it a try and see (haven't tested that part yet)
  • the downside is that I will lose all the stars from the other repos, but that's ok, users will eventually upstar this one here I hope 😄 ⭐

@zewa666 do you have any projects with VueJS? I would also like to hear what you think about my possible move of all the framework ports (repos) into here, does that make any sense? Personally, I think it does, but I surely wouldn't want to overcomplicate things either. Feedback welcome

[zewa666]

while I'm not using Vue I know others who are and have to spread the good word.

putting the framework projects in the same repo though is the real gamechanger as it makes debugging and working off local branches for tryouts waaaaaay easier. plus I guess releases should be streamlined even more. really looking forward this

[ghiscoding]

lots of great stuff on the list, especially the rowspan feature which would be huge for our former excel users

yeah but don't put too much hope on that one, I've tried to look into it a bit and the external SlickGrid fork has tons of commits which makes it really hard to pinpoint the feature and follow the code change to even make it happen. There's a good chance that this one in particular, and maybe the PDF export, will just never come to fruition unfortunately.

prettier sneaking into the repo makes me happy :)

I've only enabled it for the Vue folders for now because enabling it for the entire projects will create a sh*t load of file changes and I'm not ready for that just yet. Probably later though 😆

I thought I was pretty much done with this project about 6 months ago when I released the previous major but for unknown I keep finding new things to had to this list and the project keeps rolling...lol 🚗

[zewa666]

the next work on my plate is to somewhat manage to display hierarchical data for inputs in the grid. so whipe grouping isnt feasible with a generic odata backend a tree with parent/child is. being able to rowspan repeated columns would be huge, but worst case I can manipualte the dataset to exclude duplicates and replace with empty values, so no biggy if not possible.

yeah yeah it starts with one and suddenly you reformat the whole project. looking forward to that monster chore commit 🤣

a grid is the basis of pretty much 80% of business software hence it evolves with the use cases. The combo with the gantt chart is what will up the game for me by a large amount as we're able to replace MS projects with that. also one more opportunity to contribute back a new plugin 🎉

[ghiscoding]

A wishful thinking would be to get @GerHobbelt help on the row span since it was his fork. He did star my repo so I'm assuming he's also following the project, any contributions on that feature would just be gold 😄

@zewa666 receiving more contributions for new features demos like Gantt is always welcome, a fix for the old issue you've opened would be nice too (another wishful thinking haha) 😉

Pretty soon this repo will be the one to rule them all 💍

[GerHobbelt]

Yeah, @GerHobbelt is still around, but very quietly lurking in the background while having moved to tinkering with C++ stuffs.

Anyway, rowspan and colspan were features which I stole from others, then spent time ironing out the bugs and twists and turns.

What made it real hard (and never completed in open source) was I wanted row and column pinning as well - ponder about some cells being spanned while in a pinned row or column: how to deal with scrolling the others!? 🤔🤐😰 Your head explodes and you realize you can't do what the others do for pinning (which is rather excel style corner freezing and not what I intended), which is turn 1 grid into 4 and pray the browser performance remains good enough. ... Anyway, that combo never saw the light of day as the PoC never worked well enough: I tried it with CSS render priority levels and is was crap.

What did work is cell spanning and IIRC that was accomplished by tracking a sparse(?) array of metadata which tells us how wide and high the current grid cell is - with some backtracking included to find the top left edge grid index "coordinate" for each cell alongside -- I'd have to RTFC if you want the precise details and reality check of what I'm writing from memory here.

If I had to do this again, I would probably try to see if using a bitarray as testindex would speed things up. Anyway.... Several parts of the then solution we're done as browsers didn't support much more, so I am inclined to say: see what works well today. Their wasm support etc hints to me that a slightly different approach might be faster for very large data grids in 2024AD. I don't know what that new thing will be so it's experimentation time again 🤔

If you wonder what I did myself and not steal from anywhere, then we'd be talking scroll speed for large grids and complex cell layouts: back then as would be now, but later, there comes a point in the UX where you, the user, scrolls or drags a scrollbar and the grid repaint on scroll event takes noticeable time, slowing you down so much you start to get irritated.
That's where and why I introduced partial grid update rendering, using a bit of a rough scheduler approach: any event that scrolls the grid and consequently moved the virtual grid so that a repaint much kill certain old cell div's and paint new cell div's, I changed the code from repainting the visible area (smart but way too slow now) to repainting only a small visible strip, so JS quickly relinquished control for receiving a next scroll/repaint event. IFf that event doesn't happen, my own zero wait timer event will kick in and the code will repaint another visible strip. Rinse&repeat until the visual area us repainted completely and you're done.
While this significantly speeds up user interactivity/response under load, you of course will observe artifacts in screen: white background where the yet-unpainted grid strips are. It's either that or getting slowed down while you zoom through your huge datagrid. User feedback is kinda meh due to the visible artifacts so it's only marginally better than full visible area repaint in regular slickgrid & others.
Meanwhile that had a huge impact in the same code space as where slickgrid dealt with row/colspan (obviously) so without this info I can imagine it's bloody hard to RTFC the final result: a cocktail if multiple interwoven concepts.

If you want to know more, please @ mention me as I saw this thanks to the mention and the right time, so the message got front page in my view. Sorry, but it's the way it is 😭

[ghiscoding]

@GerHobbelt thanks for the feedback, I know that the current freezing/pinning implementation isn't the most optimal, neither the most performant, way of doing it but it works even if not the most efficient (of course Ag-Grid is the best but they are a paid product, and quite expensive that is, so we can't compare against them). Browsers have improved a lot and previous approach that might not have worked but then could actually work today but again I'm not interested in spending few hundred hours in rewriting pinning, so the current pinning will have to do for the next few years.

The rowspan was the main thing that I eventually wanted to grab from your fork but even with the first commit, it probably won't be enough to implement it since the feature seemed to have been implemented over multiple commits and it rather hard to follow (in other words, a PR of the feature would have been easier to follow). A code diff compare would also be out of the question since we migrated to TypeScript code. My wishful thinking was to maybe get your help on replicating the feature in my project, but I know you're busy and this was created about 10 years ago and I barely remember what I've done last month, so 10 years ago is way out of my head... anyway, if you want to help, I'd be super happy to receive any contributions, if not that's fine too. I've added myself a lot of features in here and in SlickGrid over the years, so the project keeps rolling anyway :)

[ghiscoding]

@zewa666 another thing that I wanted to ask, I was planning to keep the same npm package names for all ports (angular-slickgrid, aurelia-slickgrid, ...), the other option I could do is to put everything under the @slickgrid-universal org, like @slickgrid-universal/angular, but I'm not sure this brings much benefit and users might be confused!? Because currently the package name equals the component name <angular-slickgrid>, so it probably makes sense to keep same pkg name, right?

[zewa666]

definitely keep the same package names as its way easier to find those when searching.

with regards to the open issue, not sure when I'll make that since we're investing in building a bridge from columndefinitions to something like ngx-formly. reason being is I need to render different grids as forms when editing a single row. e.g to reproduce a workflow that by filling out other forms will change the state of the current selected row.

@GerHobbelt good to see ya around 👋

[ghiscoding]

first Slickgrid-Vue version is available, I even managed to get Documentations working in the monorepo (great). For the live demos, I created the regular Slickgrid-Vue-Demos and that becomes my live demo for this new Slickgrid-Vue and I could also link it as the Stackblitz....

so all that to say, having all the frameworks directly in here is definitely going forward 🚀