JavaScript Jabber

JavaScript Jabber is a weekly discussion about JavaScript, front-end development, community, careers, and frameworks.

Subscribe

Get episodes automatically

228

228 JSJ React Native with Nader Dabit and Mike Grabowski


Code-sharing between mobile and web apps with React Native

Using native code and Javascript

What to know about developing with React Native

The importance of tooling

Live and hot-reloading

Updating your app on the fly

Possible difficulties faced by transitioning to React Native

Bridging between native API’s and React Native

Writing apps in Swift or React Native

The future of React Native

How to start a React Native project

 

Resources:

Frontend Masters

Hired.com

Rollbar

Microsoft Code Push

React Native Radio Episode 8

Tadeu Zagallo’s Website

This episode is sponsored by

comments powered by Disqus

TRANSCRIPT

Nader: My name is Nader Dabit, we work at a company called School Status in Madison, Mississippi. We’ve been using React Native for about a year and a half and we develop mobile apps and desktop apps and also web apps for K through 12 schools. We do data visualization, we have schools in the South East of United States for the most part, and yeah.

Mike: I’m Mike, I’m a React Native core contributor. I’m also the co-author of RMPM that has been recently merged with React Native and is now knows as a CLI. I’m also a co-founder of coldstack.io which is a software house delivering React Native apps to our clients all over the globe. I think that’s all.

Charles: Let’s go ahead and start at the beginning and give people a quick sketch of what React Native is. I know we’ve done other shows on it but I like to just get the simple stuff out of the way so we can ask all the deep questions.

Nader: Yeah, I hope I can give you a quick overview from my point of view and why we like it and why I like it. It’s basically a way to build native performing mobile apps on Android, iOS, and also they’re already targeting Windows and Desktop applications using mainly Javascript. Basically, the difference between React Native and something like Cordova is instead of actually running a web view like Cordova or a Hybrid app would you, you’re actually accessing native components of the performances, really nice. You’re also able to access the native APIs directly just using Javascript so it’s really great for web developers or Javascript developers looking to get into mobile development because you don’t really have to learn a lot of other things, you kind of use your existing knowledge to be able to build these really high quality mobile apps. It’s got Facebook, it’s built using React so if you already know React, it’s easy to jump into because it’s using very similar syntax and you’re also using the same state and props that you’re used to when you’re using React on the web but you’re able to target these other platforms.

Charles: It works over Javascript Core. I’ll put a link to that in the show notes to the episode we did on the iPhreaks Show for Javascript Core. I also should point out that Nader and Mike and several other folks get together every week and do a show called React Native which is part of devchat.tv. But I’m wondering, I know people are listening to this and they’re going, “Well, I keep hearing that I should write my applications with Swift or with Objective-C or with whatever other Native technology, I guess it’s a form of Java in Android.” Are there things that you can’t do with React Native that you can do with React Native?

Mike: Mostly no. I would say like the power of React Native is that you can write Native modules. Essentially, in case there’s anything missing if you’re writing a mobile app, if there’s logs and controls are missing or some bluetooth interactions are missing, you can always ride them.

For example, we have been recently writing a media player in React Native. There is no module available to control the media player natively and controls so we just rolled the missing APIs and just brought them to Javascript so that it was totally doable from the JS without actually writing any Native code by other developers. That’s a very, very, important feature of React Native itself, plus the Native module itself are very, very, nice obstructions because you can write them without actually being an expert in either Java or Objective-C.

For example, our developers that have little Native knowledge can usually write some very, very, simple Native modules by just checking out the documentation and checking out the Native APIs and just going for documentation. If you have some Native knowledge or if you have a Native developer inside your team, you can always ask them to part like a Native complement for you so that you can use them from the Javascript so you can always extend it. I wouldn’t say there are any limitations, there might be some limitations out of the box but if you can write some things and if you know how to overcome them, you can do pretty much anything.

Jamison: I have a question about something that was kind of touched when React Native first came out which is this promise that you can share a lot of code between your Native application and your web application, if you’re building a web application in React. In practice, it’s been out for a year and a half, a couple of years now, do you feel like this is a thing that happens a lot in practice or is it mostly just a tool you use to build cross-platform mobile applications and it’s a little more theoretical still, the idea of sharing components for example or flux architecture between your mobile and your web app?

Nader: You’re talking about maybe sharing the exact code between the web and the mobile app?

Jamison: Yeah, I mean obviously the way underlying—devs don’t work on React Native and the Native wrappers or the components that are wrapped around Native iOS things won’t work on the web. But at some point, it’s Javascript and you can share that stuff. Is that something that people are doing a lot of?

