Hmm, I'm not sure what happened here - I can't reproduce this bug anymore and I also notice that the regex should never even fail because it's inside of if (name.startsWith('wp-')) { }.

I think the only case it would fail is if there were an attribute like wp- (with nothing after the hyphen).

I ll have to investigate tomorrow because it's quite late now in my timezone 😅.

startsWith should be safe to use (it shouldn't be transpiled to a regular expression). That means this is probably the moment when we should start talking about the bundling target for the frontend hydration.

To make this as close as possible to what we will ship in the future, I'd use Webpack to do the build and I'd start using esmodules in babel/preset-env.

The startsWith was not transpiled in the built file when I was doing the testing so that was not the problem. I'm not sure what caused it in the end because I could not reproduce it in the end.

I think the only case it would fail is if there were an attribute like wp- (with nothing after the hyphen).

What I meant here is that this regex would fail if we had an an attribute like wp- (with nothing after the hyphen):

const name = 'wp-'
/wp-([^:]+):?(.*)$/.exec(name); # returns null

To make this as close as possible to what we will ship in the future, I'd use Webpack to do the build and I'd start using esmodules in babel/preset-env.

👍 Agreed on this one!

Maybe we can replace this line:

if (name.startsWith('wp-')) {

with

if (name.startsWith('wp-') && name[3]) {

It should still be pretty fast.

FYI: It seems the site 24life.ro is facing this issue. It seems to be solved with the current status of this PR.

I've tested these options:

// 1
name.startsWith('wp-') && name[3]
// 2
name[0] === "w" && name[1] === "p" && name[2] === "-" && name[3]
// 3
const rg = /wp-\w/
rg.test(name);

Benchmark here: https://jsbench.me/9ilb2g41nb/1

3 is the slowest in every browser. 1 and 2 are equivalent in Chrome and Firefox, but 2 is twice as fast in Safari. Actually, looking at the results, it seems like startsWith is using === in Chrome and Firefox and a regular expression in Safari 😄

Unless someone else has another idea, let's use 2 for now.

FYI: It seems the site 24life.ro is facing this issue. It seems to be solved with the current status of this PR.

It seems like they are replacing String.prototype.startsWith.

I've made the change. Ready for review 🙂

I'm fine adding these changes as it seems to be more performant. However, are we supposed to give this kind of support? If a site modifies String.prototype.startsWith, I would say that's their problem. 😅

I can't approve it because it's my own PR.

I agree that we shouldn't have to worry about cases when native methods are modified but I approve anyway because it is faster in the end (thanks for pushing this forward @luisherranz! 🙂)

If a site modifies String.prototype.startsWith, I would say that's their problem

I agree that we shouldn't have to worry about cases when native methods

I agree with those statements, but I'd like to be extra careful with our toVdom to minimize backward incompatibilities. One thing is that you add a new block and it doesn't work because your startsWith is broken, and another thing is that you update WordPress and your site breaks. But yeah, it's not super important. Also, if we limit the hydration the DOM affected by toVdom that doesn't belong to interactive blocks will be way smaller.