Open ptomato opened 2 years ago
And then, some random ideas that I have so far:
For (3), maybe it could be replaced by a compareArrayElementsWith
helper that takes the two arrays and applies a supplied comparison function to each element, kind of like is done already elsewhere in formatToParts
: here
Taking the above link as an example, I'd imagine an API that might look like this if that file were rewritten to use it:
function compareFormatRangePart(actual, expected, index, description) {
assert.sameValue(actual.type, expected.type, `${description}: type for part ${index}`);
assert.sameValue(actual.value, expected.value, `${description}: value for part ${index}`);
assert.sameValue(actual.source, expected.source, `${description}: source for part ${index}`);
}
assert.compareArrayElementsWith(
compareFormatRangePart,
dtf.formatRangeToParts(d1, d2),
[
{ type: "minute", value: "02", source: "shared" },
{ type: "literal", value: ":", source: "shared" },
{ type: "second", value: "03", source: "shared" },
],
"dates with same minutes and seconds"
);
For (2), a similar compareObjectEntriesWith()
helper, although ideally the name should make it clear that the order of assignment matters.
We briefly discussed in the maintainers' meeting of 2022-04-07, the
deepEqual
file in the harness has some problems in its semantics and we should at least encourage new tests not to use it, while working out a better way to provide that functionality.I've taken a look at what uses it and identified three categories:
compareArray
, which is clearer and more fit for purpose anyway.doesn'tdoes matter.Here are the places where it's currently used:
Providing alternatives for the remaining uses could be an interesting first test of our RFC process once I have come up with a proposal for that.