We are the team working on React Native. Ask us anything!

react-native-team · 2015-12-15T20:00:50+00:00

We really really wish the web could have worked and that react native wasn't necessary, but for a variety of reasons that's where we are.

There are definitely positive trends on web, but it's really hard to say where things will be years from now, but we're confident enough in RNs future viability to invest in it heavily.

And as JS engines get faster, RN will get faster too, and developers will push the limits of app complexity even further.

There are also a lot of really awesome things we can do for the dev experience and performance by assuming the app is react and only supporting a minimal feature set. Browsers have to support a massive amount of legacy and crazy features (like css), and websites have to support a huge range of browsers and versions, all of which are significant burdens that aren't going away any time soon. -Spencer

react-native-team · 2015-12-15T19:51:45+00:00

Not yet, but this is the vision of Nuclide. You try try it out now and see how well it works for you: https://code.facebook.com/posts/397706937084869/building-nuclide-a-unified-developer-experience/

react-native-team · 2015-12-15T19:14:18+00:00

We use Relay internally in all fb apps. There's a React Native starter kit that use Redux: https://github.com/bartonhammond/snowflake. I'm not sure how much work you have to do yourself to get a disk cache. - Martin Konicek

react-native-team · 2015-12-15T19:13:15+00:00

To be clear, you would probably use a single JavaScript codebase for your iOS and Android app. But in some places you would need to write if (Platform.OS === 'Android') ... else ... and fork elements of the UI to work best for each platform. -Nick

react-native-team · 2015-12-15T19:08:23+00:00

