Fullrow editing and accept/discard buttons

[zewa666]

hey there, AgGrid has a quite interesting feature called Fullrow Editing, see this example https://blog.ag-grid.com/full-row-editing-ag-grid-committing-changes-button-click/

I wonder if we can do something like that with slickgrid universal?

[ghiscoding]

Not possible in SlickGrid since only a single Editor can be open at a single time in the grid, that's why I created the optional Composite Editor feature

[ghiscoding]

you can reuse an example if you want and if it's not already too heavy on the Cypress tests side.

Why do you want to access the GridService for? The plugins are typically kinda of standalone and typically only use the grid/dataview objects (through init()), I created the GridService as a helper when I was tired of repeating the same code for CRUD stuff and then expended it over the years. So you might remember that it's not a true DI Container, all the services passed to the constructor are passed in the slick-vanilla-grid-bundle.ts where each of them are being instantiated but a very important note is that because it's not a true DI, the order they are instantiated really matter (same goes for Angular-Slickgrid). As for the ContainerService it's only used for optional package, it's never used within the common package.

slickgrid-universal/packages/vanilla-bundle/src/components/slick-vanilla-grid-bundle.ts

Lines 345 to 357 in 21d1489

	this.extensionService = services?.extensionService ?? new ExtensionService(
	this.extensionUtility,
	this.filterService,
	this._eventPubSubService,
	this.sharedService,
	this.sortService,
	this.treeDataService,
	this.translaterService,
	);
	this.gridStateService = services?.gridStateService ?? new GridStateService(this.extensionService, this.filterService, this._eventPubSubService, this.sharedService, this.sortService, this.treeDataService);
	this.gridService = services?.gridService ?? new GridService(this.gridStateService, this.filterService, this._eventPubSubService, this.paginationService, this.sharedService, this.sortService, this.treeDataService);
	this.groupingService = services?.groupingAndColspanService ?? new GroupingAndColspanService(this.extensionUtility, this._eventPubSubService);

[zewa666]

well exactly due to crud support for deleting a row since the new actions column added would contain an edit and delete button for each row. but you're right I might be better of just looking up the delete methods implementation.

yeah I noticed its no true DI container reading the comments.

[zewa666]

hmm actually it felt too wrong to re-implement all the details that are to be found in the delete method so I've sticked to the gridService and routing it through the bundle over to the extensionService and to the init of my plugin. This one could certainly need some improvement.

Nevertheless, I wanted to show you what I got so far after a quick stab zewa666@d4372aa which is not done but a first look so that you get a chance to say whether this feels too specific, in which case I'd just implement it locally for our apps, or it could be a generic feature.

[ghiscoding]

Funny enough, I was actually going to ping you and ask how it is going with this because I wanted to possibly push a new release tomorrow to close up all opened PRs and push a few fixes. I can wait a few more days though since you seem to be making good progress. Side note, I've added an ESLint rule to prefer single quote, so things like this pluginName = "RowBasedEdit" as const; will need to change.

without actually doing a git checkout and running the code yet, would it be possible to do a print screen or animated gif of that feature?

[zewa666]

I dont think I'll make it on time. throughout the implementation of the POC I've realized there might be tons of parts the user might want to override. like you mentioned the position of the col, the template of the buttons etc.

So I'd like to take on this a bit slower and think through cases.

Also I'm not next to the PC but can post a gif tomorrow.

[zewa666]

Ok so here's the quick preview I have for the plugin

[ghiscoding]

oh ok, I thought you had found a way to make the entire row editable at once but it's not entirely that. I think that in that case it might be good if we could have a way to add some CSS classes to all the cells that are allowed to be editable. With the CSS classes, the user could at least know which one are editable (clickable). So I'm not sure if it's actually doable, it's just a suggestion on the UX side of things, if doable then these classes could be customized by the user (or just simple CSS/SASS variables might suffice)

This also kind of remind me of batch editing, which is what I've done in Example 12, all the cells that got edited (even to empty) are turning with an orange outline and once they're all saved then I remove that outline (via ItemMetadata styling)

[zewa666]

agreed, thats what I started doing with adding a slick-rbe-editmode class to rows in editmode and updating the themes to define two new css vars and defaulting different background for those rows. Also I've switched from rows to id/datasetIdPropertyName for the indicator vs the row index.

also as mentioned initially, the difference is that now you're only allowed to edit cells within rows in editmode (either one or multiple, depending on the config)

zewa666@8adc3dd

So in example 11 (batch updates) the usage of setCellCssStyles is another missing piece I was looking for. I went with monkey patching getItemMetadata instead, which didn't work though as thought since it's only triggered on rerendering rows. I thought instead of doing so I'd manipulate the DOM directly (you can see all of that in the above linked commit) to spare the extra re-render roundtrip

[ghiscoding]

pretty damn cool, I'm always impressed by new approach like this that I didn't think about :) SlickGrid is so customizable, that is also why I love the lib so much. Looking good so far 👍🏻

It looks like you're similar to me, I'm on holidays since a few days but I still work on the lib lol

[zewa666]

well ... guilty ;)

holiday with two kids is mildly said challenging, happy to have the nights blocked for coding fun 😅

so if you're still fine with turning this into an official plugin I think next I'll create a github issue to track tasks and progress.

Also with regards to the examples I didnt really find any suitable (either wrong context or too specific cypress tests) so if you're fine with it I'd add a new one. Additionally, could you point me to where in the docs you would describe this plugin? I thought about adding a new page in the grid functionallities section

[ghiscoding]

so if you're still fine with turning this into an official plugin I think next I'll create a github issue to track tasks and progress.

it seems kinda small though, up to you if you want to create a new plugin (package) but I'd be ok also to keep it as an internal extension that only requires a flag to enable (an external package will require externalResource to be provided)

Adding a new Example seems reasonable, I'm not sure when you forked the repo but I added Example 21 couple days ago, so that would require you to use Example 22.

could you point me to where in the docs you would describe this plugin? I thought about adding a new page in the grid functionallities section

yeah I guess Grid Functionalities seems like a good place. We could also perhaps add a reference into the main Editors.md doc

[zewa666]

sry if I was unclear. It wasn't about whether it's part of common or an additional new package. I wasn't sure if you'd like this feature to be a plugin at all, such as whether it can be of value to others as well.

[ghiscoding]

yes I definitely think this can be of value to others, so yes it could be part of the common package I think

[zewa666]

closing this in favor of #1299