22 ms·
New React Developer Tools
- abritinthebay 11y agoIt really can't be emphasized how much better this version is over the last version. It's like going from IE Dev Tools in IE7 to Chrome Dev Tools. Night and Day.
- baddox 11y agoIndeed. I've been using it since they published the first beta, and it has seemed as stable as can be.
- arm55 11y agoSince the upgrade, I'm just getting "Connecting to react...If this is React Native, you need to interact with the app (just tap the screen) in order to establish the bridge." when I try to load the dev tools. EDIT: Apparently the tools don't work for local dev. Just hosted the files behind a python simple httpserver.
- spicyj 11y agoAny chance you can file an issue with a link to your site so I can look into it?
- arm55 11y agoIt's all local, sorry.
- brbcoding 11y agoThat actually may be part of the issue... I just spun up a server behind mine and it works now.
- arm55 11y agoYup. python -m http.server 8000 did the trick.
- theycallmemorty 11y agoIn chrome://extensions there is an option that lets you give chrome extension to content served from the file:// protocol - maybe that's what you need?
- brbcoding 11y agoSame here, trying to isolate the issue in my project, since it seems to work fine on fb.com
- jankassens 11y agoThanks for the report. spicyj created an issue to track this: https://github.com/facebook/react-devtools/issues/172 https://github.com/facebook/react-devtools/issues/172
- fspeech 11y agoPython simplehttpserver's default address is/was 0.0.0.0. You may want to check if you don't want to accidentally serve the whole world.
- joe-stanton 11y agoAn enormous improvement over the old dev tools! Good work FB team.
- nikolenkoanton 11y agoNice work! You did an excellent job on the instrument. Also very helpful in the development of the React! I also suggest check out MicroMono: New View of Microservices. Updated documentation is coming out in a few weeks. https://github.com/lsm/micromono https://github.com/lsm/micromono
- jallmann 11y agoLooks awesome. Does this still work with JSX that's been precompiled and/or minified? Eg, after a build step involving Babel, Closure Compiler, etc?
- spicyj 11y agoYup! Try it on facebook.com.
- TheAceOfHearts 11y agoWhoa, that's freaking awesome! Peaking at how Facebook is implementing some components should be fun.
- Ambroos 11y agoTry Netflix, their interface has some fun elements that are easy to recreate. Looking at the state and props (even modifying them) is a great way to get inspiration for your own components. Or messenger.com, which is an impressive React application too!
- felixrieseberg 11y ago> We're calling it version 0.14, but it's a full rewrite so we think of it more like a 2.0 release. I love React, but that just seems like a bad idea. Especially given the fact that the previous version was called "v2-beta".
- spicyj 11y agoDid we use that number anywhere? The only place you should actually see this version number is in your browser settings so it shouldn't really matter. Edit: Oh, I see we did. The version number in manifest.json and package.json was 0.14 though… I'll leave it like this but will bump it up to 2.0 if it causes any serious confusion.
- Exuma 11y agoGreat work on this Ben!
- jtchang 11y agoWhoa awesome! And it even shows you props, state, and context for each item.
- sergiotapia 11y agoDoes this work with MeteorJS? I'm going to try it out though, looks really interesting!
- tacone 11y agoYes it does.
- jakecraige 11y agoThis will definitely not work with MeteorJS. It's a React tool built around their framework. I don't think there's anything like this for Meteor yet. Unless you mean does it work if you use React within a Meteor app. If so, it may.
- ericjang 11y agoThe software engineering quality of FB's open source projects is simply amazing. I used to think that a lot of their projects were trying too much to re-invent the wheel, but now I see it as an uncompromising attitude towards having the most streamlined development experience. I also really appreciate the strong commitment to open source.
- philip1209 11y agoI find it amusing that Chrome, the Google open-source project that this is built on, receives so little praise in the developer community. Perhaps it is because Facebook builds things primarily for developers, versus Google which seems to be function-driven (eg bettering the whole internet instead of self-serving within the developer community).
- tacone 11y agoIt is not specifically built on Chrome. It happens to be developed on chrome because that's the tool of choice of Facebook devs. Incidentally, a Firefox version is now available.
- argonaut 11y ago> It is not specifically built on Chrome. > It happens to be developed on chrome This is contradictory.
- cjhveal 11y agoIn fact, it isn't. From a quick perusal of the github repo[1], it seems that the react devtools can mostly stand alone, and have wrapping shells that access the Chrome and Firefox APIs when necessary. Here's the plain shell: [2]. My understanding is that the GP was trying to convey this architectural flexibility while pointing out that the Chrome shell is more mature because it is the tool of choice for most devs at Facebook. [1]: https://github.com/facebook/react-devtools/ https://github.com/facebook/react-devtools/ [2]: https://github.com/facebook/react-devtools/tree/master/shells/plain https://github.com/facebook/react-devtools/tree/master/shell...
- mrspeaker 11y agoIf you're using a recent version of Firefox (like Nightly) you need to set xpinstall.signatures.required to false in about:config to be able to install the unsigned add-on.
- MrBra 11y agoReact is well designed and a nice work. It's the idea behind it that is totally flawed and doomed.
- spicyj 11y agoWhat?
- sergiotapia 11y agoIt's a shame you were downvoted, I enjoy technical discussions here. Can you elaborate why you think React's approach is bad?
- MrBra 11y agoBecause it's built on the assumption that just because DOM access is slow, then it's a good idea to just add another layer of JS in order to provide a cached-like faster DOM access speed, rather than focusing on fixing DOM access speed issue itself. React augments the complexity of a stack that it's already too complex, to an unneeded, non-sustainable and dev-unfriendly way in which we are supposed to use HTML tags inside JS scripts. React is just a Facebook's own short-sighted solution to slow DOM manipulation. The fact that it is OSS doesn't make it necessarily a good thing. React is not a product of love for a greatly engineered system, but obviously just a product of FB's understandable necessity to work faster "today and here", in order to keep bringing home their daily profit. React is not a solution, it's a patch, a ugly one. We are not forced to like it just because FB made it and made it OS.
- _pmf_ 11y agoSuccinct and to the point.
- mynegation 11y agoI wish you would start with this argument, instead of the one that looked very much like trolling. Can DOM be faster? Maybe so. Does that mean React is a bad idea? No. In fact, React is Multiple Buffering[1] in the age of DOM. It is not that DOM is slow, it is that change of DOM triggers the layout and layout is inherently slow, because it is complex. If you do not need re-layout on each DOM change (and most of the time you do not), React allows you to batch changes in a very clean way. [1] https://en.wikipedia.org/wiki/Multiple_buffering https://en.wikipedia.org/wiki/Multiple_buffering
- dopeboy 11y agoJust started a client project with React. This will be very handy. Thank you Facebook.
- quaunaut 11y agoSince the developers are here in this thread- I'm curious where this goes from here. I'm an Ember developer, but sometimes Ember's heavyweight attitude isn't needed for a project, and I see React as the natural direction to go when I want something smaller. Seeing something like this, and the strength of having developer tools like Ember Inspector or React DevTools, is just going to make frontend development so much easier.
- Cshelton 11y agoOnce you do web development the "react way", you'll probably drop Ember for every project and stick with React. Just saying. I've probably built over a thousand React components at this point. I've used all the other frameworks, knockout, Angular 1.x, ember. React is by far the better way to do things as of now.
- quaunaut 11y agoPersonally, I'm not as confident. I spent a week doing a lot of React projects, and while it's nice, it is what it is- a view layer. When interacting with a complex web of routes, models, components, and templates, I have found Ember to be similar to Rails in terms of expressiveness and speed of development. Then again, I don't know a lot of the tools that people use to solve these problems in React- the most I ever encountered was having to do most things manually, but having page layout managed by React. I was still managing my M and C. What do you usually use to ease the work there?
- k__ 11y agoMost people who say they use React usually don't use it stand-alone. When I say that I use React it includes the whole client-side stack. React, react-router (inspired by the Ember router), Redux, react-bootstrap and newforms. This is a bit like using Ember, Ember-Data, Bootstrap and ember-forms.
- quaunaut 11y agoThanks! I'll give it another shot, using those exact tools. Is there any guide out there for the usual application structure?
- 49531 11y agoMan, this makes you feel like vanilla html / css (and the DOM) are almost like browser machine code.
- aidenn0 11y agoWow, just played with this and it is insanely better than the previous version. Now I just need a feature to add to my react webapp so I can use this to debug it.
- iamstef 11y agoVery nice, good work!
- deleted 11y ago[deleted]
- laichzeit0 11y agoThis is going to be slightly off-topic. I'm mostly a "backend" dev (C/Java, server side things) that recently had to do some frontend dev again after about 4 years. The last time I did this jQuery/Bootstrap was the trend. So this time I played with React for about a month, then went to Angular (coincidently starting with React components and being an Angular virgin made me think of making everything isolated-scope directives in Angular). So the problem for me was not React being bad or Angular better but at the end of the day it has to do with: As a non-fulltime webdev I need a _complete_ widget/component library available for when I want to build my apps. With React I felt like I was constantly either having to look for components that kind-of/sort-of worked for me but had some short falls or I had to build them from scratch. Then there's the look and feel so you're either looking for components that are Bootstrap ready or Material Design-ish, etc. Even then, you take Angular Material: it's not there yet. Go to the website. That side-nav menu they have going is really nice. I wanted to use that in my app. Is that an MD component? Nope. It's a hacked together mess of custom things. Talk about "eating your own dog food". Is this common place in the web world right now? Regardless of choosing React/Angular/whatever. I mean I'm used to QT. There's a widget for just about anything. You just wire up your events and you have an app. It seems like the web world is slowly just going to end up reinventing Delphi at the end of the day when I look at things like Polymer (why has it taken so long?) All these frameworks are great but can we please just work on having feature-rich components/widgets now. And maybe keep them maintained for the next 5 years or so?
- vbezhenar 11y agoI had the impression that React's primary audience is developers who want full control over resulting DOM. While custom components are possible, you are expected to write your HTML, not wire up things and be done. You might want to check more enterprisy frameworks like extjs.
- mercer 11y agoCurrently that's the case, but I'd say React is a very good candidate for good component-based solutions; they're just not here yet. One of the reasons I've seriously been considering React for even a lot of back-end stuff is that it's really easy to create an isolated component that combines markup, styling and behavior. Once done, I can simply require() the component on either the back- or front-end, or both, and reuse the component in other projects. Granted, for styling there's still no solution that I consider optimal, but the advantages might be worth the 'impurity' of it all. And solutions are being worked on. And granted, there are other initiatives like Web Components that are hopeful. But already now React is a great option if you want to create 'independent' and re-usable components. I think it's just a matter of time before a proper, popular component-ecosystem arrives, and what with React Native, there might even be some degree of 'unification' across platforms. That's assuming we won't abandon React en masse and switch to another even cooler solution in a few years, though :-/.
- estefan 11y agoI've just started building the app I've been trying to build for the last 5 years again. I'm on about version 29 now. I've tried jquery, ember, angular, native android all with REST (which I found to be a complex time-sink), grpc (has potential but a bit too non-standard/bleeding edge), and was just looking at swagger when I came across the FB stack of react, relay & graphql. This is like heaven. No more faffing around with marshalling/demarshalling and such a simple API code generation on client & server aren't even necessary. Plus, react makes the UX incredibly responsive and in future I should be able to use the same server as a backend for native IOS and Android apps which I'm hoping should be pretty quick to chuck together once I've worked out the business logic for a website. It's like a different world since last time I did front end work, and I think this time I might actually be able to create the app I want to, while having something that's maintainable and boiler-plate free. Thanks Facebook!
- k__ 11y agoYes, I think the server part is the most annoying.
- dfischer 11y agoCheck out Meteor, it makes the server part easy. :)
- k__ 11y agoAlso it locks you in, which makes the server part annoying again. Something like GraphQL or JSON API might be the right choice in the future.
- estefan 11y agoI tried meteor shortly after it was released. It wasn't clear whether there was a path to making a native app and it felt like there was quite a lot of magic going on. I wasn't sure I'd get the security right and wasn't clear on whether it could scale beyond a single server. I preferred the idea of REST because I could drop in caching proxies etc and knew it was stateless. Of course, things might have changed now. I guess there's no parallel for react-native though, which is really the killer feature for me. GraphQL & Relay are really the icing on the cake.
- krebby 11y agoAny plans to make it integrate a little nicer with Immutable.js? Currently it's impossible to update Immutable props and have them reflect live in my app through React Devtools the way that you can with plain JS datatypes. What would be really awesome is if there was something similar to Chrome Dev Tools' "store as global variable" feature, so that I could edit props in the console and then pass back to React.
- spicyj 11y agoYes, we'd like to do that sometime, at least for viewing Immutable data structures easily. We already have "Store as global variable" if you right-click.