12 ms·

New React DevTools

321 points by bpierre 7y ago

Waterluvian 7y ago
Ooooh exciting. I was impressed to see how well hooks worked when attaching Vscode to a chrome instance in debug mode. They just show up in the list of closures at your breakpoint. Maybe I need to try harder but I haven't been needing react dev tools.
- brianvaughn 7y ago
  You might still check out DevTools at some point :) They do a lot of small things that can be nice.
acemarke 7y ago
Brian has done some _fantastic_ work improving the DevTools! This is going to benefit the whole React community for years to come. Be sure to check out the complete changelog and the tutorial linked in the announcement.
- meetzaveri7 7y ago
  Yes he has put in great efforts for building this awesome tool
hswolff 7y ago
Congrats on the release Brian!
ralusek 7y ago
Does anybody bother to go through this codebase? It's a great tool, but Facebook is the last company I'd want to have the obscene privileges that extensions have.
- danabramov 7y ago
  If you saw the scary permission dialog upgrading, that was due to our mistake: https://twitter.com/reactjs/status/1162174507391574017 https://twitter.com/reactjs/status/1162174507391574017. Commits with fixes: * https://github.com/bvaughn/react-devtools-experimental/commit/545de6f02e7d8905ba4e1cd358e68bb640a31a0a https://github.com/bvaughn/react-devtools-experimental/commi... * https://github.com/bvaughn/react-devtools-experimental/commit/527fc4a63f497db1f370a8312807c2a68147edec https://github.com/bvaughn/react-devtools-experimental/commi... Both of these issues should be fixed in 4.0.2. Brian goes into more detail on why we originally added these permissions during the rewrite, and why we were able to remove them: https://www.reddit.com/r/reactjs/comments/cqx554/introducing_the_new_react_devtools/ex0p0m1/ https://www.reddit.com/r/reactjs/comments/cqx554/introducing.... (TLDR: some were for features we ended up cutting; others had easier workarounds that didn't need these permissions.) The source code is here (https://github.com/bvaughn/react-devtools-experimental/commits/source https://github.com/bvaughn/react-devtools-experimental/commi...). We're currently moving it into React repo so it's easier to find (https://github.com/facebook/react/pull/16381 https://github.com/facebook/react/pull/16381) but haven't managed to make the CI green so the source of truth for releases is still in that branch. We plan to cut over to React repo as source of truth next week.
  - ralusek 7y ago
    Yes, thanks for addressing.
- brianvaughn 7y ago
  > but Facebook is the last company I'd want to have the obscene privileges that extensions have. reply Sounds like you're talking about extensions in general, but for what it's worth- React DevTools doesn't require any super deep permissions¹ and all of the source code is in the open². ¹ https://github.com/bvaughn/react-devtools-experimental/blob/2bcc6c6d04e302f9c1cd2f724ee2033a999b36b8/shells/browser/chrome/manifest.json#L43-L47 https://github.com/bvaughn/react-devtools-experimental/blob/... ² https://github.com/bvaughn/react-devtools-experimental/tree/source https://github.com/bvaughn/react-devtools-experimental/tree/...
  - marvindanig 7y ago
    Yeah, but the intent is to drive developers away from the building blocks of web and weaken the value of HTML standards and accessibility guidelines that make the web awesome. Evil has many masks. And a corporation powered ‘open source’ is now the worst evil monster we have had to face in decades.
    - brianvaughn 7y ago
      That's definitely not the intent.
      - marvindanig 7y ago
        ...the sibling comment below disproves yours.
        danabramov 7y ago
        To give some context. Historically React has been all about sharing what worked for us at FB for creating dynamic, complex apps. If it doesn't work well for you, please don't use it. There are plenty of alternatives. The notion that there's some kind of plan to "weaken the web" there just isn't true. I don't know what you're basing it on. You may not remember this, but when React came out, everybody laughed at it. It was not some kind of asset for Facebook at the time. If we talk about motivation, ours is quite the opposite. We want to empower web developers to create complex UIs, comparable to native apps. We very much want the web to win, or at least to stay relevant. The only reason React got open sourced and kept being developed in the open was because engineers working on it wanted to share it with the wider web community. They saw something useful in it. Eventually, the industry took note, but it wasn't until a few years later. We believe in open web, and this is why we work on React. The notion that React is at odds with accessibility is also mistaken. React outputs regular DOM, and common React setups like Create React App include more accessibility checks than you'd get writing HTML by hand. Maybe you're confusing React with something else? Yes, keeping dynamic JS apps accessible has its own set of challenges (we document some here: https://reactjs.org/docs/accessibility.html https://reactjs.org/docs/accessibility.html), but it's not React that makes it hard. It's the dynamic UI expected by users that makes it hard. If anything, in my experience React makes it easier for teams to adopt better accessibility practices by putting them directly into React components (example: https://ui.reach.tech https://ui.reach.tech). Finally, concerning standards. We've worked and will continue working with standards committees to bring good parts of React into the platform. For example, the "object spread" operator in JavaScript was originally added to JSX, and was championed in TC39 by a React team member. Similarly, we're closely working with standard bodies to improve web app responsiveness. Not just for React, but for all libraries. You can learn more about this work here: * https://github.com/WICG/is-input-pending https://github.com/WICG/is-input-pending * https://www.youtube.com/watch?v=mDdgfyRB5kg https://www.youtube.com/watch?v=mDdgfyRB5kg Happy to address any specific concerns if you have them.
