[DevTools] Use Unicode Atom Symbol instead of Atom Emoji

[sebmarkbage]

This reverts #19603.

Before:

After:

Consensus seems to be that while the purple on is a bit clearer and easier to read. The purple is not on brand so it doesn't look like React. It looks ugly. It's distracting (too eye catching). Taking away attention from other tabs in an unfair way.

It also gets worse with more tabs added. We plan on both adding another tab and panes inside other tabs (elements/sources) soon. Each needs to be marked somehow as part of React but spelling it out is too long. Putting inside a second tab means two clicks and takes away real-estate from our extension and doesn't solve the problem with extension panes in other tabs. We also plan on adding multiple different tracks to the Performance tab which also needs a name other than just React and spelling out React as a prefix is too long. The Emoji is too distracting. So it seems best to uniformly apply the symbol - albeit it might just look like a dot to many.

Dark mode looks close to on brand:

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
react-compiler-playground	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Sep 10, 2024 4:03am

[react-sizebot]

Comparing: 6066b8e...653e391

Critical size changes

Includes critical production bundles, as well as any change greater than 2%:

Name	+/-	Base	Current	+/- gzip	Base gzip	Current gzip
oss-stable/react-dom/cjs/react-dom.production.js	=	6.68 kB	6.68 kB	=	1.83 kB	1.82 kB
oss-stable/react-dom/cjs/react-dom-client.production.js	=	505.22 kB	505.22 kB	=	90.29 kB	90.29 kB
oss-experimental/react-dom/cjs/react-dom.production.js	=	6.69 kB	6.69 kB	=	1.83 kB	1.83 kB
oss-experimental/react-dom/cjs/react-dom-client.production.js	=	512.41 kB	512.41 kB	=	91.50 kB	91.50 kB
facebook-www/ReactDOM-prod.classic.js	=	600.74 kB	600.74 kB	=	106.27 kB	106.27 kB
facebook-www/ReactDOM-prod.modern.js	=	577.03 kB	577.03 kB	=	102.41 kB	102.41 kB

Significant size changes

Includes any change greater than 0.2%:

(No significant changes)

Generated by 🚫 dangerJS against 7cb7bc6

[eps1lon]

Sooo, are you gonna work on adding a React emoji to the unicode standard? 😄

I don't have a preference here. It's either ugly or unreadable.

[hoxyq]

There is a parameter for chrome.devtools.panels.create, which allows to specify path to an icon, but looks like its not working on Chrome.

Looks like it is deprecated, and the docs were not updated. Only Firefox is correctly displaying the extension icon left to the panel name.

I am not sure about this change, though, would adding "React" as prefix make it take too much space?

[hoxyq]

Can we have some time to discuss this, before actually committing and potentially changing this multiple times?

I think the ideal state for us is to ask Chrome team if iconPath will ever be supported again, so that we can display correct React logo.

If its deprecated and there are no plans for supports icons in third party extensions panels, then I would prefer having "React" as a prefix in our panels names, I don't think the spelling is too long, and it looks native to other built-in panels.

I don't know about the plans on naming the third panel, but it should not be long as well, something like "React Suspense", "React Suspense Sandbox" is alright. Although the unicode atom symbol looks more similar to original React logo, it is barely visible.

[gaearon]

It's not great to have a "React" prefix because it steals screen estate from other tabs. I.e. Chrome would literally show fewer tabs on the screen because of this.

[huntie]

Adding a strong vote for leave as is 😅 Agree that iconPath would be ideal, and we should try to pursue this.

[hoxyq]

It's not great to have a "React" prefix because it steals screen estate from other tabs. I.e. Chrome would literally show fewer tabs on the screen because of this.

Chrome users can re-arrange panels, so that the most important ones or the most used ones are on the left.
I think we just need to decide what we are optimizing: the spelling length or the recognition / branding.

Ideally, it should have been just React logo to the left of the panel name, but it is currently only supported in Firefox.

[sebmarkbage]

I absolutely don't want to leave it as is. It makes me embarrassed to work on it. It really looks like shit.

I'm actually ok with just removing the icon completely and putting the logo in the panel itself. You'd have to learn that "Components" means React Components and "Suspense" means React Suspense. "Profiler" means React Profiler somehow.

Even if you reorder them "React Components", "React Suspense" and "React Profiler" is almost enough to take up the whole width in a right-docked panel.

