pass previous value to controller.onChange

[Sceat]

This PR adds the ability to retrieve the previous value in the onChange callback, it's a must have in any watcher system and allows side effects based on the update.

It also remove useless updates caused by the click event and only call onChange if the value really changed.

This PR is a bit quick so it would be nice to point me in the correct direction to also updates any typing/doc/comment to make the PR receivable.

---

gui
  .add(settings, 'count')
  .name('Count')
  .onChange((count, previous_count) => {
    handle(count)
	if(count > previous_count) console.log('bigger count!')
  })

[georgealways]

Hi there, looks like there's two things going on:

It also remove useless updates caused by the click event and only call onChange if the value really changed.

The only controller that should generate an onChange event on click is the function (button) controller. If you're experiencing that someplace else too then please file an issue!

As for passing the previous value to onChange: I'm open to it, but I'd want to receive a few more requests before adding the feature. There's some complexity here too when it comes to color objects and arrays: i.e. should the previous value be deep cloned and stored?

Thanks for this! -g

[Sceat]

Yes actually when you drag a slider it triggers the onChange endlessly even when steps don't move

[Sceat]

There's some complexity here too when it comes to color objects and arrays: i.e. should the previous value be deep cloned and stored?

to me it should be the exact same value, and we let it be garbage collected

[Sceat]

Should we move forward on this ?, we could simply have the previous value passed and not the part on multiple updates. I could make 2 separated PRs

regarding cloning, I'd advise against it to stay transparent and let the user handle his code

[Sceat]

@georgealways any blocker ?

[georgealways]

• A fix for stepped number controllers generating extraneous onChange events is on the list for the next release.
• I'd like some more input from others on how prevValue should behave.

I haven't had a chance to look at either of these closely, and I can't make any promises as to when I will. If these are changes you need quickly, I'd recommend using a fork for the time being.

Thanks!