Nader: Well, I can tell you for one thing, we are sharing a lot of other data architecture. If you write your data layer in Redux or NFlux or maybe even Mobex, you can use that exact code in your web and your mobile app as long as you’re kind of working with the same data structures. That’s been really nice. There’s actually a project out there called React Native Web which actually compiles React Native code into web elements. Basically, what you use—

Jamison: The tables have turned.

Nader: Yeah, exactly. It’s just kind of crazy. If you’re still using Devs in web, then you would be using something called a view in React Native which functions very similarly to a Dev. Basically, what React Native web would do, it would take the view and you would be able to compile your app down into a web app so your views will be compiled down to Devs, your styling would be compiled to CSS or to Javascript styling and your text elements would be compiled to paragraph elements or spans. That project is still in the works. Once that gets a little more robust and a little more stable, that idea of sharing web, mobile, desktop could be a viable option.

Mike: Yeah, like in the applications we are doing for clients, we got a lot of requests about sharing what they have already done a new app with React Native. For example, currently we are working on an application that already works with React JS on web, it’s fully deployed and kind of has a year of comment history. What we are essentially doing is we are just writing fuse because the logic as Nader said his readers serve actions, they are already there so we can just share them. We don’t need to write any additional logic.

Of course sometimes there are places where you have to write something platform specific but like speaking for Javascript, data layer can be fully reused if it’s done properly. As far as Native modules are considered, you have to think for yourself where to draw the line between the Native code and the JS code. For example, when we are doing some media player stuff that I previously mentioned, we had to find a good balance between the Javascript interface and the Objective-C of Java code so that we can not only write something that works on old platforms but can be also reused 100%. We decided to go with as little Native code as possible so that you can control the player for example from the JS. You can do all the shuffling from the Javascript.

Essentially, our Native interface was just a set of four menus like play, stop, previous, and next. That was all. Thanks to that, we could reuse almost every crucial piece of the logic so that if there was a bug on iOS for example that we’re using, was stopping in the middle of a playback. We know it’s an issue in our JS code that is probably happening on Android as well. Thanks to that, when I fix this on iOS I was pretty sure the bug is going to be solved in Android as well. It’s always a matter of finding a good balance, how much of Native code there should be written and how much of JS there should be in that code. I think it’s totally possible, it’s just that you find that balance and just to stick to it.

Charles: Related to Jamison’s question, what else do I need to know besides what I would know if I’m familiar with React on the web?

Nader: I can tell you in my experience, because I came from web development into React Native, but I’ve done a lot of hybrid mobile development before I got into React Native. One of the main things that coming into building Native looking and Native mobile apps vs Hybrid or web apps, one thing they have to kind of think about is certain UI elements that are platform specific. Android has a certain day picker that they use across most of their apps and then they have toolbars and there’s pickers and all these different Native implementations.

Thinking in that way is one thing that you have to kind of start doing when you move into this type of thing. But as far as just being able to grasp the language, if you’re a React developer or a Javascript developer, especially if you’re a React developer, all of the actual syntax and the actual language and building the actual components is very, very similar. There’s a few things that are different, things like ticking as far as your styling goes. We don’t have CSS, what we do have is something that’s very similar, they’ve actually put it over flex box, or flexbox implementation I should say into React Native that allows you to do a lot of the similar styling that you used to do in CSS with slight differences.

I would say you can take a lot of your knowledge and be able to get up and running with React Native fairly quickly. If you’re using React, I would say very quickly. If you’re just coming from Javascript like if you’re an Angular developer or just a background developer and you want to pick up mobile app development, I would probably say take a look at React and understand the React life cycle and how props and state work and then kind of jump into React Native after that.

Mike: I will also say that tooling itself is important. What I have seen across JS developers, web developers coming into React Native, the knowledge of Xcode, the knowledge of Android Studio, Gravel and all these Native tooling is super important if you want to ship your app actually. Things are different in mobile site, there’s no web pack and shipping your app is not just a matter of using a service. You also have to know how to create an account on iTunes, how to deploy your app, how to manage all the certificates and stuff.

That was also one of the reasons why we have built RNPM, just because linking Native libraries was super hard for users because essentially on the web, you just install something required and it’s done, it kind of works. But on the Native side, on the React Native side, you have to link your libraries, you have to add some Native code, you have to bundle other Native dependencies so the process itself is way more complicated and you have to think of all the steps. I would say tooling is important as well because we just have to know the process is different and there are a lot of things that you have to consider when you’re about to deploy your application and once you make it available for users.

