FIX: Remove ForceFit deprecation message, fixes #603

[6pac]

one line change, fixes this issue comment

[ghiscoding]

why not removing it completely?

[6pac]

Can if you like, but I do still view this as a work in progress. If the issues in #603 were fully resolved, then I think we could actually deprecate it. But autosizing continues to be a very long piece of string. Just when I think I've got it sorted, problems crop up again. As you have no doubt also seen, if you overlay complex formatters and editors, then this affects the sizing so it's hard to work out where to draw the line around what is the grid's responsilbility and what is the additional framework's.

Given all this, perhaps we should just decide to always keep this as a legacy option and never deprecate it? I kind of think the best way would be to move to a plugin model, for autosizing and filtering. I'm in the process of trying to work out the best architecture for this, but it takes time and some trial and error.

[ghiscoding]

well that piece of code is mostly all yours and the reality is that I don't use the project anymore, I help you maintain it but at this point I copied SlickGrid and pasted it in Slickgrid-Universal and use my own standalone copy of SlickGrid (I can keep it in sync with the one here though). I was able to do that only after the file was rewritten in TypeScript. The second part is that I also have my own cell resize by content service that I actually created before yours, so I never had the chance to try your code... all that to say, that piece of code is all yours, you decide how to approach it ;)

[6pac]

Hmmm, OK, didn't realise you have fully peeled off. Of course, I am also using a different branch, forked in about 2018, for my live projects.
Given they are both TS now, is there any easy way you can see of integrating this repo and Universal? Should we just deprecate this repo? Just concerned that this one will go stale if there's no long term incentive to keep it updated. I don't even use TS at this point, and the build tools are a mystery to me, so if you left, I'd be in a bit of a situation.

[ghiscoding]

hmm in my case, I have my Resizer Service which is a plugin and is totally disconnected from the core SlickGrid, it's like that because like I said I created it before you even created yours. Also what I've done in my case is that I only kept the autosizeColumns() that I use once on the grid load only, however it's deprecated in here so already it's different compare to my use case. What I've done is to keep what you call the legacy autosize with force fit and completely removed the new code you introduced for the resize by content, it wasn't too hard to remove since you kept them separate. So I use my own Resizer Service as a separate SlickGrid plugin, in my case it also resizes the grid, so it's the browser resize + resize by cell content (the user can choose to use it or not in my lib, if not then the autosizeColumns() is used only on grid load)

SlickGrid/src/plugins/slick.resizer.ts

Lines 60 to 63 in d1132c9

	* @class Slick.Plugins.Resizer
	*/
	export class SlickResizer {

I'm not sure that I want to spend more time on redoing this work in here though, that is the only difference between my repo and yours, everything else is the same and whenever a PR is created here (like we had for the past couple weeks), I replicate them as well in mine. It's already a lot of effort for me, I don't mind reviewing PRs by users and keep maintaining the lib but I'm not intending to do any large changes anymore since like I said I have my own copy now.

[6pac]

Sure. What I'm wondering is, is there any need for the 6pac repo any longer or should we just go with Universal?

I will be migrating my projects to TS when I get a chance, and will look closely at Universal then. Perhaps I just wait to make a decision until that happens.

[ghiscoding]

Sure. What I'm wondering is, is there any need for the 6pac repo any longer or should we just go with Universal?

Of course there is, the user is a lot bigger in here compare to mine, just take a look at the number of stars, it's increased quite a lot since we migrated to TypeScript but it barely moved on my side. The biggest difference between SlickGrid here and Slickgrid-Universal is that SlickGrid is like IKEA and you assemble it yourself but on the other hand Universal is all assembled. Some might prefer the all assembled but this comes with a cost mainly a build size cost, I use a couple of external libs for built-in Editors/Filters and so like I said Universal is bigger but all assembled. In comparison, SlickGrid is much smaller but you have to assemble it yourself, it's much smaller and much more versatile.

If we compare stars, you got 10 stars in about 2 weeks, I got 1 star in about 2 if not 3 months so there's a lot of interest in SlickGrid especially since the TypeScript rewrite and ES6/ESM builds. Take a look at this Star graph for comparison, you can SlickGrid is going up a lot recently but Angular-Slickgrid (the biggest of mine) remains flat, it proves the interest in SlickGrid https://seladb.github.io/StarTrack-js/#/preload?r=6pac,slickgrid&r=ghiscoding,angular-slickgrid

[6pac]

Perhaps what I need to do is migrate a lot of the pieces from Universal back to here. You're right about the IKEA analogy, we don't want it pre-built, but I'm wondering if we can offer more than we do, and possibly fill the use case for Universal at the same time.

Re the stats, true but all the links point here. If we put more emphasis on your repo you might get a lot more traffic. That is, the interest might be in Slickgrid in general, rather than this repo in particular, but this repo is first in line for that interest.

[ghiscoding]

Personally I think the project is good as it is today, the only problem might be this resize by content that comes up sometime but apart from that, I think most users are interested in SlickGrid the way it is. As for Slickgrid-Universal probably has enough reference as it is today, I've already added a ref when I wrote the Migration to v5 and I mention it in a few of the issues already. Also just type SlickGrid in Google and you'll get a lot more refs to my repos, I think the reason is because I have a ton of Wikis so my repos comes on top of the searches... so I don't think more emphasis is needed and it's probably ok the way it is today. ;)

Also, I think a lot of users are interested in SlickGrid because like I said it's much smaller and most users just want to use it for small grids without too many plugins, then SlickGrid is ideal. If on the other hand, some users want to use it at the enterprise level, like me, then Slickgrid-Universal offers more features, for example Tree Grid, Editors, Filters are much better in Universal and are all built-in stuff but again that comes at a cost (a bigger build size). A lot of projects just want to create small grids and so SlickGrid is ideal. However in my case and in the enterprise world, where build size isn't much of an issue, then Slickgrid-Universal has its place, so it's just a different set of users and I'm all ok with all of that.

in summary the 2 projects serves different group of people and I think it's totally fine and can and should coexists. The other good thing is that since I keep track of both projects, issues ang bug fixes are in synch on both projects, also the more users, the better to make them both as stable as possible.

cheers

[6pac]

OK then, I think we've thrashed those issue out ;-)

To get back to the original issue, I'll remove the notice in it entirety rather than commenting out

[ghiscoding]

okie dokie