F8 2015 - React Native & Relay: Bringing Modern Web Techniques to Mobile

good afternoon in his book creativity Inc Pixar founder Ed catall talks about his early days in the computer design and Graphics industry and what he says is this among the companies trying to solve those hard problems most of them embraced a culture of strictly enforced secrecy we decided to do the opposite to share our work with the outside world the relationships and the connections we Pro we formed Prov far more valuable than we could have imagined fueling our technical Innovation and our understanding of creativity in general so we think that Ed KML would have been right at home at Facebook engineering we also strive to share our ideas our Innovation and our software this afternoon in this room we're going to take you on a little journey how do we build our apps how do we work on performance all the way through to deep Dives on our data infrastructure and our developer infrastructure but to start off we have a session which I think many of you have been waiting for to talk about react and relay and yes react native it's my massive pleasure to introduce Tom and Jing and and first up engineering director Adam wolf thank you hi I'm Adam wolf and together with Jing and Tom we're GNA tell you today about a couple of components that we originally built for web that are working really well for us on Native mobile react and relay and the reason why they're make they're working well we think is because we designed them so that our apps would feel good and what makes an app feel good is the same no matter what platform we're talking about web native mobile or even desktop first thing you need if you want your app to feel good is basic reliability and last year at fa we talked about how react and the flux architecture that we designed to go with it help us make our apps more reliable and we gave this example of the unread indicator if you have an unread indicator on your app and you go to it and you have no messages that's really frustrating and even worse is if you have unread messages and don't know it and it's not too hard to get this right at first but you have to make sure you don't break this as you update your app really quickly and that can be tricky but we think you know we've got to handle on that with these two architectures that we've built with these two libraries that we've built and I would say the next thing if you've got reliability in hand the next thing that you want from your app is you want it to feel fast and if you're a developer like me when you think about what makes an app feel fast you might think about this this is the instruments panel that we can use to debug IO slow running iOS code and this is a really important tool obviously you can use it to find a glitchy animation or figure out why your scroll stutters um and it's an important aspect of the performance work we do but I don't think this is the most powerful lever we have to make our apps feel fast and I tried to illustrate what I'm talking about when the app when I want my app to feel fast with this little animation so you can see here I have my phone and it's got the usual uh Bevy of Facebook apps on it in addition to this catpick app that I'm working on so I'm GNA launch it now and I've got this cool little intro animation and when it comes up I'm going to start trying to interact with it but it doesn't do anything until finally the image is load and I'm able to scroll it and the scroll lags too which is really annoying and you know I don't know about you but for me I feel like this is the worst interaction I have with my phone what is it doing instead of responding to my input I feel like it should just do something and you know I I get so frustrated I want to throw my phone across the room when this happens and this is what I'm talking about when I'm talking about what makes an app feel fast so I think the question we need to be asking is how can we make our apps more responsive and you know to answer this question I think the other thing we can ask is like why are our apps unresponsive in the first place how do we end up in this situation and I want to illustr at this with an extended example of this cat picture app this hypothetical cat picture app um and how it might do image loading and I hope you'll stick with this long example because it's going to point out a lot of the ways or a lot of the things we want from our general framework for loading and manipulating data on the phone and to tell this story we have a few actors here right we've got the server because obviously we need to load these images from somewhere and inside the phone we have some resources that are actually highly constrained that's what makes mobile challenging right whether again whether we're talking about web or native there's the radio you know and it's access to limited bandwidth there's the processor obviously we're writing software we need a processor um and there's memory which is devilishly tricky to manage we'll get to that a little later and when we think about what needs to happen here you know I follow the book right I have these images they're objects in my UI thread and the way I encoded this is like you know we have this request we need to make so we need to encode this request using the processor and we need to send it to the radio and that takes time and then there's this long period of time where it's on the server doing something it comes back again you know it gets blocked on the radio and then there's this big decode step where the processor sometimes the GPU needs to turn these bits into an image until finally we can display it on the screen and when I show it to you like this it's like yeah you know of course it stutters actually like I'm surprised it works at all it's pretty complicated what needs to happen there um but you know the the reason why this app has this problem is because I encoded it wrong and the mistake I made was to think of that image as an object so we have a thing about quoting dyra on our team and uh I'm not going to read this because I'm not even sure he said it it's attributed to him but you know I don't know but I think it's hilarious and I think we can all agree that Professor dyra would not like objectoriented programming very much and you know frankly neither do I you know I think the when you take the state in your system and you divide it up into these hermetically sealed boxes you've precisely lost the ability to control how you orchestrate access to resources in that system we want a different abstraction for thinking about how to program the user interface and I'm going to drop it in here and in this case we're just talking about images remember I'm going to call it an image Pipeline and not by accident there's a project that we're going to tell you more about that builds out this image pipeline for Android so I hope you'll stick around in this room but let's talk about what this hypothetical image pipeline might do now what we want to do is we want to separate the concerns about how we fetch these images from their presence in the user interface and what you're going to what we're going to do is we're going to submit our requests into this image Pipeline and then forget about them and now we can interact with our user interface even while this process is going on in the background until finally we're called back with these loaded images and you know if you're a web developer you're out there like you know congratulations you guys invented the image tag good job um and it's true you know actually the web is pretty great in this way it's got declarative interfaces for most of these things that we like although at the same time you know the web is deficient in a lot of ways one example here is that the complications of the Box model and CSS mean that most browsers end up decoding images on the main thread so if you're scrolling and an image comes in it'll glitch so even you know no one really gets this right and again this is just images um but we actually have a much bigger problem than all that we'll take the Glitchy scrolling we've actually caused a problem for ourselves because now we've made it precisely so that the user interface is no longer synchronized with this heavy lifting that needs to be done in the background and now as a user I can do something problem aut atic I can scroll this before any of the images have loaded and you'll see at this point I've flooded the image Pipeline with request and it takes a little while for all these requests to come back and um you know this is uh this is actually you know a pretty big problem for our apps and if you're watching this animation you're probably thinking like okay we need to cancel those requests or reorder them somehow and it's true you know Advanced image pipelines do have those features but there's actually something more basic we need to do first which is we can't forget about this work that we've done once we've done it we need to drop in a cashier so that once we've made a request and it comes back if we don't need that data right away we have a place to put it and this cach can actually get pretty complicated right we might want to segment the cash by product or we might want to write a pretty sophisticated cash policy and again the web has an analog for this partially it's the static resource cache if you've ever sent a 304 header from a server you know what I'm talking about um and you know that thing actually doesn't have all the features we'd want again like you can't find out how big that cash is or even what's in it so you can't really write a cash policy like we'd want um so you know these components are pretty complicated but they do solve this problem of responsiveness the thing that we want to do now is bring it back to this general question of how we can build our apps so that they stay responsive and everything I've just said about images really applies to rendering if we had an asynchronous rendering pipeline we could desynchronize what's happening in the UI from what's happening in the rest of the system and if you've been following the react project for the last year you know that this is exactly what react does this is precisely the interface it offers last year at f8 we told you a little bit about how we think you should build a cache to go along with react and we called it this flux architecture over the last year we've built a ton of flux apps and we've learned a lot about what makes flux apps similar and we tried to capture that in a library that we call relay here to tell you more about relay is Jing thanks a lot thanks Adam so let's talk a little bit about relay what we think of as the next evolution of flux and what kind of problems it solves as I ad said we spoke last year about flux which provides a pattern for how actions flow through the system but flux didn't really specify how we get data from the server or how to organize data once it's on the client a lot of this was very manually hooked up and that led to some problems we Face the same problems on both web and mobile but let's take this example from our website the comment box on Facebook was one of the first projects to use both react and flux and it's also one of the most actively updated pieces of our UI there's always multiple teams changing its Behavior at the same time and it's not always easy for them to add new features so why is that well we'll take an example um stickers in comments were added just last year so let's see what we'd have to do to be able to render stickers in comments here's how the component tree breaks down we have a comment box component at the root which renders a comment list which renders a series of comment items so what do this mean for our data well we get our data from the server which meant that the data needed to be passed from the top of the component tree to the bottom so in this case comment box would fetch data from a store pass a subset of that to Comet list and then comment list would create a series of comment item components in this case each of the parent components needs to know about the data that its children needs and it needs to make sure that it passes along the correct set of information what this means though is that when we wanted to add rendering for stickers and comments we couldn't just change comment item we actually had to change its parent component all the way up the tree even to the point where we were generating that data on the server now imagine that you have three different teams trying to make changes like this they're all changing the same files resolving conflicts and worst of all they're adding implicit dependencies that the other teams don't have context on as you can imagine it becomes hard to maintain the sync over time and we were no longer confident at some point that we were only fetching the data that the render methods needed so this version is just too manual and too fragile what we realized is that we really that the component was the right level of encapsulation for this what we wanted in the ideal case is to only have to change the smallest component and here that's the common item component in order to fetch the new data and update the render as well well we already know that react components encapsulate rendering for themselves with relay we wanted to go one step further and also put the specification for data in the component level if we have the data query with the component we no longer have to fetch all of the data in one place on the server at once this makes it much easier to keep those two pieces the query piece and the render piece in sync and it makes it so that you only have to change one file instead of four when you want to make a small change in order to do this though really needed a common way of describing the data that a component needs that is a thin layer over any existing data model and that's exactly what graphql provides graphql is a data querying language we use at face book that was designed to describe the complex nested data dependencies of our modern applications so let's take a look at what the query looks like in practice let's say we're building this piece of a friend list um here's what the data payload we want to look what we' want would look like we want the ID so we can cach the object the name of the person the number of mutual friends we have and some metadata about their profile picture well what if we just took the names of all the fields in this data payload and kept the structure the same if we remove all of the values what we're left with is exactly a graphql query the query itself expresses the structure of the data that you want from the server and it's easy to tell just by looking at this query what we expect the server to give us back now you might be thinking this is a nice Syntax for clients but I don't want to rewrite my entire data layer in order to use this well the good news is that you don't have to graph is meant to be a thin layer around your existing data layer and it's just a way of presenting your data that's convenient for clients to use all right so now we have a way of specifying the data that we want what about composition well just as the render method for a react component can be composed of a tree of child components the data query can also be constructed based on the queries of components that it renders so with that we have the query piece and the render piece as parallel pieces in the component even though they're used in different phases one is used in the data fetching phase and the other one is used in the render phase putting them both in the same component makes it easier to keep them in sync makes it easier to make changes to a file so now that we have both query and render in the same component let's see what it looks like when we actually run this on the client what relay will do is take that data query tree and actually send it to the server when we get a response back relay will break down that payload and store it in our cache of graphql data and then it'll construct a set of props for the views to use now this is pretty similar to the flux pattern but instead of having multiple stores that are specific to your application relay has one generic store that knows how to consume graphql data having a generic store allows us to implement common product logic such as pagination that otherwise products would need to implement over and over again on their own so that's the read path relay also has built-in support for rights when we want to show the results of an action to the user immediately before before the server responds we'll often construct what we call an optimistic payload to reflect the state that we think the server will be in so when an action comes in with an optimistic payload Relay can notify the views that are affected by the changes with a new set of props that reflect that optimistic state relay will also send a right to the server and get a set of updated data back from the server and what it'll do is it'll merge that new data into its graph cache at that point the component that are affected by the change automatically receive an updated set of props as well this is pretty similar conceptually to how actions are handled in flux although relay makes this whole process simpler by managing which views need to be updated and making sure that we can do things like roll back optimistic updates on errors in a seamless way so now with this system we get what we wanted to do in the first place we can add stickers by changing a single component rather than changing multiple of the stack here's a piece of what our original query fragment for rendering comments looks like all we want to all we have to do to get stickers now is add attachments to the set of fields that we request from the server and then use that data in our render method this is so much simpler than the original version now we don't have to update four different files we just have one and rather than having implicit dependencies all the logic for how to render and fetch data for this component is encapsulated in the component itself now we we were trying to solve this problem in the context of web when we started out but actually we faced the exact same problems with our mobile clients and we could have you know implemented the same Solution on iOS and on Android but it's so much better if we could take a single solution and take advantage of it everywhere and react native allows us to do just that and here's Tom to talk more about it thank you awesome good job thanks a lot J so we introduced react two years ago and since then a lot of you have probably been a part of this growth it's been absolutely amazing to watch the growth there been plenty of talks about why we built it and how it works so I'm not going to spend a lot of time on that what I want to talk about today is why react has been so awesome for us at Facebook and why it makes so much sense to bring it to mobile with react native first let's talk about why it's awesome though react forces us to describe our views and break our applications down into components and these components serve as the fundamental building blocks of those apps and the views we don't in order to make changes to the entire system we don't have to keep in order to make changes to one part of our application we don't need to keep the entire system in our heads sorry about that but a lot of Frameworks have figured out that components should be the fundamental building blocks of our apps the thing that makes react rate is that it wraps the Dom's declarative mutative API or imperative mut ative API in a declarative wrapper now when we talk about declarative programming we're talking about describing what our program should accomplish instead of describing how it should accomplish it imperative programming on the other hand is focused on a series of steps that you should take in order to take what you have and turn it into what you want so when we talk about declarative views we're talking about describing what our our application should look like at any point in time what we found is that when we build using reacts declarative components we can actually move a lot faster and it's actually a lot more fun building this way so it's no surprise that react has been a home run for Facebook and we're using it across all of our surfaces and to be clear no one at Facebook is forced to use react Engineers are choosing to use react every day because it makes their jobs easier and more fun and we're not just using it for demo apps and prototypes or internal tools we're using it for real applications in production especially facebook.com but up until this point we've really only been using react to solve problems on the web and these days it's all about apps with the web we could build our applications using HTML CSS and JavaScript and then deploy those applications or deliver those applications to any device that has a web browser even some refrigerators but with these applications we have these imper these uh independent disjointed platforms that we have to learn and build on top of this is effectively B at our engineering organization but that's just one of the reasons why native development is really difficult now this isn't an exhaustive list but I want to I want to just go through a couple of reasons why native development has been a lot harder for us the first one and I think the most important one is developer velocity after every change that we make we have to recompile our apps on Native on the web we used to be able to just save our files and then reload our browser but even if we want to move some text on the screen on Native we have to recompile our applications so how many of you are familiar with this comic this XKCD comic right a couple of Engineers are slacking off but that's okay because their code is compiling now this is funny and while we're not necessarily worried about engineers slacking off at Facebook we are worried about the fact that they're moving a lot slower than they used to on web especially in a codebase that's as large as Facebooks and it's not just Engineers that are moving slower if you want to run an experiment or run an AB test on the web we push this site twice a day you'll have the the results of your experiment by morning but on mobile on Native mobile we have to release these apps you know we don't release them nearly as fast and you might have to wait a couple of weeks or a couple of months to get the results of an experiment back another thing that's really hard on Native is you often have to manually size and position your views on the screen and what this looks like is for a basic this is just the code to generate a basic Newsfeed story with four vertically stacked boxes it's basically just a lot of imperative math right I don't expect you to be able to understand or read this code right now but just understand it's a lot of imperative math and this is fragile and it's hard to get right on the web we had something better you know as much as we hate CSS we hate the Cascade it was declarative and it allowed us to layout our views declaratively and then the system would figure out where they should be on the screen on iOS we have something a little bit better called Auto layout but we tried this this didn't really scale for us it didn't it wasn't fast enough another reason that native has been a lot more difficult for us is because we can't use the technologies that we're building for the web directly in the native environment as Jin said the problems that we solved with relay on the web they're not specific to the web native mobile devices have these exact same problems and in some cases those problems are exaggerated because we have very typically very high latency low bandwidth environments on these devices so the native environment it's much more difficult to work with and it slows us down so why why do we work with it why do we put ourselves through all this Engineering in organizational pain you can tell these are software Engineers that are frustrated by the way that they're dressed by the way but but why do we do it honestly why do we do it how many of you raise your hand if you have an Android app or an IOS app okay let me count real quick everybody why why do you build Android and iOS apps rather than building for the web well at Facebook the reason we build native apps is because we can build better feeling experiences that are more consistent with the platform than we can with the web at least for right now and in the end Engineers are willing to endure a tremendous amount of pain in order to achieve that user experience so at this point what we found is that it's effectively impossible to produce truly native heing experiences with the web but there are a lot of reasons why the native environment is actually better suited to producing those experiences so even though it's harder to work with there are a bunch of things that it gives us a bunch of tools that it gives us that make it actually possible to produce these feeling these great feeling experiences for one thing in Native we have access to platform specific components there's currently no way to embed an iOS switch on a web page and what we end up doing is we reimplement these components using HTML CSS and JavaScript and we can do this this is tractable but it's difficult and it's cumbersome and additionally these these components as the platform changes our re-implementations they don't they don't update automatically we have to keep them up to date another thing that we have on Native is the ability to parallelize work on multiple threads let's talk about the threading model on the web there isn't a Threading model on the web right all of our applications code has to run on the main thread and browsers will optimize this for us and they'll do you know some image decoding optimizations and things like that but we can't manually schedule our images to be decoded off thread for example we also can't do asynchronous text measurement and a bunch of other things so this this is probably one of the biggest challenges of building high performance applications on the web we also don't have anything as sophisticated as the native mobile gesture recognizers on the web and we don't yet have the proper tooling or the developer discipline to build a system that gets this right nested scroll views are a lot harder to deal with than onclick handlers and on Mouse move and we just haven't built anything on the web that gets this right as good as the the native mobile environments to so while there are a ton of downsides to building native apps and we've given up many of the awesome benefits of building for the web we can't ignore the fact that right now we can produce better feeling user experiences on Native and a lot of people tell us we should just wait just wait the web is getting better we're going to have all of these features and more soon pretty soon you won't even need react because the the com the standard abstractions built into the browser are going to be just so good but listen we've been waiting we've been waiting a long time shifting mobile has really slowed us down but at this point we really know what we want we want the great user experience that we get with the native environment and we want the great developer experience that we get when we develop with react on the web so let's talk about the current ways that we can get the best of both worlds the first one is web views let's just use web views and we'll wrap them in thin native wrappers this will give us the ability to have push notifications and have an icon on your home screen but it'll also give us the fast rapid iteration cycle that we have with the web well well this is a great idea we tried this we built this um we called it face web and you know while it didn't scale with our application size and with a the growth of our team we actually think this is the greatest developer experience because you get that rapid iteration and you can use all of the great things that we have for the web but unfortunately since this is built using since using web views we have to use HTML CSS and JavaScript we can't produce those truly native feeling experiences the next idea we had was what if we ported react to Native what if we rewrote react in Objective C for example well we built this too this is actually a great idea so if you saw the talk yesterday this project is actually called components and components gives us all of the great benefits of react especially our declarative descriptive user interfaces and it gives us all of that access to the native technology that we need like we can do things off thread we can image decode off thread additionally components which was open sourced yesterday uses Flex boox for layout so that same code that I showed earlier with all that imperative math in it it now looks like this it's a lot easier to use and maintain there's only a couple of minor downsides with this approach for one it's written in Objective C so it's iOS only so if we want to take advantage of this system on another platform we have to reimplement it on that platform the second thing is that we can't out of the box take advantage of things like relay because they're written in JavaScript so the platform just doesn't you know we can't just integrate into into you know a components rendered view hierarchy with the data that comes from relay but the third thing that really stinks here and I think this is the biggest thing is back to my original point we this is written in native code so we have to compile after every change so we haven't fundamentally improved our developer velocity problem so what it sounds like we want is the ability to to combine these two techniques right we want to be able to write scripted code but for a native environment if we use JavaScript to script native API we should have access to all of the great features of the Native environment but that rapid iteration cycle that we get on the web we should be able to ex take advantage of some of our existing JavaScript infrastructure like relay and we could probably make this work this stack work across platforms since it's just JavaScript and JavaScript is ubiquitous at this point it sounds like everything that we want and it's no surprise that there's a ton of Frameworks out there that try to do this but we tried those two and unfortunately while they're a step in the right direction they didn't quite work for us and the reason they didn't work for us is because scripting native is tricky if we just synchronously call back and forth between native and JavaScript our UI could lock up while we wait on JavaScript execution this is exactly what Adam was talking about so we know we need to parallelize our JavaScript but parallelizing our JavaScript is hard for two reasons the first reason is because of resource contention if our JavaScript accesses something that might represent a resource on a another thread the system has to lock if we try to measure a view that's rendered on the screen for example from a background thread the system has to lock and get us that Dimension the other reason this is hard is because of the overhead that's associated with every single message that has to be passed between the native environment and the JavaScript environment if we need to cross the thread boundary often we have to pay this fixed cost over and over again so if we do this wrong this could make things a lot worse our application could end up feeling a lot wor than if we were to just build it exclusively in native code or exclusively in JavaScript but the good news is we know how to solve these problems we can solve the first problem by making our rendering a sync right we can if we never access synchronously access a resource from another thread and we instead in queue up the operations that need to happen we can let the system take care of executing those operations whenever it can and we can take care of this fixed cost of overhead by batching up as many of these me messages as possible and then delivering them all at once as many messages per Poss as possible per frame and delivering them all at once to the native environment asynchronous and batched we think these are the critical components of this architecture and the easiest way that we've found to get this asynchronous model is to describe our views declaratively describe what they look like at any point in time and let the system update them for us when it can this is exactly the application model that react gives us right so react components are just pure side effect free functions of our application State we never need to read from those rendered views in order to write to them react is non-blocking with respect to the Dom but the beauty of react is that it doesn't need to render to the Dom it keeps our views view systems logical hierarchy separate from the implementation of that hierarchy so we can just as easily render to UI kit for example this is why it makes so much sense to bring react to mobile and it's exact why we built react native react was intentionally designed this way from the beginning we didn't have to go in and layer on IOS and Android view systems so react native actually uses the exact same react that's on GitHub the only difference here is that with react native we render in the in the an embedded instance of JavaScript core and we render to highlevel platform specific components like View and text rather than running in the browser and rendering to divs and spans another really important part of react native is that we can adopt it incrementally we've learned at Facebook that incremental adoption is the key to success in large software systems and react native is no enables us to do just that as well so just like we didn't need to convert all of facebook.com to react in order to start taking advantage of of some of the benefits that we get with it uh we can adopt one feature at a time with react native wherever and whenever it makes the most sense another thing I want to CAU is that we're not chasing the right once Run Anywhere pipe dream the these platforms have different looks feels and behaviors so we should always be building separate discrete apps for each platform but we want Engineers to be able to learn the technology once and then build for whatever platform they want another thing I want to call out is that it's not important at all that we're using JavaScript for this JavaScript is just an implementation detail with a bunch of great side effects for example it lets us use relay relay out of the box and most of the what you'll see when you look at the GitHub repo for this is it's actually a lot of it is type- checked with flow so JavaScript just gives us a bunch of nice side effects but it's an implementation detail so enough babbling about architecture and implementation details we've been using this internally at Facebook for a while now and it's really working well for us everything I'm about to show you I'm going to do some demos now uh you actually have access to if you have an iPhone uh I'll demo most of these apps in a minute but the f8 app that you downloaded for this event if you have an iPhone this is 100% completely built using react native how many of you knew right our groups app that's also been in the app store for a while now is a hybrid app and this consists of both react native views and Native views so some of the views are written in Objective C and some of them are written in JavaScript and the beauty of groups is that it's actually powered the entire feed is rendered using relay so we get to take advantage of both of these infrastructures and the other app that we built using react native is our ads manager this app it's a very very very complex app there's tons and tons of screens and it feels absolutely awesome it was built by a bunch of Engineers some some fantastic Engineers but those Engineers didn't have experience with iOS or objective c they were able to build this app in record time and it feels great again but the best part about that team is that the same team after they shipped this to the App Store turned around and now they're building the exact same app for Android the same Engineers what we found is that the best people to build products are the people who understand that product so they should be able to build that product on any platform that they want so now I'm going to give some demos the first demo I want to show you is on an iPhone there it is uh so first I'll just real quick I'll go through the f8 app you know for those of you who've used this you've already seen this but we have like sticky headers on the left I'll jump into one of these sessions here you can see this uh detail view that comes up that animated kind of view at the top that animated header it's all powered by JavaScript all of this you see these great animations and navigation animations no one can tell that this isn't native because it is native but it's 100% written in JavaScript let me jump over to our groups app real quick I have a bunch of my groups here I'm going to dive into my family group my family's been talking and again you know here's a photo of me and my dad and this everything you're seeing on the screen this is all 100% built in JavaScript I can focus this comment box here my Mom leaving a little comment about the 4th of July um and again this is a hybrid application so some of these views are written in Objective C and some are written in native code or in um react native sorry the next app I'll I'll just quickly show a demo of this Facebook ads manager app so here's all of my ad campaigns and I have a list here I have some popovers I can filter a bunch of different ways um I'll dive into one of these we'll look at website clicks down here we have a graph actually let me grab another campaign that has some more a nicer graph here I can look at the the performance of this ad set over the course of seven days over the lifetime of it and I have these gestures these native gestures I know you can't see where my fingers are but I have these native gestures it's a completely native app and if I go over the settings page here you'll notice there's an inapp sound switch I can switch that on and off and that's a native iOS switch everything you'd expect so the next demo I wanted to show is is Android we weren't able to get the uh the display working so I'm hoping that we can kind of let you see it right here all right so this is pretty low Fidelity so if you want to come over to the open source Booth after this you can play with this in person but here's that same app but it's running on Android and you'll notice a couple things I mean there's a create button in the bottom right this is a material design construct we don't have that on iOS there's no tab bar on Android though so if I dive into one of these campaigns here you'll notice that we didn't get that slide over animation that we have on iOS that's an iOS uh construct on Android we have a different transition I can hit the hardware back button which again doesn't exist on iOS and go back to this home screen I'll slide out my Android Drawer here and then I'll jump over to the settings page and another thing you'll notice here is I have that same switch but the switch is actually an Android switch it's not an iOS switch sorry I'm incapable of doing this on stage uh but yeah so you know that same switch it's not an iOS switch it's an Android switch these are Android components this is a different app but being built by the same set of Engineers so now I'm actually going to jump to my laptop I'm going to write some code switch over to the laptop for me oh great so um on the left here you have the iOS simulator running and on the right I just have my text editor so what we're going to do first we're looking at that same exact uh ads manager app I'm going to go in here and the designers came back and they said you know what our advertisers need to be able to see their creative a little bit bigger can you make the photos larger so I'm going to come in here and I'm going to change the size of our image container I'm going to change the width and height to 60 pixels I'm going to hit command s to save the file I'm going to alt tab over to my simulator and I'm going to hit command R and just like that we have bigger photos thank you so the next thing they wanted they noticed a lot of apps are using circles these days instead of squares so I'll just real quick border radius we're going to just round these Corners off oh interesting invariant violation border radius is not a valid style property H I guess I spelled it wrong so I'll just fix that save it and reload awesome thanks for calling that out though but what I wanted to demonstrate there is that one of the things people love about react is it tells you when you do something wrong we shouldn't have to dig into logs to see that we should be able to look right at the thing that we're looking at and see our error messages right there so now I'm going to do something a little bit more interesting I'm going to go into my ads manager result summary here and I'm actually going to go down here to the end where we're fetching queries using relay in graphql this is a graphql query and what I want to do here is I want to actually fetch some data that we weren't previously fetching so I'm going to add in here the Run status info object and from that I'm going to affect the activity status description if I come up here above where we're returning this thing in my render function I can create a status status object I added some Snippets here to make it easier to type and you'll notice that results node. run status info. activity status description is the exact same thing that we started fetching here so results node. run status info activity status description now we'll just in our render function we'll just output that next to our subtext I'm going to add a little spacer here and then I'm going to come back over here and I'm going to refresh see that little active that showed up right there that is data that was not previously being fetched when I previously loaded this app and now relay has enabled us to fetch that new data you can't see this very well we can add some text around this we can add a component but that data literally wasn't there before and you know now it's modified the whole graphql query and we can show that stuff this is the developer iteration cycle we want you know this this is the developer flow that we want we want to be able to save our files and reload our editors I'm going to switch back to the slides so you know this is working for us this is really exciting the demo is fun we'll have more demos at the open source Booth but I'm not up here to claim that we've solve software once and for all right I'm just here to tell you that this is working for us we're really happy with it we're confident that this is the right programming model and the right approach to building all of our applications both web and Native the developer experience provement improvements here that we've observed not even that we're speculating about that we've observed are just absolutely awesome but we want feedback on it and we want help making this as good as we possibly can uh so that's why we open sourced it this morning uh cool again we're looking for your feedback we really want contributions on this we don't want everybody to change their development style right now we want you to help us out help us build this out and make it as good as it can possibly be the thing that I want to close with is this point okay Facebook does not hate the web but we're realists we just can't use the web right now to build the types of user experiences that we want the day that we can the day that the web is good enough I assure you we will use it I cannot wait for that day the day that it is good enough we will use it it but until then we will use this thank you very [Applause] much so as you've noticed we're running a little bit late the next session which is a deep dive into our Android products we'll start in exactly 10 minutes so 10 past one see you there thank you everyone