Aimee: Can you actually go into a little bit more detail on that? You guys first touched on about being able to use FlexBox which is different from my understanding of what you would do if you’re using Swift or something like that. But then another cool thing is that if you’re using React, you can do hot reloading but then the other thing that I’ve read is that you don’t have to go through the app store to update your app. I guess I’m bringing up all these things because I just want to see if we could talk a little about—everybody says how great it is to share code but it seems like there is actually also a lot more there other than just being able to use Javascript and just being able to share code that’s really valuable because you’re just using Swift.

Nader: I can actually see those things that that were very beneficial for us. We have a few Native developers in our company. One of the main things that they said was a huge benefit and a draw for React Native versus Native development was the fact that we do have the loud reloading and the hat reloading. The hard reloading as far as being able to just save your app and being able to update the state of your app without having to compile it.

A lot of times if you’re developing a Native app, you have a compile time and compile step of anywhere between a few seconds to maybe a minute depending on how large you are or the net you have. If you have just a small UI change, sometimes that would get really frustrating and the developer time would be extremely long just to make a small change. It’s beneficial for companies because you’re able to kind of develop apps a lot faster. That’s just one of the ways that it improves your speed of development.

You mentioned the remote updating app store, yeah there’s a lot of services that are built now and a lot of different implementations of that as far as being able to update your app. Basically what you do is you build your initial version of your app, submit it to app store and then as long as you’re not updating any Native code as far as in the actual Objective-C or anything like that, you’re able to remotely update your app using one of many services. One of the best ones right now is actually Microsoft Code Bush.

Microsoft has built a really, really, nice way to do that. Nice API, it’s free, it’s really easy to use and you can basically update things like you would on the web. If you’re a Native mobile app developer, you might be used to waiting a day to a week to update your app in the app store whereas if you’re a web developer you can update it on the fly. That’s a really beneficial thing as far as React Native goes.

Jamison: I got an interesting thought in my mind which is that as a web developer, you might not have an idea of what the constraints are of the Native platform. Sometimes, some of the pitches that I hear for React Native are like, “If you’re used to this crappy thing about mobile development, check out this awesome thing.” It’s like I didn’t know that was a crappy thing, I just thought that you can just deploy code easily or build faster, whatever. It seems like part of the pitch for React Native is making web developer aware of here’s what it’s like without it.

I have a question about kind of what—Chuck already asked how much of the experience transfers over. I have quite a slightly different take on that question which is, if I’m a web developer and I get it into React Native, what’s going to be hard for me besides the obvious things, of like writing on Objective-C or Android code or whatever. What will not be as seamless for me?

Mike: I feel like tooling. Tooling I think is the hardest thing you’ll have to kind of check out before you actually start writing. I feel like for example on iOS, obviously React Native shifts with the common lines tools so for example you can run your app on iOS on the simulator or just come online and you can run your app on Android with the common line as well. There are times where you have to open the xcode and you have to check out—you have to bundle your app, you sometimes have to change the release scheme and do a lot of configuration stuff. This is not something that web developers are used to.

An x code interface is not the best interface ever made so sometimes people get confused how to change things and even to understand why these thing require, especially given that Apple is kind of super strict about what can be inside the app, what cannot be inside the app. It has a lot of security concerns you have to consider and you have to for example set up. Sometimes with the iOS 9 release, you can’t just access a random server because they are whitelisted now. If you are about to access resources you have to whitelist them in the configuration. These are the things people are sometimes asking,” Why is this required?” Or for example, “Why is my HTTP services not working?” These are the things people are kind of trying to figure out and these are the hardest things I think from my experience that are the biggest breakers for web developers when they are trying to actually write and where they give up.

Aimee: I feel like in some podcasts that I was listening to, they start to go into details about this but I was on a run and I was like half paying attention because I was running really hard. I would like to actually go

Charles: Like running away from something?

Aimee: No, running on my run own around the Harvard. I was probably really hot so I’m half paying attention. I’m actually super interested if we could get into not just like talk about it at a service level but actually get into the details about how it works bridging between the Native APIs and React Native when React Native doesn’t support something.

Nader: Mike, you might want to pick this question up because I know you’ve done quite a bit of that.

Mike: I know that question was going to be asked after all.

Speaking more in details, there is a very, very nice presentation given by Zagallo which is the guy behind iOS of React Native. I’ll share the link later after this stuff where the bridge itself explains very, very much in details. Speaking very briefly, how bridging between the Native Code and the JS code works is that for example on iOS, you create a class which is extending some React Native internal code. And then inside this class, you have to define that your Native Code is going to expose to the Javascript.

For example if on iOS you have [00:23:07] that can be called called a number, you have to wrap it with a marked which is called RCT Expert [00:23:14]. As soon as you wrap this with this micro, this is going to be available on the JS site and you can actually call it.