Keep in mind that it's not just about these two tabs. It's about the panes integrated into the other native tabs too. For example I want to add a "Components" pane in the Elements panel. That one defaults to a horizontal tab bar in smaller sized pane. We could just name it "Components" there too. I'm ok with that but it's a bit broad.

Then there's the Performance tab. It would have things like Client Components and Server Components tracks. That's already kind of long even without the React prefix and the Performance tab has this existing problem that the earliest left-most things are already covered up by the track names.

Even if we get the iconPath added back it's probably not getting added to the panes and the performance tab too. So we don't have a consistent design language to work with. The unicode icon is a nice hack to build that consistency without taking up real-estate.

But I'm also ok just removing the icon and word React completely. When working on a React centric app that's typically your primary focus so it's implied anyway. It's like the whole thing is the React DevTools.

[sebmarkbage]

Btw the icon in Firefox looks terrible in light mode too. Is there a way to make that use a transparent background instead that can work in both?

[sebmarkbage]

If we remove the icon we can maybe squeeze in the logo in the top left corner where the selector is and next to the record button. The way I was imagining the Components pane in Elements was that the top would be a short list of Components so wouldn't work there. It also wouldn't work in the Performance tab. Those are maybe implied by Client Components and Server Components (there's a third one to be named too) or could use the icon only in that case but then there's nothing to carry it over.

[josephsavona]

Could we have a single "React" tab, within which we have components and profiler and whatever other tabs we choose to add later? Just "React" makes it super clear.

[hoxyq]

Btw the icon in Firefox looks terrible in light mode too. Is there a way to make that use a transparent background instead that can work in both?

I think Firefox is using one of the icons, which are defined in the manifest file. Updating these icons to have transparent background should fix it, but there could be other implications from having transparent background in the extension logo.

[hoxyq]

Could we have a single "React" tab, within which we have components and profiler and whatever other tabs we choose to add later? Just "React" makes it super clear.

It is possible, and I think this is another case we should consider.

The code for it is already there - we do render inner tabs (Components and Profiler) in React DevTools UI for React Native (both in legacy standalone electron shell and in new Chrome DevTools-based approach).

One potential downside is cross-panel deeplinking in Chrome DevTools: we want to be able to navigate to / from Performance panel, for example, this is something Chrome DevTools team is currently exploring. Although it would probably not affect the complexity of the potential implementation (we could still implement inner tab navigation by parsing deeplink), having multiple panels is more obvious to the user, because you only have single level of depth for panels.

[sebmarkbage]

Could we have a single "React" tab, within which we have components and profiler and whatever other tabs we choose to add later? Just "React" makes it super clear.

The goal with all of this work (performance.measure instead of React Profiler, elements/source panel extensions, server console logs, console.createTask for native stacks everywhere etc) is to great an integrated experience that works throughout the DevTools. Then there's also Next.js DevTools tabs etc.

React is only a small part of a larger system. So the idea of centralizing around you just opening the "React" tab and staying there is counter to that principle. It's more like the React Suspense tab is closer to a theoretical Next.js Network tab or Performance tab than it is to the React Components tab.

Given that the tabs are customizable and some tabs are more useful than others for specific work I don't think this is good. For example, I would likely hide the the React Components tab and just bring forward the React Suspense tab and the Elements tab. I wouldn't want to click React tab and then Suspense tab every time I want to get there.

[josephsavona]

@sebmarkbage That makes sense for why not grouping into a React tab. I think it's helpful for docs and new users if there is something a bit more specific than just "Components" as a tab name, and "React Components" is too long. The unicode symbol is a bit more subtle (i've never loved the current emoji either) so I'm supportive of this change as a good compromise.

If we can use the actual logo later great, but we don't have to block on it.

[sebmarkbage]

Tbh, I don't love the real icons in Firefox neither. It's very cluttered. I think Chrome probably did the right thing by removing them to avoid too many colorful icons there but maybe should've banned emojis at the same time. But then they added the green Node.js icon (which is great but green). 🙈

[sebmarkbage]

How do we feel about adding it to the end? That way when they're presented in lists the letters line up as opposed to:

This happens in Performance tab and extension panes in Sources tab too.

There's precedence in Chrome itself for icons at the end for example for Experimental features.

[josephsavona]

At the end seems fine too

I still don't see a reason why we are optimizing spelling size, but also agree that it should not block this PR from landing. Whatever we decide on styling, I would prefer to change it only once, and then maybe migrate to using React logo as an icon, in case this will ever be supported again by Chrome.