Show Pristine and Touch

[shiftlessatol]

Is it possible to add additional bool values to include pristine and touch representations?

And example would be this:

var ex = {};
watch(ex,function(prop,action,newvalue,oldvalue,status){
console.log(status);
});

//add new prop
ex.prop = 10;
/* 
ex.prop.status:
Pristine: true;
Touched: false;
*/

//change the value
ex.prop = 12;

/*
console would show:
status:
 Pristine: false;
Touched: true;
*/


//change value back to original value
ex.prop = 10;

/*
console would show:
status:
 Pristine: true;
Touched: true;
*/

This would be very handy for change tracking. You're already tracking previous and new values - It would be the same to store an additional value that can't change on the creation of the property to check against pristine. And then setting touched would be simple as the first time the watcher set is fired, it would be turned to true.

Let me know if this is something you would consider and how long you would expect to implement ( assuming you would consider it )

Otherwise, I will just code it for myself.

[Gil Lopes Bueno]

Sorry, I didn’t understood the difference between pristine and touch Em sex, 30 de mar de 2018 às 09:35, shiftlessatol <[e-mail]> escreveu:

…

Is it possible to add additional bool values to include pristine and touch representations? And example would be this: var ex = {}; watch(ex,function(prop,action,newvalue,oldvalue,status){ console.log(status); }); ex.prop = 10; //added new prop ex.prop = 12; /* console would show: status: Pristine:false; Touched:true; */ ex.prop = 10; /* console would show: status: Pristine:true; Touched:true; */ This would be very handy for change tracking. You're already tracking previous and new values - It would be the same to store an additional value that can't change on the creation of the property to check against pristine. And then setting touched would be simple as the first time the watcher set is fired, it would be turned to true. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#122>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABRqfwR6ZY4goeg_QESG0xDOE_QBcgqsks5tjiaTgaJpZM4TBpX7> .

[shiftlessatol]

pristine = being that the originally set value is the current value. ( unchanged value from it's creation or initial set )

touch being that the property or object has been modified ( regardless of value )

So in the example, if I declare a value of 10 that becomes the pristine value.

If I change it to 12 it's then been touched and it's not the original value so that it's not pristine.

But if I change it back to 10 it's now the original value, and therefore, pristine - but it was modified so it remains touched.,

This would be good to check for manipulation and also to see if the value is different ( there are a few use cases that would benefit from both ).

I've already created the ability to do this outside of watch.js and using the listener to fire the event.

I need this regardless of your decision, and in case it's too bloated or complicated or of no interest, I went ahead with a decentralized method for the tracking of pristine. on an object-by-object basis. If anyone is interested, I can publish my object identification - and pristine comparison feature.

I've made it so that when the object is changed, watch.js passes the context to a method and I do a comparison to determine which object in the hierarchy was modified. I return that object and then compare it against the original. This allows me to see if the object or property is pristine or not ( original value or changed value ).

Touch: I have not done yet - but could easily be accomplished with a first-ever call to the watch.js handler for an object/property.

The benefit to adding it to directly is that in the handler, you simply pass an object that stores the extra details about the property/object.

I can fork and build this if you would like. or just modify and paste the js directly in this comment. Since I'm working on this part of my project it would go well. I just don't want to waste anyone's time.

[Gil Lopes Bueno]

This can be useful, do you think it may decrease the performance? Em dom, 1 de abr de 2018 às 13:37, shiftlessatol <[e-mail]> escreveu:

…

pristine = being that the originally set value is the current value. ( unchanged value from it's creation or initial set ) touch being that the property or object has been modified ( regardless of value ) So in the example, if I declare a value of 10 that becomes the pristine value. If I change it to 12 it's then been touched and it's not the original value so that it's not pristine. But if I change it back to 10 it's now the original value, and therefore, pristine - but it was modified so it remains touched., This would be good to check for manipulation and also to see if the value is different ( there are a few use cases that would benefit from both ). I've already created the ability to do this outside of watch.js but using the listener to fire the event. I need this regardless of your decision, and in case it's too bloated or complicated or of no interest, I went ahead a decentralized the tracking of pristine. on an object-by-object basis. If anyone is interested, I can publish my object identification - and pristine comparison feature. I've made it so that when the object is changed, watch passes the context to a method and I do a comparison to determine which object in the hierarchy was modified. I return that object and then compare it against the original. This allows me to see if the object or property is pristine or not ( original value or changed value ). Touch I have not done yet - but could easily accomplish with a first-ever call of the watch handler for an object/property. The benefit to adding it to directly is that in the handler, you simply pass an object that stores the extra details about the property. I can fork and build this if you would like. or just modify and paste the js directly in this comment. Since i'm working on this part of my project it would go well. I just don't want to waste anyone's time. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#122 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABRqf-ebF6Fu-HfdSRc2MZ6coSCWE8u6ks5tkQJSgaJpZM4TBpX7> .

[shiftlessatol]

Always a possibility - but most likely worth it. I don't think it would be noticeable. you could add a configuration parameter to turn it on and off. then for those who want it they can enable and those who don't can leave it off. That would satisfy the concern. you could also do it per object/property to give granularity. So it's the best of both worlds.