On a very, very, high level, when you wrap these with the micros that are available on iOS, then doing the run time of your app, all these informations are collected into a huge Jason and then that Jason is then transferred to Javascript and based from the information that was provided in that Jason, React Native is able to actually kind of build the dynamic API based on that file.

For example an array, there is a new information that your code is exposing for example ten Native modules and all these ten Native modules have some certain [00:24:04]. Based on that information, it will prepare an object for you where properties will be the names of your Native modules and each of these properties will have another object inside with properties that will be the names of the [00:24:20] you can actually call.

The API is built dynamically when you’re up start based on the information provided by your Native code. The most important part when you’re about to write a Native module is to decorate the [00:24:33] you want to expose and after that, everything is done by React Native so that you can just keep calling them and providing the [00:24:43] you want to call.

Obviously, there are some constraints because not everything can be passed or transferred for the breach. For example, in iOS, you can pass some literals like string, numbers, objects and these are converted during the call, these are converted. For example, string becomes a string, and object becomes an NSdictionary and these are the objects from the core iOS library. But for example you can’t transfer NS date because this is a custom property that’s not supported, so in order to pass a date object for the brief Native Code, or from the Native code to JS for the breach, you have to convert it to string.

These are the things that you have to remember. But essentially what happens is there is a dynamic communication for the bridge and all these calls are queued up. This Native topic itself is kind of broad so if you have more detailed questions, I’ll be happy to answer. But as I said, API itself is built dynamically based on the information provided during the run time, based on the Native modules you have and the exported that you have decorated.

Nader: We actually have a pretty good episode on React Native radio about bridging Native component with taboo. I think it’s Episode 8. If you’re interested in that, or if anyone listening is interested in learning more about that, definitely check out that episode and Google Tadeu’s Zagallo and look up his blog. He has some good stuff on there as well.

Jamison: But first you must spell his name. That’s the biggest challenge.

Charles: I’ll put in the show notes. He’s a really smart guy, he knows a lot of things.

Mike: He also has a lot of cool stuff about the JS and how the React code is executed on React Native. If you are interested for example in learning more about how actually Javascript code can be executed on iOS or on Android and how the Native views are transpired and how that happens that you can write the React component that then becomes a Native component, you should definitely check out that because pretty much everything has been explained there in terms of the life cycle of what happens when you open up the app.

Charles: One other question that I’m running across here is that—I just got back from Wood Badge which is adult leader training for boy scouts. One of my tickets, or one of my goals is to write an iOS app that has cheers for cub scouts in it. I’m wondering, should I do this in Swift, should I do this in React Native and why or why not? I stumped him.

Nader: Well, if you’re a Swift developer or you’re an Android developer and you’re very comfortable building Native mobile apps, then there’s really no reason to use React Native if you’re just targeting that single platform. But for most of us, we’re not really in all these different platforms.

I guess the main argument for something that you would talk about would be having the opportunity to build cross platform using mainly the same code base. Pretty much all the apps build with React Native so far, we kind of like to go through them and see what percentage of our code is being reused. We’re able to use anywhere between 70% to 90% of our code cross platform.

I guess the main thing would be if you’re not a very good Android and iOS developer, the main reason to go with something like React Native would be able to get the performance of the Native mobile app but only being able to understand a single platform. Their original idea was learn once and write anywhere and they’ve stuck to that but they also kind of moved also more towards the write once run anywhere to extent. They’re not saying you can pretty much just write the app a single time and have it run everywhere even though that is theoretically possible if you stayed away from platforms specific APIs but you would be able to reuse a lot of your code. That would be I guess my argument for something like that.

Charles: The idea is you get the benefit if you’ve already written the app in React then you can send some of your code but I haven’t really done that and I haven’t written this web app. What you’re telling me is the other advantages is that there are certain aspects of it that will cross over between both platforms and I can effectively be on the two main smartphone platforms right out of the gate instead of having to learn Swift and then having to learn Java.

Nader: Exactly.

Charles: What were you going to say, Mike?

Mike: I was just going to say that from the developer’s perspective, what I have seen when I was comparing my development of Native applications on Objective-C to the development of even iOS React Native apps, was that when I was dealing with complex Json data structures, for example when I was interacting reverse APIs fetching some data, I have noticed that it’s way easier for me to work with JS for example fetching APIs and then transform this data with JS then for example writing some complex serializers and deserializers in Objective-C. I would also say if you are planning to do a lot of HTTP request and operate on web data and you want to write something super, super, quickly, that’s also something to consider, to keep in mind because it’s going to turn out to be way more simple in terms of managing the data.

Jamison: I know a part of what we were going to talk about today I thought was the React Native in action, right?

