Add fast path skipping grapheme counting

[gaearon]

Not a huge deal but since we visit this codepath for every single validated string, seems like we'd want to avoid any unnecessary computation here, especially on low-end devices.

I don't know how encodings and grapheme work very well so this needs a close look.

Commits

• 0d6b54d
• 7b97382
• 8b0bdcb?w=1

Before

This was showing up in a profile for switching tabs with 6x throttling. (Note this is a DEV profile so in PROD its % would be higher compared to other things around it.)

After

It doesn't show up.

[pfrazee]

Yeah good call

[bnewbold]

behavior and overall approach looks good to me! this particular set of optimizations is on a relatively hot path and improves performance in the common case and feels worthwhile.

we'll probably want to do the same thing in the go implementation, and can copy these test cases (maybe make them "shared interop test vectors") when we do.

[bnewbold]

The "caching" logic could maybe be more readable like:

if (typeof def.maxLength ==='number' || typeof def.minLength ==='number') {
    const len = utf8Len(value)
    if (typeof def.maxLength ==='number') {
        if (len > def.maxLength) {
            ....
        }
    }
    if (typeof def.minLength ==='number') {
        ...
    }
}

and similar for the grapheme value.

but not sure what idiomatic typescript style would be here. not a big deal either way.

[bnewbold]

might be worth mentioning here (and below) that JavaScript string length is UTF-16, just to be super redundant about that, because it is confusing to many devs.