Make it easier to create custom DataTypes
I've been able to write a custom DataType implementation for Moment.js but am stuck in places where the equality of two instances of the DataType is evaluated.
Currently, there are a number of lines of code which specifically handle Dates differently because of their inability to be compared using ===. For instance, in a35_defaultPropertyInterceptor.js:
// exit if no change - extra cruft is because dateTimes don't compare cleanly.
if (newValue === oldValue || (dataType && dataType.isDate && newValue && oldValue && newValue.valueOf() === oldValue.valueOf())) {
return;
}
However, that means if I want a custom DataType, and need a custom equality operator, I have to edit this portion of the file. Instead, I propose using the getComparableFn method already available:
// exit if no change - extra cruft is because dateTimes don't compare cleanly.
var normalize = dataType && DataType.getComparableFn(dataType);
if (newValue === oldValue || (dataType && normalize && normalize(newValue) === normalize(oldValue)) {
return;
}
This would be similar to what you're doing in getComparer in OrderByClause in a45entityQuery.js. One could use the same logic for the coEquals function in EntityType in a40entityMetadata.js.
The other oddity I found while doing this was the custom code used for Dates in fromJSON in DataProperty. This function would seem better served by using the parse function of the dataType itself, or the static DataType.parseRawValue.
Finally, it would be nice to be able to attach a getConcurrencyValue function to DataType for use in updateConcurrencyProperty in a50_entityManager.js.
Mike McCaughan
shared this idea
-
Mike McCaughan
commented
Thanks for taking a look at this!
I was looking at creating a custom datatype for the Moment.js library, as we are trying to use that in our app for easier date handling. I looked at all of the places in breeze.js where there's special handling for Dates, since Moments are obviously very similar.
That's where I noticed the special handling for Dates in `fromJSON`. It would be nice to have an extension point on DataType for that purpose, but maybe I'm not understanding the purpose?
-
Steve Schmitt
commented
These are good ideas; it should be easier to create custom datatypes.
We have to be careful in a35_defaultPropertyInterceptor.js, because that's a very hot path (it gets executed every time any property changes on any entity).
DataType.fromJSON is different from the `parse` function because it has different expectations about the incoming format. It's handling the metadata definitions, not arbitrary query responses.