Nader: I’ve been working with Manning for about 6 months now. We’re putting together a book called React Native In Action. It just went on sale yesterday which was August 1st. We have three chapters so far. It’s going to be a total of 12 to 14 chapters and it’s pretty much going to be a very comprehensive book. If you’re coming into React Native or you’re coming into mobile app development and you kind of want to learn how to build mobile apps in Javascript, React Native In Action would be a pretty good book for you to kind of check out. You can read the first chapter for free and kind of see if it’s kind of what you’re looking for. If it is, it’s available for purchase right now.

Jamison: How do you write a book about a technical topic like this that moves so fast? Especially if you’re going to talk about the tooling or the modules or ecosystem or something like that, or do you just not want to talk about that stuff and try and focus on the core that’s not going to change?

Nader: It’s been pretty interesting. This is my first time actually putting together a full book. I’ve done quite a bit of blogging, I’ve done quite a bit of other forms of publishing as far as web stuff but I’ve never actually put together a book. Working with them, they understand that this has been a very fast moving technology. Already just in the past few months, there’s been a lot of API training. We actually had to go and rewrite pretty much every chapter every month. When I say rewrite every chapter, we’ve pretty much had to go in and just pick out things that have changed and best practices that have changed and things like the way that you import React and React Native from the platform change so pretty much everywhere in there that we’ve referenced React Native without kind of doing a rewrite. I would say one of the best things about dealing with these e-publications like Manning and stuff like that is we are going to continue to keep the book up to date. Whenever something does change, we pretty much go in and update that.

Something that’s really interesting actually is the navigator is very much in flux right now. There’s a few different ways to use navigation and routing in React Native but they’re actually deprecating the main way to do routing and navigation and they’re implementing a new experimental way to do navigation. But the APIs are not stable yet. We intended for that to be for chapter 6 or 7 but for the sake of not having to rewrite the entire chapter, we’re going to have to put that off towards kind of the end. We might write like a small chapter and kind of walk through all the different ways to do navigation except for the experimental way. Ince that API becomes stable, we’re going to go in and update that.

It’s been very interesting, it’s been a lot of work, it’s been a lot of rewriting and testing, and re-writing and testing. But overall I think we’re really happy with what we have so far. If you’re interested in learning about navigation and doing things like that without purchasing the book, I’ve got a few blog post on medium on dabit3medium, I have quite a few different blog posts on the experimental navigator as well as some regular implementations of the navigator and those are also being kept up to date with the API changes.

Another book I would also recommend if you’re into React Native is O’Reilly put out a book called Learning React Native. It’s a little smaller or shorter of a book. It covers some of the same topics but not so in depth but it’s an excellent book. In fact, I read it when it first came out. It’s written by Bonnie Eisenman, that’s just another option too if you’re looking to learning React Native, I would check out that book as well.

Jamison: You’re not in competition with that book? Trying to crush it?

Nader: No, definitely not. I love that book.

Charles: These things are so fast moving, do we know what’s coming next?

Nader: Mike actually handles the releases for React Native and he’s kind of closer to the metal there. I kind of keep up with the updated versions that are coming on the React Native to kind of keep up with what’s going to be coming and what to be working on the book. Mike can actually speak to a little more to that.

Mike: Yeah. We don’t have any upcoming road maps like what will happen next in the few months. I guess that’s something people at Facebook might know better. But speaking for the release process itself and what gets released every two weeks because obviously React Native gets released every two weeks. We always release on top of the master so if you want to check what’s coming up next, you should just visit us and see the latest comments. From the biggest features that are going to land in a few days because there’s going to be [00:37:42] I guess being released is that we have fully reworked the coming online  interface to be more developer-friendly, to have more examples and to have more features. This is thanks to the RNPM that I mentioned previously that we managed to merge.

This is the biggest feature that’s going to be added in the upcoming release. But as I said, if you’re interested in knowing more of what’s going to be released in the next two weeks or next months, you should definitely check the companies that have been merged to Master because essentially that’s how we’re releasing the React Native versions. There’s nothing like a road map. There’s obviously a product panes website where we are trying to release the most important for the community, the most important features for the community that are weighing for some contributions. These are the most likely to be implemented in the nearest future so definitely you should check it out to see what’s coming up next.

Nader: I know you’ve done an episode or two on React Native but this is a fascinating framework like we talked about earlier and there’s constantly things being approved. I was going to ask Mike to maybe speak about where React Native is today as opposed to where it was when it first came out and watch someone that may have tried it in the past may want to come back and take another look at it they weren’t too happy with it or they weren’t too interested when it first came out.

Jamison: That’s a fantastic question. Thanks for doing our job.