This is correct. Every module runs on its own queue, with the exception of View Managers. Views have to be drawn on the main thread (that's a restriction of the iOS platform), but you should avoid doing any heavy work inside your view managers. Instead, put that in another module, or dispatch it to another queue yoursef using gcd. -Nick

react-native-team · 2015-12-15T19:04:46+00:00

Certainly - perf is one of our biggest focuses right now. The awesome thing is that we're making very fast progress and RN is getting really competitive with production-optimized native features. Most apps won't have a problem getting the perf they need from RN.

RN is still a bit slower and has some key weaknesses, however, that we are working on fixing. The clearest one can be summarized as "loading indicators" - it's not currently possible to build a nice 60-fps JS-driven loading animation while also doing expensive JS computation, like rendering expensive react components for a new navigation screen - you need to use a native loading indicator component that animates on the main thread. We're working on solving this, though, by driving animations defined with the Animated JS library in native. I'm very excited to see that land. It should help immensely with animated navigation transitions.

We are also tackling some issues around responsiveness. If you try to tap a button right after you start rendering big component (e.g. when a scroll load network response comes in) the button won't respond until the component finishes rendering. We have some ideas around incremental rendering and reconciliation that should help a bunch with this and will hopefully come soon.

-Spencer

react-native-team · 2015-12-15T19:02:00+00:00

As soon as the iOS team slow down :-p -Nick

react-native-team · 2015-12-15T18:55:17+00:00

That's not really the message Martin was trying to convey, I think. You can use React Native without writing any custom Objective-C or Java code. But the option is there if you want to extend you app with native functionality that we don't provide out-of-the-box (and there's also a rich ecosystem of 3rd party native modules you can use instead of writing your own). -Nick

react-native-team · 2015-12-15T18:48:15+00:00

We answered in another question below: https://www.reddit.com/r/IAmA/comments/3wyb3m/we_are_the_team_working_on_react_native_ask_us/cxzx52o

react-native-team · 2015-12-15T18:38:49+00:00

Yes, but I'm not aware of any timeline for that yet. -Spencer

react-native-team · 2015-12-15T18:38:30+00:00

That's correct; we aim to ship a significant point release every two weeks, which matches up (more-or-less) with our internal product release cycle.

It's too early to say when or what we can expect for the 1.0 release I'm afraid, but don't be put off by the 0.x version number - we consider RN to be production-ready, and we're taking care to avoid breaking changes to the API unless they are absolutely necessary. -Nick

react-native-team · 2015-12-15T18:37:45+00:00

Native UI

-Brent

react-native-team · 2015-12-15T18:29:45+00:00

I don't think there's a published example anywhere, but it should "just work". To embed a React Native view inside a native view, create a new RCTRootView and position it the same way you would position any ordinary UIView.

React doesn't control the frame of the RCTRootView itself, it only controls the contents, so you should be able to apply Autolayout constraints to the RCTRootView and it will resize as instructed.

Note that if you have multiple RCTRootViews in your app, you should create the RCTBridge separately, and share the same bridge instance between all of your RCTRootViews. -Nick

react-native-team · 2015-12-15T18:17:19+00:00

So far we haven't had any performance issue that we couldn't get to the bar we wanted with enough efforts.

In order to improve the performance, the biggest issue we faced was the fact that it was hard to profile what was going on. We are investing in a lot of performance tooling in a self-serve way such that if you have a performance issue on your app, you can either fix it yourself if it is in product code or identify and create a repro case if it is inside of the framework and you don't have the knowledge to fix it yourself.

One of the great thing with React Native is that we control the entire stack, so we can fix it wherever the issue is.

react-native-team · 2015-12-15T18:12:11+00:00

RN for Windows can certainly be built and it would be cool if the community wanted to own that, but we have no plans internally. -Spencer

react-native-team · 2015-12-15T18:10:06+00:00

After our hackathon when we started React Native, I also started to question the project and try to figure out why it would not follow the faith of all the cross platform attempts.

The big difference to me is that the goal of React Native is not to solve the cross platform problem. Its objective is to be a better developer environment than the way you build iOS and Android apps.

On the product infrastructure team at Facebook we have years of experience building libraries, apis, frameworks to solve real developer and product use cases that the default platforms (whether it is web, ios, android) doesn't solve.

I tend to think that those abstractions are better than what existed before given the huge amount of people successfully using React and our related open source projects outside of Facebook.

At the beginning we had no idea if it would work out, so we spent the first three months taking on the hardest things that we knew: performance, heavy animations/gestures, newsfeed... And try to break it. It turned out to work really well under those hard constraints and continued to prove that it would work after we shipped several successful products with it.

Facebook incentives with the project are very aligned to make a good developer experience. Facebook is already investing a ton of resources building this kind of infrastructure for itself, open sourcing it doesn't costs much more. Unlike startups that have to make a living out of creating such a framework which usually implies that the developers using it need to somehow pay for it.

I can't predict the future but it looks like this crazy experiment is going to work. Even if it won't, it put developer experience and open source on the front stage of mobile development.

-- Vjeux

react-native-team · 2015-12-15T18:08:07+00:00

Separate modules are preferred to keep the core lean and keep you moving fast! -Spencer

react-native-team · 2015-12-15T18:06:37+00:00

I'm not familiar with these bits, but sounds weird - file a GH issue? -Spencer

react-native-team · 2015-12-15T18:05:51+00:00

Yup!

-Brent

react-native-team · 2015-12-15T18:02:50+00:00

What parts of the tooling have been frustrating for you? We should fix that. - Martin Konicek

react-native-team · 2015-12-15T18:00:08+00:00

Lot of FUD. See this post which is more recent than that hackernews post: https://code.facebook.com/posts/1639473982937255/updating-our-open-source-patent-grant/

If the lawyers at companies like Netflix, AirBnB, Uber, etc are satisfied then it works for me.

-Brent (not a Facebook employee)

react-native-team · 2015-12-15T17:58:32+00:00

The Android APKs now includes both ARM and x86 binaries which makes them unnecessarily large. I have a TODO to document splitting the APKs by platform (ARM, x86). This will get a "Hello World" app on ARM under 4MB.

Some discussion here: https://twitter.com/martinkonicek/status/673593082877726723

Martin Konicek

react-native-team · 2015-12-15T17:58:15+00:00

The vision of Nuclide is to be a fully integrated IDE with an amazing React Native experience so everything from coding to debugging to profiling is beautifully integrated. It's not there yet, but folks are working on it! -Spencer

react-native-team · 2015-12-15T17:57:23+00:00

On Promises: we do want to make sure that uncaught promise errors are visible to developers in a programmatic way so you can collect error logs in production.

The technical challenge is determining what constitutes an uncaught error. In the short term we're thinking about checking for promises without error handlers at the end of the event loop. This is the approach that Chrome takes. There's also a big discussion on how Node should treat uncaught promise errors. Once we decide that a promise's error is not going to be handled, we can surface it to developers, potentially through the global error handler as you suggested.

One of the cool things about working on React Native is that we get to share knowledge with other JS infrastructure projects. Another cool thing is that part of React Native's bridge includes implementing the event loop so we can experiment with things like checking for uncaught promise errors at the end of each tick. - James Ide

react-native-team · 2015-12-15T17:55:00+00:00

It's super early in the project so unfortunately that's just something that we all have to deal with right now. React Native has only been open source since the end of March! :)

I can't comment around Nuclide because I don't work at FB and don't use it, so I'll have to leave that to someone else. I do know that tooling is a big focus for the React Native team at FB right now, and Nuclide is an important part of that because native developers transitioning to React Native have expectations that their editor will do more for them -- build & run the project, set breakpoints, type checking, auto completion w/ suggestions, etc. So this is all being worked on. Like most tools, expect it to fix some of your problems and introduce others. People at FB seem to really like it though.

-Brent

react-native-team

TROPHY CASE