komali2 7y ago
Is this the same program that, if a project has installed, tries to make a bunch of websocket requests from the app to the browser plugin, which if non-existent causes your console and network tab to be flooded with failed websocket requests?
- brianvaughn 7y ago
  Doesn't sound like it. React DevTools uses the `postMessage` API to communicate, not websockets.
  - LinguaBrowse 7y ago
    komali2 is referring to the long-standing issue in the React Native repo (#10027); see my comment for an explanation: https://news.ycombinator.com/item?id=20713612 https://news.ycombinator.com/item?id=20713612 Maybe the Chrome/Firefox DevTools don't, but the standalone React DevTools most definitely depend on WebSockets. My custom React renderer can't connect to them without shimming in a WebSockets implementation, for example.
    - brianvaughn 7y ago
      Thank you for elaborating.
- leetrout 7y ago
  Are you thinking of the service worker caching issues in create-react-app?
- ricardobeat 7y ago
  Hot reload?
- pault 7y ago
  No, that's the webpack dev server.
- LinguaBrowse 7y ago
  I'm surprised that everyone's looking confused here. Yes: since 2016 (React Native v0.32), at least on iOS, React Native apps in development mode try to open WebSocket connections to standalone React DevTools at startup and indeed flood your console with cryptic messages. https://github.com/facebook/react-native/issues/10027 https://github.com/facebook/react-native/issues/10027 The issue has been locked and is still open.
duxup 7y ago
>It also offers full support for React Hooks, including inspecting nested objects. Thank goodness, that was killing me.
droidist2 7y ago
One thing I like about having React DevTools installed is you can easily see which sites use React because the little icon lights up. It's a surprising amount these days; React is getting so popular.
- MuffinFlavored 7y ago
  I wouldn't want to work on Polymer or Angular in today's job market.
  - rovyko 7y ago
    Why is that?
    - throw03172019 7y ago
      I think he/she is implying everyone is using React which means no jobs for Angular devs.
      - jackdh 7y ago
        I can still see Angular kicking around for a long time too be honest.
        k__ 7y ago
        Yes. Especially in Germany it seems to be on a high in terms of Web development. But when it comes to mobile, React-Native seems the way to go.
        bytematic 7y ago
        What is the competition in that regard apart from native apps? Flutter and Ionic are sorta different beasts
        7y ago
SimeVidas 7y ago
1.7 million users in Chrome? Wow, that’s a lot of React developers.
- brianvaughn 7y ago
  It's a little scary to upload a completely new version, when you know there's that many weekly active users that are going to be hammering away on it soon.
erikpukinskis 7y ago
React DevTools are very valuable. But only because React, with transpiling and the shadow DOM and all that is so inscrutable. There’s no hope of understanding the DOM with React, no hope of understanding styles with styled-components. There’s no hope of placing a breakpoint in your code and tracing forward through events. No hope of understanding stack traces. The DevTools begin to address some of those deficiencies. It does help, but still leaves me thinking the tradeoffs weren’t worth it. You can never reach simplicity, only manageable complexity. In the long run it leaves an opportunity for a new generation of tools that respect JavaScript and the DOM.
- onion2k 7y ago
  There’s no hope of understanding the DOM with React... You can still understand the DOM in a React driven app though. The component output is there for anyone to read. I do that every day. All React is doing is generating DOM content and then working out the smallest update necessary when the state changes. The problem that React Devtools addresses is that it's the component output that's there, not the components themselves. There's more information behind the scenes, and that is what React Devtools lets you peek in to. It does help, but still leaves me thinking the tradeoffs weren’t worth it. You have to reason about the way you write code, what your apps need, and what works best for your users. If the tradeoff is that using React's features means you can no longer work with the complexity of what's happening in the browser and that's slowing down your development process then don't use React. Your development process and your users are way more important than any framework.
  - blueprint 7y ago
    > You have to reason about the way you write code, what your apps need, and what works best for your users. Not to use too-harsh language but that's a cop-out in my opinion. Yes, some tools are better for a given job than others. But we're working with general-purpose machinery for the purpose of building UIs and applications. There isn't really a differing set of requirements or problems in that domain. ... and if that's true, then it means that one size should actually fit all. I think, personally, UIKit is excellent. I think people don't understand how to use it properly… they don't understand how to write good imperative code, so they look to a declarative system as a way around that… but I think they're only deferring the inevitable or shifting non-problem-inherent complexity they couldn't initially solve.
JTenerife 7y ago
As if the improvements of the dev tools weren't enough, they've created a sweet interactive tutorial (https://react-devtools-tutorial.now.sh https://react-devtools-tutorial.now.sh)! Don't know it it's new, but I'am very impressed.
- Vinnl 7y ago
  Where they=brianvaughn (I see he's also left a comment elsewhere on this post), who did most of the work on both the tutorial and the dev tools.
  - brianvaughn 7y ago
    Glad the tutorial is helpful! :) It was a last minute idea and I'm excited about how it turned out.
snazzycalynx 7y ago
Can someone explain why the permissions changed? The new version (in Chrome) wants permission to "read my browsing history", and other people are saying that it needs permission to "run when Chrome isn't running" (although it hasn't asked me for that one yet - maybe it was already fixed in the 4.0.1 release or something?).
mistyeyed 7y ago
Only had a cursory glance at the new tools but looks awesome. Love the new look and feel and the hooks inspector is working flawlessly. kudos folks!!
panzerklein 7y ago
Does anybody else get "Unable to find React on the page" error in private mode in Firefox?
dmitryminkovsky 7y ago
Great news. Excited to try it out. Thanks a lot.
notus 7y ago
Hooks still show up without variable names associated with them (I say still because I was using this before release). I assumed they would try to find a way around it. In the current state the hooks support is useless.
hnsocks 7y ago
Why trying to simplify complex usability ? This is just life support for react. So many better and simpler alternatives are there. Please use them..

321 points by bpierre 7y ago

Ooooh exciting. I was impressed to see how well hooks worked when attaching Vscode to a chrome instance in debug mode. They just show up in the list of closures at your breakpoint. Maybe I need to try harder but I haven't been needing react dev tools.

brianvaughn 7y ago
You might still check out DevTools at some point :) They do a lot of small things that can be nice.

acemarke 7y ago

Brian has done some _fantastic_ work improving the DevTools! This is going to benefit the whole React community for years to come. Be sure to check out the complete changelog and the tutorial linked in the announcement.

meetzaveri7 7y ago
Yes he has put in great efforts for building this awesome tool

hswolff 7y ago

Congrats on the release Brian!

ralusek 7y ago

Does anybody bother to go through this codebase? It's a great tool, but Facebook is the last company I'd want to have the obscene privileges that extensions have.

danabramov 7y ago
If you saw the scary permission dialog upgrading, that was due to our mistake: https://twitter.com/reactjs/status/1162174507391574017 https://twitter.com/reactjs/status/1162174507391574017. Commits with fixes: * https://github.com/bvaughn/react-devtools-experimental/commit/545de6f02e7d8905ba4e1cd358e68bb640a31a0a https://github.com/bvaughn/react-devtools-experimental/commi... * https://github.com/bvaughn/react-devtools-experimental/commit/527fc4a63f497db1f370a8312807c2a68147edec https://github.com/bvaughn/react-devtools-experimental/commi... Both of these issues should be fixed in 4.0.2. Brian goes into more detail on why we originally added these permissions during the rewrite, and why we were able to remove them: https://www.reddit.com/r/reactjs/comments/cqx554/introducing_the_new_react_devtools/ex0p0m1/ https://www.reddit.com/r/reactjs/comments/cqx554/introducing.... (TLDR: some were for features we ended up cutting; others had easier workarounds that didn't need these permissions.) The source code is here (https://github.com/bvaughn/react-devtools-experimental/commits/source https://github.com/bvaughn/react-devtools-experimental/commi...). We're currently moving it into React repo so it's easier to find (https://github.com/facebook/react/pull/16381 https://github.com/facebook/react/pull/16381) but haven't managed to make the CI green so the source of truth for releases is still in that branch. We plan to cut over to React repo as source of truth next week.
- ralusek 7y ago
  Yes, thanks for addressing.
brianvaughn 7y ago
> but Facebook is the last company I'd want to have the obscene privileges that extensions have. reply Sounds like you're talking about extensions in general, but for what it's worth- React DevTools doesn't require any super deep permissions¹ and all of the source code is in the open². ¹ https://github.com/bvaughn/react-devtools-experimental/blob/2bcc6c6d04e302f9c1cd2f724ee2033a999b36b8/shells/browser/chrome/manifest.json#L43-L47 https://github.com/bvaughn/react-devtools-experimental/blob/... ² https://github.com/bvaughn/react-devtools-experimental/tree/source https://github.com/bvaughn/react-devtools-experimental/tree/...
- marvindanig 7y ago
  Yeah, but the intent is to drive developers away from the building blocks of web and weaken the value of HTML standards and accessibility guidelines that make the web awesome. Evil has many masks. And a corporation powered ‘open source’ is now the worst evil monster we have had to face in decades.
  - brianvaughn 7y ago
    That's definitely not the intent.
    - marvindanig 7y ago
      ...the sibling comment below disproves yours.
      - danabramov 7y ago
        To give some context. Historically React has been all about sharing what worked for us at FB for creating dynamic, complex apps. If it doesn't work well for you, please don't use it. There are plenty of alternatives. The notion that there's some kind of plan to "weaken the web" there just isn't true. I don't know what you're basing it on. You may not remember this, but when React came out, everybody laughed at it. It was not some kind of asset for Facebook at the time. If we talk about motivation, ours is quite the opposite. We want to empower web developers to create complex UIs, comparable to native apps. We very much want the web to win, or at least to stay relevant. The only reason React got open sourced and kept being developed in the open was because engineers working on it wanted to share it with the wider web community. They saw something useful in it. Eventually, the industry took note, but it wasn't until a few years later. We believe in open web, and this is why we work on React. The notion that React is at odds with accessibility is also mistaken. React outputs regular DOM, and common React setups like Create React App include more accessibility checks than you'd get writing HTML by hand. Maybe you're confusing React with something else? Yes, keeping dynamic JS apps accessible has its own set of challenges (we document some here: https://reactjs.org/docs/accessibility.html https://reactjs.org/docs/accessibility.html), but it's not React that makes it hard. It's the dynamic UI expected by users that makes it hard. If anything, in my experience React makes it easier for teams to adopt better accessibility practices by putting them directly into React components (example: https://ui.reach.tech https://ui.reach.tech). Finally, concerning standards. We've worked and will continue working with standards committees to bring good parts of React into the platform. For example, the "object spread" operator in JavaScript was originally added to JSX, and was championed in TC39 by a React team member. Similarly, we're closely working with standard bodies to improve web app responsiveness. Not just for React, but for all libraries. You can learn more about this work here: * https://github.com/WICG/is-input-pending https://github.com/WICG/is-input-pending * https://www.youtube.com/watch?v=mDdgfyRB5kg https://www.youtube.com/watch?v=mDdgfyRB5kg Happy to address any specific concerns if you have them.

komali2 7y ago

Is this the same program that, if a project has installed, tries to make a bunch of websocket requests from the app to the browser plugin, which if non-existent causes your console and network tab to be flooded with failed websocket requests?

brianvaughn 7y ago
Doesn't sound like it. React DevTools uses the `postMessage` API to communicate, not websockets.
- LinguaBrowse 7y ago
  komali2 is referring to the long-standing issue in the React Native repo (#10027); see my comment for an explanation: https://news.ycombinator.com/item?id=20713612 https://news.ycombinator.com/item?id=20713612 Maybe the Chrome/Firefox DevTools don't, but the standalone React DevTools most definitely depend on WebSockets. My custom React renderer can't connect to them without shimming in a WebSockets implementation, for example.
  - brianvaughn 7y ago
    Thank you for elaborating.
leetrout 7y ago
Are you thinking of the service worker caching issues in create-react-app?
ricardobeat 7y ago
Hot reload?
pault 7y ago
No, that's the webpack dev server.
LinguaBrowse 7y ago
I'm surprised that everyone's looking confused here. Yes: since 2016 (React Native v0.32), at least on iOS, React Native apps in development mode try to open WebSocket connections to standalone React DevTools at startup and indeed flood your console with cryptic messages. https://github.com/facebook/react-native/issues/10027 https://github.com/facebook/react-native/issues/10027 The issue has been locked and is still open.

duxup 7y ago

>It also offers full support for React Hooks, including inspecting nested objects. Thank goodness, that was killing me.

droidist2 7y ago

One thing I like about having React DevTools installed is you can easily see which sites use React because the little icon lights up. It's a surprising amount these days; React is getting so popular.

MuffinFlavored 7y ago
I wouldn't want to work on Polymer or Angular in today's job market.
- rovyko 7y ago
  Why is that?
  - throw03172019 7y ago
    I think he/she is implying everyone is using React which means no jobs for Angular devs.
    - jackdh 7y ago
      I can still see Angular kicking around for a long time too be honest.
      - k__ 7y ago
        Yes. Especially in Germany it seems to be on a high in terms of Web development. But when it comes to mobile, React-Native seems the way to go.
        bytematic 7y ago
        What is the competition in that regard apart from native apps? Flutter and Ionic are sorta different beasts
        7y ago

SimeVidas 7y ago

1.7 million users in Chrome? Wow, that’s a lot of React developers.

brianvaughn 7y ago
It's a little scary to upload a completely new version, when you know there's that many weekly active users that are going to be hammering away on it soon.

erikpukinskis 7y ago

React DevTools are very valuable. But only because React, with transpiling and the shadow DOM and all that is so inscrutable. There’s no hope of understanding the DOM with React, no hope of understanding styles with styled-components. There’s no hope of placing a breakpoint in your code and tracing forward through events. No hope of understanding stack traces. The DevTools begin to address some of those deficiencies. It does help, but still leaves me thinking the tradeoffs weren’t worth it. You can never reach simplicity, only manageable complexity. In the long run it leaves an opportunity for a new generation of tools that respect JavaScript and the DOM.

onion2k 7y ago
There’s no hope of understanding the DOM with React... You can still understand the DOM in a React driven app though. The component output is there for anyone to read. I do that every day. All React is doing is generating DOM content and then working out the smallest update necessary when the state changes. The problem that React Devtools addresses is that it's the component output that's there, not the components themselves. There's more information behind the scenes, and that is what React Devtools lets you peek in to. It does help, but still leaves me thinking the tradeoffs weren’t worth it. You have to reason about the way you write code, what your apps need, and what works best for your users. If the tradeoff is that using React's features means you can no longer work with the complexity of what's happening in the browser and that's slowing down your development process then don't use React. Your development process and your users are way more important than any framework.
- blueprint 7y ago
  > You have to reason about the way you write code, what your apps need, and what works best for your users. Not to use too-harsh language but that's a cop-out in my opinion. Yes, some tools are better for a given job than others. But we're working with general-purpose machinery for the purpose of building UIs and applications. There isn't really a differing set of requirements or problems in that domain. ... and if that's true, then it means that one size should actually fit all. I think, personally, UIKit is excellent. I think people don't understand how to use it properly… they don't understand how to write good imperative code, so they look to a declarative system as a way around that… but I think they're only deferring the inevitable or shifting non-problem-inherent complexity they couldn't initially solve.

JTenerife 7y ago

As if the improvements of the dev tools weren't enough, they've created a sweet interactive tutorial (https://react-devtools-tutorial.now.sh https://react-devtools-tutorial.now.sh)! Don't know it it's new, but I'am very impressed.

Vinnl 7y ago
Where they=brianvaughn (I see he's also left a comment elsewhere on this post), who did most of the work on both the tutorial and the dev tools.
- brianvaughn 7y ago
  Glad the tutorial is helpful! :) It was a last minute idea and I'm excited about how it turned out.

snazzycalynx 7y ago

Can someone explain why the permissions changed? The new version (in Chrome) wants permission to "read my browsing history", and other people are saying that it needs permission to "run when Chrome isn't running" (although it hasn't asked me for that one yet - maybe it was already fixed in the 4.0.1 release or something?).

mistyeyed 7y ago

Only had a cursory glance at the new tools but looks awesome. Love the new look and feel and the hooks inspector is working flawlessly. kudos folks!!

panzerklein 7y ago

Does anybody else get "Unable to find React on the page" error in private mode in Firefox?

dmitryminkovsky 7y ago

Great news. Excited to try it out. Thanks a lot.

notus 7y ago

Hooks still show up without variable names associated with them (I say still because I was using this before release). I assumed they would try to find a way around it. In the current state the hooks support is useless.

hnsocks 7y ago

Why trying to simplify complex usability ? This is just life support for react. So many better and simpler alternatives are there. Please use them..