[DevTools Bug]: Emoji as visual helper produce strange symbole

[jonlepage]

Website or app

https://codesandbox.io/s/react-playground-forked-j4niq

Repro steps

Emoji seem supported but produce strange symbole

To test emoji on Window Os, use [win]+[.] 🟩

How often does this bug happen?

Every time

DevTools package (automated)

No response

DevTools version (automated)

No response

Error message (automated)

No response

Error call stack (automated)

No response

Error component stack (automated)

No response

GitHub query string (automated)

No response

[bvaughn]

This is interesting!

DevTools sends component names as encoded characters, because the components tree is just a typed numeric array for performance reasons.

So a component name gets encoded like so:

const encoded = new Array(string.length);
for (let i = 0; i < string.length; i++) {
  encoded[i] = string.codePointAt(i);
}

I think "🟩" is a multi-byte character because it has a length of 2 (code points [129001, 57321]). When we decode those points on the other side though, the resulting string is "🟩\uDFE9".

Our string table needs to be updated to handle multibyte characters? Maybe we could use something like TextEncoder and TextDecoder for this? I wonder what the performance impact of this would be?

I'm not very familiar with this area.

[bvaughn]

Maybe we could use something like TextEncoder and TextDecoder for this? I wonder what the performance impact of this would be?

Yes, this does work:

Not sure what the performance impact is though.

[jonlepage]

Is performance in a development environment are so important?, are we talking about micro optimization for this specific case ??
Am also not familiar with this, but i let you take decision :)

[bvaughn]

Yes. This code is a hot path and very performance sensitive. I don't expect this would be a deal breaker though. :)

[jonlepage]

ok, i can live with that, it's not that big issue for me. :) feel free to close if you think is there not more solution (wihout perf impact)

[bvaughn]

Based on a few benchmarks, the TextEncoder/TextDecoder approach is slower (~85% slower), but it's unclear how much of an overall impact this will have on actual DevTools performance (as we don't encode long strings often).

• https://jsbench.me/boktzulhew/1
• https://jsben.ch/5tnt1

We could also break the benchmarks down further to compare how much the slowness is from encoding vs decoding. We cache names when encoding so we might be able to limit the impact in that case. If it's overhead from e.g. creating new typed arrays when decoding (or decoding itself) then we may have less flexibility.

[jonlepage]

ho ! 85% is really big!
it would be a shame to add such a load for so little.

A other suggest can be maybe add a options?

if people have good machine they can check this ! and bad machine, unchek ?

[bvaughn]

No worries. Good news is that I've found an alternate approach that's actually slightly faster than what we had before (based on benchmarking at least) so we'll move forward with it.