Mike: Yeah, actually I’ve been wondering the same earlier today, how React Native had changed over a year. If we’re trying to compare with the old versions, I think the biggest difference is the ecosystem itself. Back in the day, a year ago, if you were about to write something, there was always a module, a component that you feel like is missing. If you want to make in-app purchases within your app, there is nothing to use. If you wanted to scan your credit card, there was nothing to use.

Now, all these modules are there by the community. If you have a feeling that the ecosystem is not there yet and if you had a feeling that something is missing and you didn’t have Native experience to write these missing things, now you can try to check it again because it might turn out that all these things are already there.

This is one of the things that changed a lot. Also, the API itself has become more stable. Back in the day, React Native was shipping with React Forbes so it was impossible, it was super hard to actually share your components between platforms. For example, Redux used to have its own React Native entry point just because React Native was having a different React version. Now, these things are no longer there because React Native is depending on normal React version so this improved as well.

If you want to write a react Native app, we’re using Redux and we’re using some web logic in mind. Now, this is totally possible and it did improve. If you are about to do it again or if you would like to check it out again, I think it’s a good time because all these things are improving, documentation is improving like back in the day, there was a lot of missing places. The documentation was kind of confusing in a few places as well. Now, we have revamped the documentation dramatically, it’s now way better, it has more me though, it has more sections.

If you had problems with knowing some things, if you were unable to understand some certain things, if you found a lot of unanswered question, now you can try to search for these questions again because it’s very likely that they are already answered and you will probably find an answering documentation for these particular things again.

Charles: If somebody is listening to this show and they’re thinking, “Alright, my next app is going to be a mobile app and I think I want to try out React Native.” How do they start a React Native project?

Mike: It’s actually super simple because all they have to do I they have to just open up the terminal and call React Native in it and insert the app name. That’s done. I mean after probably an hour or after the installment finishes, you can just run your app with a common line again. All I know is that there’s two set of calls, React Native in it app name, and then React Native run iOS for example then you’re done, that’s all you have to do to in order get a bonus application that just says Hello World and you’re ready to go and to explore the APIs and do whatever you want.

Charles: Do you need to use NPM to install a command line package or something?

Mike: Yes, first of all you need to install the React Native CLI package which is the global version of the package. Important thing about this is that it doesn’t have anything hard coded so you don’t have to update it, you just have to install it like once in your life to have it on your machine and it will automatically detect a React Native from NPM and then run iOS and Android, all these things are actually called from within modules. If we announce something on Twitter, if we announce that okay CLI has a new comment, you don’t have to do anything because it will already be there for you. Just install once and forget about it and just go in it and you’re set pretty much every time.

Nader: I also want to speak about RNPM a little bit more. When I first started with React Native, I wanted to implement some of these Native modules or these Native plugins for React Native. Actually getting them to work and configuring them as web developer took me a little time to understand because in the past at least when you install Native module or Native package into your React Native project, you also have to do some configuration on x code or you have to do some configuration in your Java file for Android and if you’re not a Native developer, it was a little hard and it took some digging in and a little bit of work to do.

But now RNPM is something that is built into React Native. If you want to install one of these Native modules, it’s as simple as typing a single command, I think it’s RNPM link. You basically install the package of NPM install and then you run a command RNPM link and then everything just works. Mike can probably talk a little bit more on that because he is one of the people that kind of created RNPM.

Mike: As you said, the biggest problem we had back in the day was that when we wanted to actually use a third party module that had some Native code inside, not only we had to run NPM install but we also had to perform certain actions that were different for every single module based on the Native code or Native complements that these modules were having. This is kind of complicated for web developers because on Native side, you not only have Native code like Objective-C or Java code but you also have some libraries and some Native libraries that you have to link to your project and these steps are not done automatically. You can’t just have them added to your project automatically. After installing the module, you have to open your Xcode, you have to locate some build settings which is a tab in xcode and then you have to add some header search bars, you have to perform some other certain things like include a study library into your project.

People are not only trying to find these places but they are also wondering what a static library is. What we wanted to do is to make a tool that will obstruct away all these things and will make installing a Native library for React Native as simple as NPM installing anything else. Now that RNPM is merged into React Native, there is nothing actually you have to perform, all you have to do is you have to just call React Native install instead of NPM install and provide a name of the module you want to add. As I said, everything else will be done automatically for you.

I think this is a pretty cool feature because like in most cases, the linking steps, the manual linking steps were simple because you just have to do three things. After doing this for a month or two, you already learned them so you’re doing these automatically. But then let’s say you wanted to integrate code push. If you go to the code push GitHub, you check the readme installation steps, you will see that there’s way more things to do. You have to provide some configuration, you have to set up keys, tokens, you have to attach some Native libraries, SQL libraries or something else and this is getting super tricky not only to add to your project but then think about uninstalling Native dependency it’s like very, very likely that you may break something because these third party Native dependencies may overlap across all your React Native dependencies.

