Double state update for Date (Objects) vars in component with binding.

[stalkerg]

First example: https://svelte.technology/repl?version=2.11.0&gist=10425d9f7670c91b6aff756943ffb43c
In console for the first button, you should saw two print and one for the second button.

This happens because we wrong compare Date object after this._state = assign(assign({}, oldState), newState); in _set.
Ofcourse, it will happens for any object and it bad too but for Date at least we can solve this problem just use .getTime() in _differs.

[stalkerg]

Will be good if we can introduce functions for compare variables in state like:

	export default {
		data() {
			return {
				bindVar: new Date(),
				bindVar2: " " + Math.random(),
			};
		},
		equalentors: {
                	bindVar: (a, b) => a.getTime() === b.getTime(),
                },
	}

[stalkerg]

immutable: true, ha immutable solve my problem

[Conduitry]

Part of me thinks that letting the object comparison logic be customized is a neat idea - but another part of me thinks that we should just keep it as it is now, and say that if you're at the point where you're caring about that level of optimization, you should probably be using immutable data. Having a special case just for Dates seems weird. This would also be extra code that everyone would be forced to download and run, whether or not it was relevant to them.

Also, Equalentor is definitely the name of my next band.

[mrkishi]

Should the parent even be .set()ing the child component after direct binding changes?

[stalkerg]

@Conduitry

you should probably be using immutable data

unfortunately, in JavaScript, we have no any good way to make an equal operator for objects.
In other languages, you can set this outside - in your own class or object. In JS you should do it explicitly anyway.
I want to say in some case we will not have a good solution even with "immutable".

Also, Equalentor is definitely the name of my next band.

I can help you with some instruments. :) PS I just tried to find a good name for this thing and makes the new with the cool scifi sound.

[stalkerg]

Should the parent even be .set()ing the child component after direct binding changes?

looks like no... somewhere bug here. At least, what we pushed up we shouldn't set directly again.

[Conduitry]

We have #2886 for making improvements to the comparators, but we don't want to start worrying about different specific object types. As noted above, a component with immutable data won't have problems with this. Closing.