Speed up your React Native Development with Storybook

all right well we're going to miss that whole part of the the presentation in the beginning so I want to talk a little bit of our about our react native development process and if you're new to react native this is a good primer on what it what it's like so late last year we started making a shift from a traditional iOS app to a react native application and we have the obvious benefit of yes you can you can target both Android and iOS but one of the great benefits of using react native is that you can leverage your existing web development team to work on the react native apps so our app developer poll went from three people who can work on the iOS app to 10 plus engineers who can work on the react native app and so we have contributions to react native app from all over the team the engineering team our back-end developers our web developers are react native developers can contribute to this we have a traditional get flow which I think it's pretty good for our mobile development we have one master branch and we create PRS to go into it there's other teams that have slightly different get flows but this is ours we like to rebase all day every day instead of like just emerging having one master branch and then just coming in the morning or like you know several times birthday and just advancing your your your work is just very very clean we like very very clean PRS without any merge conflicts large commits or anything like that and we have two levels of developer reviews we have a developer review which ensures code quality etc and then we have a QR q QA review which make sure that the experience is great for the customer you know let's make sure that we don't have any bugs or anything like that and then on top of that we have continuous integration so whenever we merge something into master our team study server just runs fast lane and automatically makes the builds and pushes them to test flight and to fabric for us to distribute the app internally so we're constantly testing you know what the latest master is and that's that's really really nice for us and obviously there's some places where we would like to improve but we want to go fast we want to iterate fast so I want to talk about one of the problems in developing react native access the working on deeply nested scenes our app at this point have gotten pretty big we have places in the app where you have to navigate to three scenes three or four scenes and what I mean by scenes is kind of like the fullscreen components that contain functionality for like a card or for like a of you so for example our search screen is one scene our you know hotel program Hotel details screen is another scene etc so we have hot module reloading to help us with that if you don't know what hot module reloading is it's a feature from web pack and further from that also happens to work in the react native development server which sends a signal to the client whenever you change a module so then the client handles it and we load that module which could be like a react component and there's some special magic that happens in the background in react native there's a babel transform that converts component into a component that can accept hot module reloading NAL's that hot module reloading spore was made by MA then ever evolve and it's been pretty nice but it's sometimes it's not that great so what other issues that we have with working in deeply nested scenes is that we will in order to get to the screen that we need to work on you know go start a hotel search for example in our app then you pick a hotel and then you scroll all the way down to look at the part of that scene that you want to work on and you start working on it and it's nice and then you hit save and you expect it to reload or to reload that little portion of the screen that you just worked worked on you make your change and then it doesn't work because then you realize that you didn't turn on how much of a load so it's okay you do like the little shake etc and then you have to do it again you wait forever for the JavaScript transform to happen and then you're like okay this is this would be fine if you only did it once if the salsa mistake that you did once a day but one of the things of a hot module reloading sometimes put your put your application in a weird state and when you get into a weird state you just have to like reload and you know kind of like do the navigation dance all over again and this can happen to you like several times a day in this low sound development it's kind of a like an annoyance and if you can get rid of rate of annoyances then that's great so it's kind of like you know having to deal with that like all the time is not great Bob right so enter storybook storybook is a tool for interactive development and it's a kind of like a testing environment for building components in isolation it allows you to develop also a content library that you create over time and you just have a reference of all the components that that you make and the storybook basically lets you create a list of stories that are essentially testing harnesses for these components and I'll show you the stuff in a second I wanted to play with storybook because if you know I went to Rio comp I incurred all the talks and it seemed like working on a component in isolation would be very interesting and then I realized you know at this point I had never actually done this in my career work on the UI elements by itself it's always been as you know you're working on the whole webpage at the same time and you can only had to reload the entire page and certain things like you know automatic refresh and like your hot module reloading but you're never actually working on components in isolation you're always working on it as part of a bigger product so I've been putting buns on web pages and mobile apps for a really long time and this is just a very interesting concept if you want to install story book in your react native in your existing react native project it's very easy all you have to do is install the story book CLI and then type in in your project get story book and it will do all the magic of setting up the story book tool and then to get story book running you essentially just do NPM run story book and what that will do is it will start up a web pack server that's different from the react native development server that will deliver a different javascript file then your application file to the app and the app is just loading you know whatever javascript file it you know it gets from the localhost 8080 one so that's where story books comes in and just delivers like a nice testing framework so you can load up in your in your app and I'll show you right now so let's see if we can scrape out of this nice creepers what's the show that can't see anything so I have my emulator right here and I'm going to load up story book here I'm just going to reload this for a second what story book gives you is this nice web page where it shows you the list of stories that you've written and I'll show you what this looks like in a second but this is essentially your component library and when you click on the components or sorry on the stories you can see the application updated and you can take a look at some of the different concepts so let me vent whoops that's not great there you go yeah I'm not going to I'm not going to split my screen here first or murder the screen but let's see if we can search for some of these components so Hotel hotel marker so this is a component that I recently had to work on that is just essentially a marker with different props and these are I guess your stories that you know essentially run your component with different props it's really nice when you want to test when you want to do things like you know standalone animation so yeah let's take a look at hetero animated this is one animation that we made you know it's really nice it's awesome that you can just you know make these things without having to load up your entire application etc it's very nice to focus we can have some more complex examples like like Lola repeater which is something that I made this is a more complex story that shows you components this component that I build its attention to the viewpager and it has to work differently on iOS and Android this is just one of the different capabilities of the act native between the platforms and here's an example of the story of this component controlled by props and I can just move interval update the parent so it's really nice to be able to to set this stuff up one of the things that I really like about storybook is that it has a really nice community built around it and somebody made this thing that's awesome let's close this this is this is an annoyance like this webpage it it takes up too much space and it distracts from my code so I'm just going to pull up vs code here and as you can see I have storybook integrated and integrated into vs codes so I can just go look through my stories and yeah I can just you know change what I'm working on which is really really cool another cool thing that I like about storybooks is that it can actually control two different the two different platforms at the same time so let me see if I can pull this up and get it working so oops that's a story that's not already but let's take a look at some other stuff and as you can see I'm showing you my android device right now that I have connected and I can change stories and see them on both platforms at the same time which means that I can develop stuff for both platforms at the same time and make sure that it works which is really cool okay let's go back to the presentation if I can find it so this keeps working so we started doing building stories and at first it was just like I want to play with the school to let cetera and then we started realizing that it was changing our process our development process so what did we start learning we plan a lot better now before we used to assign entire scenes as features for one developer and now we think in terms of components we separate working components instead of like keynote like entire scenes and we realize that giving somebody an entire scene to work on it's a mistake because scenes actually have several concerns so there's a Redux concern right we probably need to work on the Redux portion of it you need to build the container that connects Redux to your component there's layout concerns and then there's like the basic component concerns and as we started realizing this eventually we started separating work by concerns instead of just by components so let me give you an example look like you know what concern or like what a feature for us was a feature was an entire scene we would say RAF you know worked in this entire scene and just get it done please and the several concerns here and because you're thinking about this in terms of like one thing it's very easy to just like you know mix everything up and build your spaghetti cook once we started thinking in components our planning was a lot better starting from our sketch mock-ups during our sprint planning we would actually take the extra time to separate things into components and this you know this process took a little bit longer but it's totally worth it and the things that we argue about during this meeting so it's mainly like what are we going to call these components like what are the names right we have different philosophies and we spend like a lot of time but once we figure that once we figure that out you know we know exactly what we need to work on so these are the concerns that typically go into a scene right you have your Redux store stuff you have your Redux container you have a scene layout and you have several components and here I'm just going to highlight you know these these things in different colors are the things that can be worked on by different developers at the same time instead of one developer working on this entire thing you can have you can throw multiple bodies at it and get it done quicker so let's go back to the demo and I'll show you some of the like the interesting things that we've done past the stage so I'm going to show you this thing called Skeletor Skeletor is this component that I build and it has a cool name Skeletor yeah I Molly I mean thought of the name horse and then I build a component I just want to do it for just so I could have a component a skelter one of the things that we realized is that we would give the task to build let's do some people and then we would give the test to build out the scene to other people right but we want us to go parallel and we found you can't really build a scene if you don't have the components like you want to you know say like oh I can't I can't work on this because I'm missing a component Toria so we built this component called Skeletor that is essentially a placeholder so that people can start working on on the layout and all this component does is you know it takes whatever props you want to give it you know it takes a name and then when you click on it it shows you this little window right here that shows you the exact prop sides hey so the person in charge of connecting the components in a scene doesn't have to have the components in order to do that let me see if I can look at this look that it yeah so can people see this that's a big yeah so basically we have a component that we're importing from our components library by the way Atticus taught me a cool trick to like avoid this about how about doing this this whole thing talk to them afterwards I'll have to talk to afterwards you'll remember it but yeah we import this component called Skeletor and we just you know we use it all over our layout right skelter you know we give it a component name and we give it some like props instead of whatever props are going to give that container or the component that's eventually going to go in there and then the neat thing is that you can import Skeletor ask the name of the component that you're waiting for which is awesome like a so you can see right here you know I'm waiting for header primary to be done and then once that's done all I need to do is this just delete this part go like that and boom my skeletal component that used to be there is now replaced by the updated component so this is a really neat way of parallelizing work you know you can get to shipping a full feature much faster if you organize the bodies that are you know going to work on it another another scenario that I want to show you guys I didn't have time to prepare this is you know talking about the container concern we have some components that we're including into some of their stories in story book that you know depend on we have character they have containers in them and when we start first started putting these stories into into into story book we we had this error that like hey you know there's no store right you need to set up a store in order to be able to use this component because it's a connected component and this is one example so in order to get this component to work all you have to do is just add a provider and store in call create store with just like you know nothing on it and that's enough to get a store into your storybook so that your component won't complain and this is the part that I wish I had more time to prepare but there's a realization that comes from this which is you can work on the container you can start working on the Redux container without actually having the redox store so you could potentially here just make up some random store that just happens to have the structure that you're eventually going to have in your Redux store you know have somebody make the container and then have somebody else just work on redox without having to worry like how it's going to get connected etc and that's that's the best way to work out with actually Redux are supposed to be this kind of have less app and you just you know somehow attach to the UI but it's supposed to be a standalone app and this part is really cool and we've done it in development I don't have anything that I can show you right now but it it's really really nice to be able to do that alright um back to the presentation so what were the speed-up benefits a scene or like an entire feature used to be one or two big PRS made by made by one person which are really big they were hard to to review and now in other we have story book you know we can create a scene with like seven eight PRS made by entirely different people and those PRS are smaller and easier to to review the other awesome thing is that we don't need to queue QA every PR now because a lot of the peers are just story book PRS you know story book does not go into your product whatsoever it's it's an entirely separate testing harness so it's okay to just merge you new components into inter master you know if you're just playing with them in story book once you actually put this into your product then we have a QA review the PRS can just you know have the story book link in them in order to demonstrate hey I made this component and it works and it's awesome and obviously you know it helps our planning our sprint you know much it happened it helps a lot and what happens is that because we're working on these components in isolation it means that the contract between components mean like you know which processor which process the components get paid that's much more well defined because it's not it's seen standalone it's not part of like this bigger you know sea of things and what's awesome is that you know eventually you build a component library over time so as you build more features you say oh I think we already have this component so I'm just going to like you know take that and put that into my next scene that I'm building and this is what a PR looks like and I'm going to like zoom in a little bit this way so a PR you know our what our peers have maintained intent you know they talked about like you know what the component contract is has a link to the your storybook URL and it has like a little preview of you know what the component looks like and you know we find that this helps you know the PR process a lot totally so some takeaways from this stories are testing you know slash developments like showcase harnesses for your components story book puts modularity front and center and if you want to have like a very king maintainable code base you need to make sure that you put an emphasis on modularity and you'll have higher quality code sorry book lets you break down work by components it has awesome integration with GPS code you know our developers who use them are very jealous of this I'm sure somebody will eventually write a plug-in for them or something but it's totally for BS code right now and you can make stories for not just components but for layouts and Redux containers etc yeah and I think that's it thank you you guys have any questions yes isn't she a good profile not yet we do have kind of like this external stories folder and I can show you like what the structure that is a little bit so we we kind of have like the storybook folder and we have our stories but our components are still like in in source component slash share etc like our components right now are a little bit messy we're working on eventually we organizing that you know right now we're actually in the middle of a launch like we got our lunch and I have tomorrow but after after we're done with that like well you know take the pencil we own as a project a little bit yes you do they just work on so I can I can see why that this question is important because you're running the story in the device you know the native modules will just work that's not true of test and that's a common issue in react native like you know you there's a lot of native components that you use when you know when writing code and if a function uses a native module when you run it in node when you run off when you test that function at node node doesn't have any notion of native modules or anything like that so you your test will fail but in storybook because you're just running the thing on a device it will just work yeah yeah when you have to it's up to you to again it's kind of the same thing as with tests you know in tests you know if you have up from confirmation you often mock the modules each other you're going to have to do a little bit of setup if you if your component requires things to already exist but stories because they're just JavaScript files you can do that the same way as you would in your app and actually we do that like in some components some of our more complex components I didn't show you require like a real app store that is already initial initialized with certain stuff and we just run the same initialization code as we would in our main app yep yeah um really I started started taking a little bit different approach to our screen and our app we have just like the few things your topic your connection screen the way out right there think about breaking it apart much more there you just have your layout you have your connector that actually so with that scenario we're here screw for your theme is really just a layout of other components are you putting your theme and storybook to orbit we're actually putting some scenes in storybook because things are just components right um that was the awesome part of this in my mind things are a little bit differently they're a little bit different from components you know students take up the entire screen we can just know stories for the things themselves and when I talk about layout that's what I'm talking about like the scene is in charge of like laying a bunch of components and a seam doesn't necessarily need to be rabbina in a container a scene can just be a collection of stuff that you know components that are contained they have their own containers and in that case you can still do the same thing that we're doing here which is you know wrap your scene in a provider and just give it some like you know either the real redock store that you use or male duck store yes professions so as somebody who is very interested in doing this at it looking at storybook Wow what would your advice be for team that doesn't use this and want to introduce it but already 32 features focus right now that we need to had incorporated um I would say um you know the benefit to us has been enough that I would advise you know you know take a day off feature work and actually set this up and you can start out with one component you know you can start out with one story you need to start making stories for everything you need to stop existing PRS etc but if you have like one component that's like a button there you would like to get right try setting up story book it took me like less than half an hour to actually set up and you know you can get started with it you know in less than like an hour or so any other questions so I'll say one of the things that we would like to get to in the future is having a static storybook or we have native so once we commit stories to master who would like our you know CI server to just generate the storybook and put it online somewhere so that we're not as developers who are making scenes that already have wave components like we can just go to a URL and you know look at the existing components that we have without having to run storybooks ourselves and I would say Atticus is actually doing some really cool stuff in that regard and hopefully you'll give a talk about it in the future all right uh thank you thanks a lot Hey

Channel: Rafael Mendiola

Views: 9,323

Rating: 5 out of 5

Keywords: react native, storybook, react

Id: SN9DKCKb13k

Length: 32min 27sec (1947 seconds)

Published: Thu Jun 29 2017