While iteration such as with for...of may avoid the need for a lot of length-based for-loop iteration, I wonder whether at (and for that matter codePointAt) might be more appealing if there were a more Unicode-friendly replacement for length that it could hook into.
For example,
const icons = '🐎👱❤'; // code units respectively: \ud83d\udc0e , \ud83d\udc71 , \u2764
console.log('Character length', icons.charLength);
for (let i = 0; i < icons.charLength; i++) {
console.log(icons.charLengthAwareAt(i));
console.log(icons.charLengthAwareCodePointAt(i));
}Character length 3
🐎
128014
👱
128113
❤
10084
While there are still other problematic methods as you have pointed out elsewhere (e.g., reverse), it would seem to me that this fundamental one, length, really ought to be addressed, to allow developers (e.g., at least those using eslint rules against non-Unicode aware methods) to avoid needing to care about how characters are composed at the code unit level.
It is not complicated to polyfill:
Object.defineProperty(String.prototype, 'charLength', {
get () {
return [...this].length;
}
});The fact of it being easy to polyfill though doesn't mean it wouldn't be good to promote its use.
While iteration such as with
for...ofmay avoid the need for a lot oflength-based for-loop iteration, I wonder whetherat(and for that mattercodePointAt) might be more appealing if there were a more Unicode-friendly replacement forlengththat it could hook into.For example,
While there are still other problematic methods as you have pointed out elsewhere (e.g.,
reverse), it would seem to me that this fundamental one,length, really ought to be addressed, to allow developers (e.g., at least those using eslint rules against non-Unicode aware methods) to avoid needing to care about how characters are composed at the code unit level.It is not complicated to polyfill:
The fact of it being easy to polyfill though doesn't mean it wouldn't be good to promote its use.