As I said, RNPM is the tool that makes this super easy for you because you don’t have to think about it. If you are a web developer, you don’t have to learn what a Static library is or what a Native library is or how is the React Native dependency different from regular JS dependency. If they are all in NPM they should be the same. As I said, this tool is there to make it easy for you, to make these initial steps easier for you to start with React Native.

Charles: Alright, well everyone got real quiet. Let’s go ahead and get into our picks. Aimee, do you want to start off the picks?

Aimee: Sure. I have one but I’m not going to say the full title but I didn’t like it but anyways, it is a talk by Kathy Sierra who I actually was not really terribly familiar with but apparently she is amazing from everyone who responded as I posted this on Twitter. It’s a talk called Making Badass Developers. It just kind of talks about using your mental energy wisely when you’re developing something. I got a lot out of the talk and she is just like a phenomenal speaker as well so that probably makes the talk too. I’ll put the link in the show notes.

Charles: Alright, Jamison what are your picks?

Jamison: I have 4 picks and 2 of them are self-serving, I’ll do those first. My first pick is surprise, surprise, it’s React Rally, it’s a Community React conference in Salt Lake city. Aug 25th and 26th, this might possibly go out before the conference starts. We’re working on a live stream, that depends on a couple of things but for sure we’ll acquire the talks and have them up on YouTube soon after the conference. Tickets at this point are almost sold out so they might be sold out by the time this airs. We’ll see, we might have some more but I would love to see you there.

My next pick is another podcast that I’m on called Soft Skills Engineering where we talk about the kind of non-typical side of software development. It’s Dave and I so two Javascript Jabber people. We have a website this week and we’re just so proud of being all grown up and having a website, you can see all our episodes at softskills.audio as a way to subscribe to.

Then, my next two picks are just two books that I’ve been reading lately that I’ve really enjoyed. One is Practical Object-Oriented Design in Ruby, it’s a Ruby book but guess what, it’s good no matter what language you program in. It’s been really interesting to read it, I think how would I solve this from a more functional programming aspect too, just really good information on how to design code that’s easy to maintain.

The second book is The Algorithm Design Manual. I did a CS program in college and I took the course on Algorithm and one on Data Structures but it’s been a long time since I really looked into that stuff. This is a pretty approachable book. Some of these are very mathematical and formal and kind of difficult to read as a working programmer but this one is really well written and also really interesting too, so those are my picks.

Charles: Alright, I’m going to jump in with a few picks. Generally, we talk about picks as something that made your life better or something that you’re working on or enjoying. I really had a pretty impactful experience last week. As I mentioned before, I was at Wood Badge. If you’re not familiar with what Wood Badge is, it’s training for adult leaders in the boy scouts of America. I think they also have it in England and other countries as well. Anyway, I don’t know how to describe it but I feel like more than just being a more capable boy scout leader, I feel like I’m a more capable leader in general and a better person for having gone. If you’re involved with boy scouts at all and you’re considering on going, just go.

The other thing that I’ll say about it is that I have attended leadership training in the past and I’ve seen leadership training programs on par with Wood Badge and they usually cost thousands of dollars $2,000, $3,000, $4,000, or $5,000 I’ve seen them cost. Wood Badge, if you’re a boy scout leader or even if you’re not, it’s open to anybody but it is $130 I think for adults in the US. You have to camp out, that’s part of the deal but it is definitely worth it. Anyway, I’m going to pick Wood Badge.

I’m also going to really quickly pick the Boy Scouts of America just because I think it’s a terrific organization that teaches young men and young women if they want to join a venturing crew. If they want to join a venturing crew, they can do that and it teaches them strong values and really gets them involved in a terrific organization. The mission of the boy scouts is actually to teach young people to make good life choices based on the values in the boy scout oath and law. I think people are on board with most of the principles there and I think it’s a terrific organization that does a lot of good in the world.

Lastly, I’m going to pick the scout camp that we were up at, beautiful area, it’s called Camp Tifie Scout Camp. It’s part of the Mountain Dell Scout Ranch. It’s right above Mt. Pleasant Utah if you know where that is. But anyway, if you don’t know where that is, don’t worry because Mt. Pleasant is a really small town. We were up on kind of a bench above the valley so you could look out over the valley, beautiful scenery. They had I think we saw 3 or 4 like or 4.5 box just walking across the open area in the camp and it was just wonderful, great place to go. I know that they have activities that you can go up and do without actually attending the scout camp but if you’re looking for a place to go and a nice place to visit, then that’s definitely a place that I would recommend. Those are my picks. Nader, what are your picks?

