 Okay, everyone's here. Hello everyone. I'm going to give a very unbiased and unbiased view on React Native. So let's go over what we are going to talk about today. So for those watching at home, this is a tech talk at Pivotal Labs. So in Pivotal Labs Singapore, many of us have already tried React Native. And so everyone has their own opinions about this. Feel free to chime in whenever you want to agree with something or when you don't think that's the best way to do something. Not at home, but maybe like YouTube comments. Exactly. Okay, so I'll be going over the motivation for React Native. Why do we need yet another JavaScript framework to do something? Just a quick look under the hood. What makes it special? What makes it different? Some of the top features which I've come to love and where I feel React Native lacks and I'd love to see some more development in those. So Native apps, there have been over 200 billion app downloads when you put together both the stores, just Apple and Android. For whatever reason, which I'm not going to go into today, whether Native is the way to go or not, people like Native apps and they have their own use cases. Whenever clients come to us, they want us to build. There are a lot of clients who want us to build native iOS or Android apps. And most of the time it's like they want both. So they need cross-platform native apps and they do matter. What makes native apps different from, say, websites is that they are fast and responsive. They handle complex gestures and you have a consistent user story. Basically, the feel of the app is consistent across each platform and which is not reproduced by a website. But the main problem is when you want to target two different platforms, it turns out that building these apps is really hard. So when you're building cross-platform apps, you have different text apps for each platform. So Android has Java, iOS has Swift or Objective-C. Everyone knows this. There's no code sharing unless, I don't know, you're using C binaries or something. I don't know. And the other thing which is one of the main problems with using just native apps is that there's a slow hydration speed. So as the apps become big, you need to wait a while for compile times and testing on physical devices. It becomes harder. And there is this delay from changing a file to seeing it on your device. Who has already solved this? Web technologies. So for each of these different text apps, web technologies use HTML, CSS, JavaScript across all browsers. So you have the same code being used and you also have very limited build time. In most cases, you just change your file hit at five and you see the result. Again, there are problems with that site as well, but it's got this part right. And so it begs the question, why don't we just use mobile websites or wrappers? So what's the motivation for using native over creating a native wrapper around the web? Again, it goes back to the same thing about look and feel, the consistency across the platform. So these are just three small examples of the same basic navigation in the two platforms, iOS on the left, sorry, Android on the left and iOS on the right. You'll see that there's a huge, there's a big difference and there's a clear visual difference between the two. And other one, which is more subtle is the interaction. So if you notice this one, it's basically very similar, but the way they behave is different. If you put the Android version on an iOS device, the users can tell, even if they're not able to point and say, okay, this is what's different about this app, but there'll be something wrong about it. And this is the main challenge that mobile web faces. So native still has better performance. Mobile websites don't have complex testers. So you have basic touch and drag. Yes, sure. What am I looking at here? Is this a web app? Oh, no, this is the same list view interaction. It's actually implemented. But this is inherently it's inherently using the native version of the list. So it is, but what I'm trying to focus here is if you look at the drag gesture, you see that the interaction is different. One, the whole list moves down. And then there's a different kind of spinner. And Android is something else. You see the list doesn't move. This is very small subtle change between the two. And it's really hard to customize your web app to behave differently in these kind of small ways across different platforms. We want it to look like this. Exactly. This is what we want. This is what we want to achieve, which is hard to do with just wrappers, right? So other reasons is that you can't use native components. So Android does a good, great job with its calendar widget. So you can choose a date and all that stuff. And it's familiar to people. So when you're picking a time on Android, it shows up a clock and you can select drag and drag and select the time, which is a familiar interaction for people who use Android. And if you put that on iOS, it will not work. So if you want to use native components on websites, you need to make JavaScript mockups of these and try to achieve this, which is not really great. It's not a good experience. So what React Native is trying to do is get the great developer experience of developing web apps and apply it with native components. So you can build amazing native apps. And that's React Native. It's, as the name suggests, it uses React as its JavaScript site and it runs natively on your device. So let's quickly look under the hood. How does it work? This is just going to be an overview. So feel free to stop me and ask me more questions. I'll try my best to answer whatever based on what I know. Before we get started with the native aspects, let's talk about the JavaScript site, which is React. So this is common knowledge for both, this applies for both React Native and React and how the code is structured. So in JavaScript code, React is divided into different components. So React is a library that uses components that have props passed into it, which is some form of data, and internally contains state. And what React ensures is that there's a unidirectional data flow. So as you can see, data flows from top to bottom. So each component internally has a render method which it can call, it can render its children, which can be other components as well. Whenever a component state or props or anything in blue changes for that particular component, it calls the render method again. And this render method will internally re-render itself and its children. So that's basically the logic behind React Native. Can the state change without props changing? The state can technically change without props changing if the component is making external calls or something, because state is controlled by the component. Props are something external that's passed into the component and it's immutable. So that's the logic behind React Native. What this enables is, yeah, go ahead. How does components that visual that you like in components or? They are visual components. They are meant to be visual components, yes. So each each component has a view attached to it, a render method attached to it. And the graph, are they nested or? They are nested. So it forms a tree. We'll look at that and go ahead. Yeah, yeah, yeah. So even if you look at the implementation of the router, it is also just another component which has more components in it. Okay, so every render method needs to emit a virtual DOM. So the virtual DOM generally translates into HTML and even the router, it will have different tips which will be ready. So there is, even though there's nothing visually changing on the page, there's still a view component attached to it. So let's look at that. I'll dig deeper into rendering. So this is what a render method normally looks like. That's a bit hard to see, but let's hope it can work. Render is, the key thing about React is that render method is stateless. So it has no side effects. It only operates on data. It's a pure function of data. So here, this dot props are labeled. It's the data that's passed into this component. Similarly, this dot props or conflict is a function that's passed into this component as props. If you see this, it looks something like HTML tags, but it's called JSX. We'll look at that in a bit as well. But what it does is that if you notice, there's nothing else that's changing in here. So whenever there's a prop change, whenever the label changes or the on click property changes, it will change what's the output of this render method. But nothing else can affect the render method. So that's what, I mean, by stateless rendering. This example can also use state. It does mean, but I'm guessing it's just using property strength. So by stateless, I mean the method is stateless. The component might not be stateless. So really, the render method is a function of state and props. Yes. That's what I mean by data. So if you go back to the previous slide, anything in blue is data. So either state or prop. Is it worth saying that the render method is pure? Yes. It doesn't have any side effects. It's a pure function. Yes. Go ahead, Simon. Yeah, but on the next slide on the render method there, so this doesn't explicitly state that this is a react method code standard, but the tags in there, the layer correspondence to UI widgets, native UI widgets, can be the way you should compose the actual layout of your UI by substituting the text and UI components. So basically the render method looks very similar in React and React Native. The only difference is that React deals with HTML stuff. So instead of having view and touchable highlight, you'll have H1, H2, P tags, those kinds of things. In React Native, it provides a different kind of token. So you have things like view and touchable highlights, which are then provided by React, which translate into native views in each of the platforms. So in the documentation, there's a list of tags that they already provide. Those are what you can use. They tell you about the tags, and you just tell them it's a tags metric. Yeah. Yeah. Not always, actually. They don't tell you what it always marks because some of these, like touchable highlight could be a JavaScript implementation. It's just that this is a box. Any click in here will trigger some call on JavaScript. So it needn't be that this touchable highlight will turn into a button element or something in native. It somehow manages. So in native, there's some code that's rendered, which you don't need. It's abstracted away from you. So you don't need to worry about it. Which, let's see. So the output of this render method is a virtual renderer. So the JSX in React, this is some, it's like syntactic sugar. So this is using this. So this is actually for just React, not React data. But it works the same way. When you pass it through a Babel transform, this is what it comes out on the other end. So it's React.createElement div, which contains children, image, and h3. So as you will see, each of these tags translate into a React.createElement. And what this createElement does is it creates a node in the virtual DOM. So just a quick overview of virtual DOM, it's just a tree structure which is created in memory to represent what the document is supposed to look like. So whenever a render method is called, it creates a new version of the virtual DOM. And then it makes a comparison against the previous version. And if there's any change to any of these individual nodes, then what it tries to find the minimum number of changes to make to the previous DOM to make it look like a new virtual DOM. So that's how it tries to optimize its performance. But essentially you could think of it as every time there's a new virtual DOM, the actual DOM looks like the new virtual DOM. How it happens is again abstracted out from. So yeah, another thing to notice is each node that's created here has one parent and multiple children. So again it's a proper tree structure. So if anything changes at one node, that particular node and its children are affected. Now let's look at react-native method. So react-native takes all the react stuff that we talked about so far and puts it in a JavaScript engine which is running on a single thread in your device. There's also a native thread which is the UI thread and that's used to interact with, like it captures all your events. For example, there's a touch. So if you click on something on your screen, it's actually captured by the native thread which captures the event and passes it on to JavaScript. The bridge is some form of inter-process communication so that it can send whatever information it captures here into JavaScript asynchronously so that the UI thread is not locked and it appears to be pretty smooth. In JavaScript, you capture this event. You figure out what components are affected by this touch. You look at your virtual DOM and see which nodes are affected. You pass that particular touch processing into that component and see if anything changed in the render method itself. So the question is missing you, is that the developer's job is just like this path strategy or is that react-native does that for us? Yes. So actually you don't even need to subscribe. So as soon as you create one of these things like the touchable highlight that I showed you, it has a native component running on the UI thread already. So it knows how to talk to its JavaScript process. When you're writing a bridge you might need to be able to do that. I'll show an example later. This is really interesting. Is that literally two different processes or two different threads? Two different threads. But it could be two different processes as well. When it's running in your device I think it's two different threads but you can extract it out to do different processes. There needs to be some interface on both ends to know how to transfer the information with each other. So when you're doing debugging, especially it's two completely two different processes, I'll get to that as well. So again, it creates a virtual DOM, it makes a diff of the virtual DOM because of what native components needs to be changed and makes those individual native calls back through the bridge into the native side. So in case you're using iOS it triggers UIKit to make some changes, Android also has the Android UI. So it uses the native libraries of Android and iOS to make the visual changes that you see on your device. JavaScript, an interesting thing that I found out while I was researching this is that in iOS it uses the JavaScript code that's already part of your device. So it comes with Safari, right? So JavaScript code is what Safari uses to render the pages. In Android it also uses JavaScript code and this is actually bundled with your app as a library. So this means that the minimum size of an Android project is somewhere between 3.5 MB to 5 MB because this additional JavaScript library is packaged with your code each time. Thank you Android. The thing is each Android device has completely different like some have Chrome, some have something else. So you need to have a standard way of processing this and they chose to stick with JavaScript code. Exactly. So this is something I found yesterday. So next thing is let's talk a bit more about the bridge. We know that there are two different threads running, right? So it needs to become asynchronous. That makes sense. But it also means we can't use a single object anywhere and then just keep mutating it because if there are multiple cause happening there could be race conditions. So it needs to be immutable. It's also a serialized interface. This is actually a really cool feature of the bridge because one, if you're developing react-related plugins it is possible for you to capture this serialized information, record and replay them for testing. So that's actually a pretty cool thing that you can do when you're building react-related plugins which talk across the bridge. So the bridge is an object that's immutable? Bridge is just some form of communication. The adapters on both sides. It's just a representation here and the adapters talk to each other using some kind of serialized data. Serialized data is something like, it looks very similar to JSON. So it passes data. It tells you which elements need to be changed, create this bottom node, make this thing disappear. Those kind of calls. So there's a serialized interface that's passed. So is bridge actually a program that's sitting in the view? No. It is just a way for me to represent there is some communication between the two. It's an architectural concept. So if you wanted to write your own custom text you'd actually have to write and write on both ends. Unless your custom tag, if your custom tag doesn't depend on pre-existing tags and you want to make something that's completely new, you need to create something. Another cool thing about the bridge is that the processing is batched. So if there are calls that are faster than 60 FPS, they batch the calls together. So if you click on, you're really faster tapping and you keep clicking on the thing like more than 60 times a second or obviously there's some automated way of doing this. All the calls that are going through between these two threads are batched. So what the bridge, information passing through the bridge looks like is essentially just an array of different serialized objects. So one example of asynchronous execution is that when you have a remote debugger which we'll look at later, you can still interact with this thing while JavaScript is paused. So that's something that I found pretty cool about. Another thing I want to talk about before we start looking at some code is styling, which I'll show you some more in a bit. This is unique to the app native. It uses JavaScript to style everything. There's no CSS. So there's a custom implementation of Flexbox which may confuse people because there's a Flexbox for HTML and CSS as well but this is completely different and the same tags don't apply. So if you notice it's just a hash containing different objects. Something cool about this is you can have like if conditions and all that stuff in your styles. Though I wouldn't recommend you do this. So this is more powerful than SAS. So that's just an overview of some things that's slightly under the hood of React Native. Any questions? Not let's look at some code as it. So I'll start off by showing some of the things that I find really amazing about React Native. The first and foremost thing which many people here would agree with me is that setting up that back babble and all that shit takes like half a day, even more. And sometimes it doesn't even work. It's hot reloading, for example, is a feature that is really buggy when you're working with React or any other for that matter. React Native is really cool. It comes in with its packages, it comes in with babble, everything. So out of the box, it's ready to go. So these are the four commands you need to run to get your Hello World app running on your Android device. That's it. Like if npm is fast, you can get it done in under 60 seconds. And that is something that is just amazing about React Native and more frameworks need to do this. So let me just show you what running these commands looks like. Okay. So technically I've added a few more, like two extra folders in here, but imagine that source tree doesn't exist. Everything else you see here is what comes with running those four commands. You have an index.android.js and index.ios.js. That's a package as well. In the package, you will see... Let me make this a little bit bigger. You'll see that all this one depends on is React and React Native, nothing fancy about it. Come on. Yes, this is like the app manifest. This is a package file. Anyone who's worked with npm modules before will find this extremely familiar. Along with this, you have your android.js, which is your root file entry point for Android. And similarly, you have the same thing in iOS. It's literally the same code. There's no difference between the two right now. So this is basically the structure which I was talking about. There's a class called React Native counter, which extends the component, which is provided by React, and it has a simple render method in it which creates another thing called counter. Did you generate this when you made the app, or did you write this? This class is generated. I just created this counter thing just so that to make it look a little bit better. By default, it just says hello world, and these are the files you have to change, and this is the documentation you can look at. So you wrote this React Native counter to illustrate a little bit more with the default app generation. Yes, yes. By default, everything except the source folder comes with React Native, and that's amazing. By default, everything starts working. So let's look at this. Once you have initialized one of these projects, all you need to do is npm start. This one creates a package. This is not using webpack. React Native has its own package, and it listens to port 8081. And if I go into iOS, I just have to refresh. It loads from 8081. It says, okay, there's a request here. It's trying to find an index.ios bundle. The platform is iOS, and it's in dev mode. It's finding dependencies. It's packaging everything, and that's it. That's all there is to it. And this is a simple app, which is like you click buttons, and you just click this. Everything you see in here is native. That's interesting. So it actually boots it by loading it from its own... Was that a HTML or web page resolver or something that loaded? Because it looks like it boots that itself of the server. The way that you guys have been streaming a copy of it in the office, it protects itself of the server? I don't really get the question. No. It's running in dev mode. I'm running it in dev mode. We're probably running it in things like that. The version of the app that is deployed to the iOS simulator is looking for stuff on its files that are going to be populated. I'll talk about that in a bit as well. But the cool thing is this iPhone emulator is just running off the code that is defined in here. So this is the iOS package that comes inside ReactNet. Let me show you that. When you ran it, one thing it did was it built an iOS excellent project. When you do the initialization itself, it creates it. So there's this export project in here, which you just open in Xcode and hit run, and you get an emulator running your code app. It's that simple. In the next code, what does it actually run? Does it stand up? I don't understand what actually happens from the... What it does is it creates an iOS app with all the things in the native site, installs it onto your emulator, and then that emulator talks to the packageer to find what are the JS files available on your device, in your application. Does it do an interpreted runtime translation of the JavaScript, or does it do a transpiling into native code? Nothing. So this goes back to the bridge that we talked about. So JavaScript is running as JavaScript in a JavaScript engine. So this thing is pure JavaScript. And the output of the JavaScript is a virtual DOM, and the list of changes that need to be made to the native app to make it look different. For example, when I click increment, it says, go to this particular text box and change the value from 6 to 7. And that's the command that is passed across the bridge into the native site. So that's what's really cool about this, and it differentiates this React native from something like PhoneGap. But PhoneGap, the native site is just basically a glorified web browser. In this one, it's really JavaScript driving the native code. So that's what makes this stand out. So the view of all that is moving your own JavaScript and your new JavaScript. Yeah. That's it. So only the right-hand side has to change that. Yeah. I'll talk a bit more about that as well. Go ahead. So would I be correct to say, if I go to my package JSON, if there is some random JavaScript library or any independent module that provides, let's say, email validation functionality, I can just pull that in. That will actually be usable in my application as the JavaScript. Just call it that. Yes. Though there's a small thing to remember, many JavaScript libraries assume that you're running in the browser, and they access browser functions. If you do that, it's going to fail, because right now you only have a JavaScript engine. There's no DOM. And this is a problem we commonly face when you're working with NPM packages. Well, I think it's implied if it's targeting nodes specifically in front of your process. Yes. Yes. There's no multi-threading on this. They have to be purely abstracted by these. Yes. So something like Lodash works perfectly. But if you want something, say, that creates WebSockets. And you need it to be specific about the API. Yes. Yes. Yes. Mm-hmm. So let me do the same thing for Android. So all you need to do is you need to say ADB devices. Make sure that an emulator is connected, and then I just do React Native run Android. And that's one command. It packages your JavaScript files. It packages whatever is there in the Android folder of your code. And then runs it in an emulator. Runs it in a similar way. Yeah. You could. Yeah. So this will look familiar to anyone who's using Android. That's a same code. Yep. So now going back into, you know, the next really amazing feature about React Native is cross-platform code. Right? You are still using native components, but JavaScript code is able to talk to both platforms. It's amazing that it can use the same file for both platforms. And also you can have overloading. So let me show you what I mean by that. So in code, right now, this one, which is my index. Say I'm going to look at the iOS one. Index.ios.js, it is calling the counter. Counter is inside my components. And if I look here, all it does is it has this thing where there's a text that renders this.state.count. And then there's a button that says onclick increment. And all increment does is it increments the state. That's all it does. And the same code is running on both iOS and Android. Index.counter.js is just one code. But on the other hand, button, which is a custom component I created, has two versions. It's a button.ios.js and button.android.js. So let's look at the iOS app running here. So button.ios.js. I go in here and say it says props or label from iOS. I'll change this from this to say hello. Save this. And yeah, what happened? It is on by default. But maybe let me show you. Enable library load. It's not on. So anyway, I'll just do the regular reload. Come on now. Right? So this is in Dev mode, you have this help window when you shake the actual device. In iOS simulators, you can just have a shot. It's basically the same thing. Okay, so what hot reload is supposed to mean is that when you have DOM and you're changing just one part of the DOM, just that part is switched out. That component is switched out. Yeah. Yes. Actually, I can show that. So look at this. So right now it is this five and says hello Pivotal. And I do a refresh. It loses its state. Right? So now I'm in at six. And then I say hello. And then I save this. Okay, this is still lively. Okay. Yeah. We need to enable hot reload. There we go. So I'm in six. And then I go here and change in word. It changed the app. It changed the view without messing with the state. It's not doing a full view. Yes. Same thing. So I go into my styles and I can say, hey. I just saved. And this is something you can't do with native apps. Yeah. Yeah. Yeah. Yeah. Good work. Just abuse change. So in iOS, I go in here and say, where's the text? Oh, sorry. Counter.js. In increment, I will say instead of plus one, plus two, plus two. Right? Now when I click this, see? So it basically changes whatever JavaScript you change. And there are some weird edge case bugs that I've seen with this, but most of the time it works pretty well. And I'm really happy with that. Just to speak to cross-platform. But with platforms, what about the third platform? With Windows phone? Nah. Windows has a phone. Microsoft is just the opposite of that. They just remove it as an option. They might have. Yeah. They might have. I don't know. So. Cross. Yeah. Does it work when you create new components? Not always. Sometimes, okay, the thing is I have seen that sometimes the package does not work. So when you have a new component, the Watchman instance that's looking at file changes doesn't realize that there's a new component. Sometimes it doesn't figure it out. And you might need to restart that. So if you reach a part of the watchman thing, so whether the watch will become the default. So I think that it does sometimes. But sometimes it does by the watch. Yes. So it should figure it out. Basically, the use case, it's meant to be like quick changes. Like you make style changes or you change the text to make it, what would it look like on each of these devices? You can have three, four devices running and then you can try. And you can also use this on a physical device. So Android, if you're running it on your actual device, you can still link it up to this and hot reloading it to work even on your device when it's remotely connected. It's a kind of... Yeah. But... Yes. So in the past, this might actually be a problem if you work with it. It emulators on faster computers. I worked with it a few years ago. Pretty slow. Okay. The Android emulator. All the emulators were really, really crazy of all this memory. Yeah. How is this one? Is this one faster? Is it still a problem with the emulator being slow? Is it still a bit too low? Not too much. Not too much of a thing. It seems... Okay. But the thing is... Is it okay because of technology? Have you moved on? Or is it because of React Native? I don't think React Native in any way with emulator performance. But in general, for Android, we found that working with an actual device was always better. Yeah. So the emulator is better than the hardware. The hardware does help with the emulator performance for each and you don't have to re-generate it to get rid of the whole thing. Yeah. So that way... You don't need to keep hitting run. Exactly. Yeah. So... Basically, that's what this is. So, yeah, this is an app developed by Facebook. It's for their F8 conference. Even though they look really different. The left one is for iOS and the right one is for Android. They look really different. Most of the code is reused. If you will notice that the schedule in my F8 and all that stuff that's seen on the sidebar for Android version is at the bottom for the iOS version here. So it's just a slightly difference and the bridge component it's using to render. And by doing this, most of this stuff, which is like the scheduler stuff, it's the same thing in the background here. And this means that there's a huge amount of code reuse between the two platforms. And... I don't want to demo this much. Yeah. That's how you feel when you just change something and it actually changes on your phone as well. And you can have multiple devices connected to the same package. Next thing, this is also really cool. So let me show you on the simulator. I come on here. I say I want to look at my inspector. Click on this and it tells me the styling. This is basically like doing development on Chrome. I have like... I have performance analysis to see drop frames or what's going wrong and things like that. And yeah, there's like sysphrase. There's all kinds of stuff you can do. And you can also figure out what state and in that background, what about your state bar? You can use remote debugger for it. I will show that as well. So in-app inspector, really awesome. Debugging. Debugging. That's the next one I'm talking about. This is a familiar thing. You keep clicking next, next, next. You figure out what's happening. Debugging feels like this. So it's a very good feeling to work with React Native. It has these extremely clear error messages. Even when you have stupid errors like null is not an object or undefined does not have this thing. It tells you exactly where it was called, which file and it gives you these nice colored representation. Yellow means warning, red means error. So let me show you one example. And a lot of times where it actually can suggest a solution, it also gives the... Did you mean this? Yeah, here's the thing. My button expects to... So button.iOS expects there to be two props passed into it. There's an onclick and a label. It says onclick needs to be a function and label needs to be a string. Now, if I go into my counter... Let me show the app. I go into my counter and say my label instead of increment, I want to pass the value... I'm going to... Yeah, sure, why not? There you go. Let me just disable this thing. Hide Inspector. Check this out. It says warning, invalid prop type. It got Boolean instead of string. So you don't need to use prop types. You should talk about that. Yeah, you don't need to use prop types, but if you're using like ESLint or any tool that recommends the right way to... the best way to write code, it always suggests that you create prop types for any data that's passed and gives you like some level of type safety, but this is not the same as compile type. I know, yeah. When you specify it has to be a string again, can you show that code? Yeah, sure. So in the component, which is button, everything about the button is encapsulated here. You have the specs, titles, and the button itself. So here, you have prop types, which say that it needs to be a function or a string and you can say if it is required or not. So if it is required and you forget to pass it in, it will again give up on. What's the button's factor here? Okay, so I don't have specs on this project, but I just added it in there to show what the directive structure generally looks like. That's why you add your unit tests. So is it for... can it have more than one complex? No. You can have a complex one, which just says object. Object is just... It can be a hash or anything. You can be as... You can also say it's not required. So it's either a very specific form. No, no, no. You can have an object of this format where you have these keys. You can have that. Oh yeah, yeah. So there's some level of stuff. And with live reloading, as soon as you're editing, suddenly you see this yellow screen, and suddenly there'll be a red screen if you do something crazy as well. Yeah, but then again, all these things, right, it's the developer's choice to add the properties. So that way, if you're careful, you add the properties. But if you don't add properties at all, then it will not even come clear. You won't need it on this one. So yes, links promise you it will protect us. But yes, links promise you you do not have properties. Again, it's a choice. It's a slippery slope because people will be like, oh, I don't want these stupid error messages and you can disable it, but generally not a good thing to do. Next thing, live reloading. So now, what am I saying? Remote debugging. So click on this. It spins up a debug UI in Chrome. So now I can just look at my inspect and if I look at my console it's possible it's the prototype exception that's causing this. Seems like it's kind of hung. Come on. Android the problem with this emulator is that you can't shake it. So you don't have the options and the newer device don't have the options button on the bottom. So that becomes a problem. Essentially what it does is that in here anything you have like console logs will appear here and how it does this is pretty interesting. It, oh you can have breakpoints here as well. How it achieves this is by making a slight modification to the same diagram we saw earlier. What happens here is it replaces the bridge with instead of inter-process communication, it now uses WebSockets. And your JavaScript everything that we initially talked about the same thing now runs in V8 inside a Chrome app and there's communication using WebSocket. So native code still runs on your device and the JavaScript runs in Chrome. People have taken this to a crazy extent where people have installed this thing in Hiroko and your app can literally stream, every time you touch something it makes a call to Hiroko and ask Hiroko what should I change on my native app. So you can do that kind of stuff as well. Now if you have a library that relies on your web browser of V8 specific features you won't catch that error while even because in work here but not on your native yes I think yeah that's one So do they do anything to prevent that? I'm not aware of that I should actually check there are tests but I'm sure they would have done something like that I need to check, it's a good question. Yes So what you test in the, at least what we use in the debugger mostly was to see what are the props, what is the state and the data is what we do Yes I have not tried it I'm assuming it might but at the same time I can't be sure I need to check Most often what we do is we put like debugger like a breakpoint in the code itself and then just stop there and then look at the objects So I think we're running out of time so let me move a bit faster Next one which we really love is code push It's not technically a feature of React Native itself, it's a library by Microsoft What it does is it deploys your You need to configure for your application to have the code push libraries on Android and iOS What it does is it keeps track of your JavaScript files and every time you publish a news version of your JavaScript components it will dynamically replace the JavaScript files running on your users devices So people could have already installed it and it will live update and that's really amazing One of the, some of the cool features about this is that there's auto rollback So suppose the new version of JavaScript breaks something, it will roll back to an older version unless we do something Then there is segmentation, A-B testing You can also have different groups like you want to have a dev group, you can have a staging group and then you can have production Is this when the guys come to management to live before there is a copyright? Yes It's easy to work with especially in our agile methodology where we use a staging server and we want our product owner to see the latest version of the app instead of sending the new versions of the APK Do you know that that works with React desktop as well? I'm not sure I don't think it supports it right now It's only for Cordova and React Native on iOS and Android So this is a library but also it's not a library It's a service Is it free to use? It's free to use as of now But the big question we have is about the big question is about security and all that which is something we need to consider before we use this for a real client project One shortcoming of this is that if you are making new code that uses native aspects which so that means you are writing code that bridges the JavaScript native views you can't push using CodePush because the native components don't get published Only JavaScript files can be changed So do you know if anyone is using an improvement code push service we'll get basket jfc out of cell phones We'll get basket jfc Is that to be the there are some ratings CodePush makes it super easy to release a new version It's just this one command where you specify your app name and which platform you want to release There are also extra options like I want to release it to 10% of the people over this time period and things like that which is really cool So if you don't want to load your servers for some ways The other thing The other thing We were actually walking around finding people to talk to because it was so amazing We had to spread the word So another really good thing about React Native is that there's a lot of development happening, there's a strong community and there's also backing from Facebook so I think it's worth investing our time learning picking up this language because picking up this framework since there would be growth in the future So next I want to talk about some things I think React Native falls short on and some places some examples where it's not a good fit So one such example is this runkeeper app So this is the iOS version of runkeeper and this is Android version If you notice the views, there's extensive difference between the two views and also I'm sure that they're using a lot of native features GPS, it needs to use maps and all that So in this kind of scenario, what will end up happening is if you use React Native, you'll have to fork each and every one of your files a majority of your files This just ends up becoming very hard to maintain So in these kind of examples when we have clients with very different views across platforms it might not be a good fit But if you think about it in terms of the logical interaction that your component is performing you can probably still share all of the business projects that you're just wiring up to different views But that's For all you know, they probably wanted somewhat similar but because they were different developers it's entirely possible It's entirely possible But where it becomes a problem is if you're using separate views for both platforms and you're using native components there'll be a lot of bridging React Native is only used for your logic So that ends up becoming the next problem bridging code. One of the cool things about React Native is there's native interrupts so you can communicate with Android or iOS So doing that is also pretty fairly simple This is an example where iOS is talking to React Native All you need to do is call this RCT root view and you say that I want to target this one image browser app this is the component and these are the props I'm passing into it So props are also defined here and that basically just makes a call to this one It gets this new props So this is really basic So this is just a very simple example There are also more complex versions that JavaScript can talk back to native code and it can make view changes But the problem is if you're using React Native only for your logic and all your views are written in the native side there'll be a lot of this kind of bridging code and it becomes a kind of overhead Some places where you can't get away from using bridging code is when you want to use custom native components So this is I think it's a stepper counter for Android So if you want to use something like this and this is your setup app setup flow for your app you need to use custom native component The other thing is you need specialized hardware features so you want to talk to the headphone jack or something So this is one of the React Native The JavaScript side can't create new threads It needs to call the native side to create new threads So when you're building an interview in iOS for example you have to extend from the base parts or is there a way of doing So is there a prototype I haven't actually created much bridging code so I'm not very sure about that I'm assuming there might be but I don't want to say that unless I might see a nice native component custom but I don't have to reinvent it because it's inherent whereas if it's something I can import it in then I'm safe and double check and get back to you Okay Can I go over for another two more minutes and just finish it off Last couple slides This is the problem which we already talked about There are so many packages that assume that you're running your code in a browser or you're running it in a node environment and you have all these weird errors that happen because the new version of a library assumes that you're running it in a browser and add some extra functionality This is something that we faced with Firebase which Jason can talk more about as well When Firebase went from 2.4 to 3.0 they included a lot more features such as cloud messaging analytics and all some other stuff which required a browser to be present and that just basically broke support for ReactNet and these kind of things happen because it's not your mainstream when people make huge changes to well established libraries they don't consider ReactNet as one of the platforms they need to support Hopefully things will change but this is something you need to be comfortable handling when you're getting into ReactNet right now One way we have found to solve this is by using this site called JS Coach I can highly recommend this site because they have it's updated daily and it's curated so if something goes out of date and something is not supported anymore in ReactNet it'll let you know and another thing that's amazing is it tells you which of these libraries work on Android and iOS so you can say like I'm only interested in Android so I can choose only the libraries that support Android Those kinds This is a really cool website So those libraries are popular to use with ReactNet? Yeah So Isn't that favorite one? It also has so many React components which didn't show up here So I don't know if it would be better to do something to make it show up here Not sure They're not for ReactNet React also This has to be for React as well Okay I'm going to move a bit faster right now Unit testing is hard for ReactNet The reason being you're testing in a console You don't have access to any of the native components So how do you do this? You essentially replace your ReactNet with a mock ReactNet and what mock ReactNet ends up being is just React So you switch back from ReactNet to React and you replace all your all your native components like views and list views with just divs So it becomes like a tree with just divs in it This becomes a problem because when you have components that contain logic like for example this Recycler, ViewBack ScrollView, you can define things like okay I want to only show the first five and then later slowly load the next few This logic cannot be tested at the unit level, you need to write integration tests for this So all you can do in a unit level is say that hey I expect ListView to be present and I expect ListView to have the props ListView to renderRow which is equal to my renderRow, something like that So the tests you can do is black box tests that say is it present? Yes or no? Are these props being passed into it? Yes or no? That's all you can do So it's kind of limited You can obviously test logic better but for ViewTest this is something I found to be pretty limited And when you go to integration testing there are all these tools that people recommend Appian, Espresso, Xcode, Robotin, all these things are essentially tools for individual platform, Android or iOS You can't write just one set of integration tests that run across both platforms and that is also something I hope will change in the near future, like you can write JavaScript integration tests and that will just run on both devices So with that I am ending my presentation, so I really enjoyed React Native, I found React Native to be very easy to install, to use to debug and to even deploy using code version It's really powerful because unlike other web wrappers you have access to native code, you have multi-threading and it's really fun to use, something What was that? Come on GIF fail Hey This is tutorial We did try to create a wrapper application for a free web store Because all the things you mentioned are advantages and disadvantages, I feel applies equally well to pre-build labs So the main difference is one, you just get this way out which is obviously cool Two, they have a lot of pre-built components that already provide native UI But that seems to be the two main elements, just to list the ASUS and Fedoba and Fedoba has passed the out-of-down job If you build your website right, you can most of your statements So that's where there's a difference in the way you build the application, so when you come into React Native, the amount of effort required will be much higher But then compared to Kodoba apps, because it's not running performance is better, and it feels more native So that is the primary difference between the two, and since Kodoba is also having plugins that can connect to Android and iOS you could technically use that But when you have to work with both your web app and native code simultaneously, it gets kind of mess, here JavaScript is always talking to native and there's no HTML anymore, so it's much easier to work with It's curious if you have verified a thing that becomes messier, because the parts that sounds to me like it would be a messier are the same parts that you mentioned for example you mentioned that it gets messy when you have things in your browser that could be an iOS and Android, that are the parts that would be mostly messy with Kodoba as well, so that problem still exists I mean, when it's vastly different I'm talking about small changes like what we saw, we can have overloaded JavaScript files, right? Yeah, we can look it over too You just have one that runs on iOS and one runs on Android Isn't it the case that if you're going to your app and going to your goal is to have something that is available on the website, in that case for Kodoba whereas if you're bringing an app me, then the app should be available then Oh yeah, I think so There are completely different use cases both the same and whatever Let us think that there could be more of a reuse from doing the rapid defense, but if you have a lot you know the app is going to be all used and you do need performance There's no question There's another point here where when doing a particular device it's a specific version and then you have browser rubbish you've got to deal with that That's a very good point Then you don't know until you deploy to a thousand devices that demand a significant portion of your user base code and you're going to have a free video Other devices that doesn't support 3D versus the one that sends down your iTunes Any left on the wiring and all the stuff that you're going to want to do and you will be able to have people in X number of years bonus problems But the future doesn't have to know about it So, if I want to target both the iPhone and iPad do I have to change stuff? Interesting question I don't know Actually, that's an obvious iPhone and iPad I think that because the iPad has a small way of state there's like a mask When I open it like that I can see that it's like a bar for example So, there are two ways to do this separation of dot IOS You saw the I difference right? You had dot IOS and dot Android IOS Similarly, there is another way to achieve the state but in the final difference actually inspect what device it is and then make that difference So, maybe using that you can actually have a different question Actually, I don't know if you'll go for iPad Imagine if you're using Flexbox So, the thing is when we run it on an iPad it just looks like when you run an iPhone app on an iPad it just looks this like really stretched out zoomed in It's not, by natively I don't think it supports This one? Which one? This one? Oh, yeah That's a good idea Let's see Yeah Hey, it looks pretty okay Maybe, yeah It might be okay to work Yeah, I think it does Cool, thank you Yes, Stefan