Open aaronm67 opened 12 years ago
I agree - this is confusing. The other issue here is that the order of enumeration is not guaranteed: https://github.com/bgrins/filereader.js/blob/master/filereader.js#L255.
So if you had something like:
readAsMap: {
"image/png", "DataURL",
"image/*", "BinaryString",
}
The image/*
could potentially be matched first depending on the order the readAsMap is enumerated.
What do you think the ideal behavior / interface for this is?
jQuery "Converters" on Ajax requests are fairly similar -- The interface they provide is similar to this:
var readAsDefaultMap = { ... };
if (typeof(opts.converters) == 'undefined') {
opts.readAsMap = readAsDefaultMap;
}
The ordering problem could be solved by disallowing Regex in these maps, i.e. "image/*" is disallowed, then rather than looping through the map, it would be accessed directly by key (i.e. readAsMap[type] || readAsDefault).
Alternatively, you could do something to this effect, where you will match the exact content type before trying to match with a regex:
for (var r in readAsMap) {
if (type ===r) {
return 'readAs' + readAsMap[r];
}
}
for (var r in readAsMap) {
if (type.match(new RegExp(r))) {
return 'readAs' + readAsMap[r];
}
}
This doesn't really fix the issue, though, it just makes it a little less common (it will still, for example, pop up for { "image/" : "DataUrl", "image/jp", "BinaryString" }).
The interface with the readAsMap is a bit awkward -- typically I'd assume that this:
would make all inputs return a DataURL, or this:
would make all inputs return the "readAsDefault". Instead, both of these situations end up with a "readAsMap" containing