Nader: I have three picks. My first pick is going to be the Angry Birds movie, I wasn’t really too hyped up to see that maybe for some reason that I’m not a big fan of the game but if you have kids or maybe if you just like animated movies like me, then I highly recommend watching it. It was extremely entertaining, the animation, it was just a really fun movie. My second pick is an app called Enki, you can sign up for the waitlist. I signed up for the wait list and it took about a week I got an email and I was able to download the app. It pretty much gives you 5-minute daily workouts for dev skills and you can pick whatever programming language you’re looking to learn. I’m on Python, Javascript and Ruby and right now they only have Javascript actual exercises but Ruby and Python are coming up.

What it does is basically sends you in push notification every day and it gives you 5 different new things about a language and you can kind of pick what skill level you are so either beginner, intermediate, or advanced. I’ve learned a lot and I really enjoyed it and lets me fit in a little bit of extra learning every day.

My last pick is something we already talked about, it’s my book called React Native in Action for Manning publications. If you’re listening to this podcast and you’re looking to learn more about React Native, download the first chapter, it’s free and check out the book if you’re interested in the rest of it.

Charles: Awesome. Mike, what are your picks?

Mike: I have three picks as well. The first pick is the React Native Europe conference that will happen next year, probably quarter three in Poland. It’s going to be the first React Native conference to happen in the world so if you are looking for learning more about React Native and kind of hearing more about Native modules and how React Native can help your dev team and help your apps to go on both platforms and old platforms.

You should definitely sign up to our newsletter on our website and wait for the tickets. It will be happening next year and Poland is a really great country to visit so don’t forget about it on your list.

The second pick is the React Native Apple TV. Apple TV is obviously the digital media player by Apple and I’m pretty sure you guys all have heard of it before. There is that guy called Doc Lauder that had made a forum for React Native where he had it designed for Apple TV and it’s supposed to be working pretty well because the APIs between iOS and Apple TV are pretty similar. If you have an Apple TV at your home and mobile development is not your, you can kind of try to get this app and running and probably build an app on your TV, I don’t know a game or a kind of a streaming platform, whatever you want, it should be fun.

Actually, I’ll probably start again with this one. My last pick is going to be a React Native meetup that’s happening in San Francisco, November 16th, I’ll be there speaking about Native Modules so if you’d like to hear more about how we have built the media player I’ve been talking about previously, how to add in Native codes to your app and make it cross platform, just be there, we’ll have a coffee and share our experience.

Charles: Sounds good. You should stop off in Utah on your way back.

Mike: I’ll do. Actually I have a list of places to visit. I’ll be having a car. Yeah, definitely.

Nader: Is Mississippi on that list?

Mike: Half of you are on my list already so I’m not really sure how this all will fit in in my visa as of three months but I’ll try to make it.

Charles: I’ll let you sleep on Jamison’s couch.

Jamison: You’re welcome to. There’s a 9-month old baby so there may or may not be a lot of screaming at night from adults and babies together.

Charles: Well, we’ll go ahead and wrap this up. I just want to put in another plug real quick though if you’re a React Native developer, you’re interested in React Native, go check out React Native Radio, that’s reactnativeradio.com, see what they’ve been up to. How many episodes do you guys have now? 33? 34?

Nader: We just recorded number 36.

Charles: Okay. Yeah, definitely check that out. You can also, if you go to the Javascript Jabber page, on the top there’s a dropdown for shows and it’s listed there in the shows.

Nader: Yeah. Absolutely, we have Sir Kevin Old, Jed Watson and Ali Najafizadeh. Me and Mike are kind of the regular panelists. We come and go.

Charles: Alright, well we’ll go wrap up the show. Thank you both for coming and we’ll catch you all next week.

Jamison: See ya!

Aimee: Bye, going back to work.

Nader: Bye ya’ll

Aimee: See you.

Charles: Getting back to work. Why do you have to end on a downer?

Aimee: It depends if I fix this bug or not.

Jamison: I have confidence that you’ll to fix it.

Aimee: I’m so close. Oh, Jamison. You know what,

Nader: I was going to mention since you’re moving to Nashville about Kevin Old but I guess you already know.

Aimee: Yeah, definitely. When I went to my boot camp, I feel like I know a bunch of people there and I’m just going kind of going back home close to family and stuff so yeah, I’m really excited to go back there. But anyways, okay getting back to work.

Charles: Alright, we’ll catch you all later.

Nader: Bye you guys, thanks for having us on.

Jamison: Thanks for coming.

Charles: Yeah, thanks for coming on short notice.

Mike: Yeah, thank you.

Charles: Alright, bye.

 

x