Save all changes feature

[zewa666]

Hey @ghiscoding.

finally I've started our company project with a dynamic OData based backend that provides column and grid configs for dynamically rendering and handling CRUD with a Slickgrid.

so far we're tracking changes in an editQueue, much like some examples you've made, and send updates/adds with a save all button to our backend, refreshing the current backend query on success. deletes are currently handled as one-offs but I plan to look into the rowselection option to also support bulk deletes.

our next step is to now improve the save all button to check all modified rows, iterate over their cells and trigger the validators to see if all client side validations are covered before executing the backend call. invalid cells will be highlighted with a individual cell css class applied.

so far the ideas. now I'm sure we're not the first ones to think about this and I recall our discussions to generalize the editQueue concept. now I wonder whether we should ideally think bigger and create a plugin to take care of all the parts involved.

would you see something like that as too big of a concern for slickgrid-universal itself and better kept in user land?

[ghiscoding]

do you mean keeping track of the visual styling of what's saved and what not (similar to Example 12)? I mean this goes back to our previous discussion that it could be nice to move that to some form of Edit Queue Service of some kind. I don't personally plan to work on that but if you wish to start then I would totally accept a PR for a new feature (it could be built-in or as an optional plugin if you think it could be huge). Because yes we tend to copy over and over the same kind of code to do this so it would make sense to move this to a centralized service in the future.

The only thing I'm not sure about in what you said is for validation of the queue?

[zewa666]

ok so the behavior there is that an editor is created on the fly to apply the new value. if the validation fails it applies the default of the respective inputEditor.

what it doesnt do is trigger an onValidationError. I'll look into creating a PR for that

[ghiscoding]

BTW when I made the Tooltip PR last week, I noticed that you made a mistake when you wrote the Cypress test, you complained that Cypress was wrong and you had to use the force: true on the button click but in reality you forgot to click Edit before clicking Update (perhaps the page was refreshed at that time, dunno), so Cypress was correct all along hahahaha 🤣 Anyway, I forgot to mention it to you before, so now you know 😋 below is the code I used to correct the mistake and add tooltip tests.

[zewa666]

are you implying I made a mistake? well if its just a single one I'd say not bad 😅

thanks for pointing out the issue, glad to see its not due tooling.

[ghiscoding]

I was just having a laugh, don't take it too seriously 😄

[zewa666]

all good ;)