React Native Code Reuse: Architecture that Works - Aaron Greenwald

my name is Aaron Greenwald and um yeah this what we're gonna talk about I'm gonna talk mostly they're gonna listen but then you can ask questions if you want so let's start off with survey show of hands how many people here right react native every day only a few of you and like some of you your car works ok how many people here right react native sometimes ok we're getting there how many people here wish they wrote react native okay fine so no that's good that's important we have a lot of aspirational what we call it which is good because this way I can tell you things and you won't know if I'm lying what's the talk about what do we want to talk about here we want to talk about react native reusing code or protecting our app in a way that makes it work what does any of that mean what's react native react native mix of promise okay a long time ago like I don't know three years ago which is a long time in JavaScript world maybe for react native Facebook came out and said we have a new framework bla bla bla bla bla that's a lot of cool things bla bla bla it's called react native and this approach yields about 85% we use of app code this think I lifted this quote directly from a blog post of theirs I can't remember who wrote it probably doesn't really matter the point is that Facebook says that they can reuse a lot of code which sounds like a good thing I mean I shouldn't have to convince you that we're using code is good right it's the holy grail of software development that's all that's what we want to do we want to reuse code the question that you have to be asking yourself the question that I was asking myself when I saw this three odd years ago was not is this good but is it true and not is it true like his facebook lying I assume they're not lying they seem like I don't know what let's assume they're not lying okay but when I was really worried about is it true for me like sometimes big company comes out the framework and says yeah this framework is great yeah well no kidding because you wrote the framework for your exact use case so of course it fits the use case perfectly but what about my use case maybe your framework gets you 85% a app reuse app code reuse but me maybe I'll get I don't know 60 50 40 30 100 I don't know what I'll get can I trust this that was the question I was asking if this is just something Facebook and gather or for something I can get and three i years later the good news is my answer is yeah i think so in fact i would say that i get more than 85% in the parts of the code i see most of this my daily work I would if I had to pick a number unscientifically made up not based on anything except my gut 95 percent maybe so yeah it's great right but of course there are caveats nothing's perfect and that's really what this talk is about where are the caveats where the GOC is what do you have to do to get that 85% and where can you get it where can't you get it well let's take a step back when we talk about reusing code what are we talking about I mean it sounds good right but when we move past the the buzzword of code reuse what do we mean I like to categorize or I like to group all of code reuse into basically three different things that I have found when I talking to different people that this is what they're thinking of okay the first is between Android and iOS this is probably the most common when I said the word code in use I guess most of you thought about reusing code between Android and iOS right and maybe if you know somebody with Windows Phone that too but basically Android and iOS right and and that's a legitimate kind of code reuse but there are others for example reusing between your mobile app and and your web apps I've had many people come up to me and say hey look you know I have a react app this sounds like react native I don't know it's got the same word in it at least half of react native is react so presumably I can reuse code right can i and that's something we're going to talk about and then finally there's another kind of code reuse which is reusing code between multiple projects now this is we don't we're not gonna talk about a lot but we will talk about briefly and and it's important for those of you especially how many people here are guest not that many of you are writing react native you said but of those that write react native how many of you work for agencies great so we don't have to talk about this stuff but basically a the idea is that okay if you work if you're like me and you work for the company and you have only one app that your company publishes then you probably don't want to write code or you you know it's not that important for you to write code that you can reuse in multiple apps except that you want to open-source some parts of your code that can then be used in other apps which is part of it but if you let's say work for an agency and you build apps for many clients and you probably have pieces of boilerplate an infrastructure that you want to reuse across your apps and that's another kind of code reuse we'll take them one at a time Android and iOS and with this one this is the question we start off by asking what can I share or those people who come from a background of Android and iOS native development start off asking this question they say all right so you tell me that I can share code whoa what but that's obviously so there's also already write react native we know this is the wrong question the right question is not what can you share what can't you share because you can share everything I mean the default way of working in react native when you just take out your ID and start working is that every line in code you write the first line the tenth line the 500th line it's all shared between Android and iOS for free so the question that we have to start asking or the mindset that we get into and react native is not oh how I share some code it's how do I not share code and when do I not want to share code so when do I not want to share code well I don't know if you have four different UI then you probably want to share that and that's probably a good thing that I I don't get into a ugx debate but you know some people maybe that Apple and Google will tell you that that your your UI should cater to their platform and look like it's native on the platform some app some big companies are famous for not honoring this and coming up with their own design system but but basically the UI is if you're building an app you probably want your UI to look like it's at home on Android and at home and iOS so you want a different UI and maybe there are some features that only apply on one or the other maybe not funny story I once worked for an insurance company where they had a problem this was before react native and they had different teams for Android and iOS and and so this was in the United States and they said that if if they ever released the feature by accident on Android two weeks before iOS people would call and complain they'd be like hey my wife has the feature and I don't what's up with that so you know but maybe you have some features that are only relevant maybe you have something that a note interacts with NFC and it's only relevant on Android and sewed are things that you can't share we're not gonna get into your product here you probably have some things you can't share what's interesting though is how do you do that and react native gives you some ways to write platform-specific code gives you ways to basically say this code that I'm about to write I only want to be friends or only wanted to be for iOS how well option 1 is the platform module what does that mean that means something like this ok this is an old screenshot from a long time ago but the and and there's now fancy or nicer or more ergonomic ways to do this like platform select but the fundamental is the same which is that there's modulae even port from react native it's called platform and there are some methods and variables let's say there's a variable called OS and it will either be not necessarily either but it will be in this case iOS or Android and in my render of my here I have a view that has you know if it's iOS it says I see you're on iOS and if it's on Android if you're on Android it says I see it on Android easy peasy good done we're done we can all go home but of course there's another way because nothing simple the other way is use file in the Imperfects is what does this mean this looks like this imagine I have a directory in my app like a car you know in my source code sorry and in it there's a mean builder of component miyamoto j/s and it imports an input box ok but I have two input boxes here I have one input box Android Jas and one input box dot IO SAS except when I use it I use it like this I just say import and put box remember box which is a lie because there is no file anywhere called input box ajs but react native is magic react native says no problem you want the input box just component which doesn't really exist ok if you're on Android I'll find the die Android is if you're on iOS I'll find the iOS that is what happens is a compile time the the package are essentially the compile time the package er runs over all of your code and says okay I'm gonna take all of the files that have a generic graphics ojs plus if I'm compiling for Android all the ones that have that Android and I'll skip everything that sorry OS and if I'm compiling for iOS I do the opposite I compile everything that's either generic or iOS and I skip everything from Android which is a nice solution yeah so we have two options which one's better okay show hands you have an opinion good point so so I've never tried it to be honest but um no but but essentially the idea the idea platform suffix is that you have also dot Windows that yes or whatever the suffix would be okay and and that's why I said I was careful platform OS doesn't have to be iOS or Android okay it could be neither could be the third or fourth or fifth thing that's the theoretical concept but who thinks here that up the using the platform module is a preferable way and who thinks file name suffixes so everybody votes file name suffixes who thinks it depends that was a trick question the answer is always it depends okay there's never going to be a question where the answer isn't it depends all right the the real knowing that it depends is not an accomplishment knowing what it depends on is and I'm not gonna embarrass anybody so I'll just tell you what I think it depends on it's a matter of preference okay really but there are two there's there's one main difference between these two options which I think most of you sensed which is that the file name suffixes is a compile time selection okay the iOS code never gets to the Android device because at compile time it picks the correct code and the platform module is a runtime selection which means that every time this this view is rendered it has to say Oh am I in iOS am I in Android and make that decision how much does that that cost performance wise I have no idea probably basically nothing it's not so much the performance I'm concerned about but the semantics if I if I look at a component and I see that to code flows and I assume that you know maybe in the morning it says good morning in the evening it says good evening right like there's a component that can go two ways but that's not the case here there is no component that can go two ways there's only one component here it's just that the input box looks different on different platforms so I have a different input box but for the given device that I have in my hand it's always gonna be this one or it's always gonna be that one so y-you have code that makes a look like this - all right the flip side and then that's I think why a lot of people like file name suffixes the flip side is the file name suffix is a pain to deal with so so you have a bug somebody complains about it what do you do you search the code because you don't remember where it is in your code base your code base is huge right you search the code and you find someplace and you fix it there ah but you forgot there were two places that had that cook or similar code and you have to fix that bug in two places right or you're looking at code and you can't remember if you're looking at the iOS one of the Android one because the main difference is that one has an underline in the input box someone has a border and so now you're confused having two files when you really only wanted one as a paint and so when it's a very small difference I say just go ahead and use the platform module it's not such a big deal if you want if you if you need to have okay a thicker border or a thinner border just use the platform module if things are significantly different than the file name suffix is a cleaner way to do it but there's more overhead involved so right around now is when I when somebody here gets a clever idea and says oh I get it you're telling me that having two files is a pain because your files are basically the same and there's just one little difference I have a solution to that it's called inheritance why am i make a base class that is like input box base well that'll have all the common stuff and then I'll just override the little piece that's different in input box Android info box iOS and then I'll import the subclass of the correct subclass seems easy right back I think it's a great solution yeah no I think it's a terrible solution okay because what's happening here you're using inheritance when you could use composition or you could have done was separate all the common things out to a component called info box common that was now wrapped in the Box Android name mocks iOS ok which is a lot easier to reason about a lot easier understand especially in JavaScript which is only kind of sort of object oriented and your ID probably doesn't really support it that well and you know what I said that the having two files have to find the code that you're looking for as a pain well now have him three files it's a real pain okay I was there like last week I have no idea where my code is I don't know what overwrites what this court all over the place but you look at this component there's no render function how do I have a component with no render off cuz the render is in the superclass but then I look at the superclass there's no logic I don't know what's going on anymore this is don't do it I'm telling you I used to I used to be the guy who did these things I thought I was so clever I feel like an old guy you know that's only three years and react native but I'm just saying anyway the bottom line here is that your architecture matters okay how you architect your app how you design your app how you setup your code is gonna make a big difference in whether or not you can achieve that 85% Facebook is promising or even more what do I mean first of all and Ron talked about this well Ron talked about the next thing but logic is generally cross-platform most of your logic is gonna apply to with Android and iOS okay I say most because I'm trying to be conservative I don't want to make a big statement in my case it was all I don't think I had any examples in my personal work in a few years of having logic that didn't apply to one or the other but yeah I I submit that there might be an example somewhere but most of your differences are going to be in UI which is why you want to keep your logic out of your views you also want to keep it logic at your views for what I'm talked about which is better testing but in the context of this stuff keeping your logic out your views is really good because it allows you to reuse your logic and am i keeping your logic out your views your your views to become perhaps specific to one platform or other and your logic stays cross-platform to do this we use presenters dispatcher selectors call them whatever you will these are the parts that Ron talked about that uh that essentially take what you have in your stew in your state okay what could be again the redox remarks or whatever store could just be some blob of data but take whatever's there and figure out what to do with it yeah I call the presenters the part that take that raw data format it figure out what to do with it and the dispatcher is the other side of that that take the actions user did and Marshall today to organize it the setters so to speak the reason I keep these generic terms here is because there's different nomenclature depending on what kind of state management library religion you subscribe to so if you're if you're in the marks were land you have setters and getters if you in the redox world then you have dispatchers our actions it doesn't matter the point is that that you have you have a temptation to dirty your components with logic and you don't see it happen it starts off very simple okay it's really it starts off like you know it's just an if statement it or the user puts the data in the input box like this except the server accepts it like that and then the server actually changed now we need to change it so we just make the change right here and we just you know convert the data like just take this data and put it there and then maybe we have to reformat it and then we have to organize it in the tick to eight from two places before you know it that's like a whole blob of code okay keep it out of your views and then finally there's another tool we for this which is Hawke's hooks and whatever else comes out I was reading about hooks today hooks are pretty cool okay I don't like them so much though I don't know I reserve judgment I don't want to say this because there's a camera but um you know I'm not sure how I feel about hooks okay feels a bit like ox or higher are components which for those of you who haven't had the privilege of working with them yet are very very clever super clean elegant entirely understandable and I say this is somebody's written them and then and I you know you write them you're like it's so great because like logic is separate it's here it's there and and and everything so you know separation of concerns it's beautiful except the next guy comes and tries to figure out what's going on and it spends an hour or two three four trying to figure out a bug until the poor fellow figures out that the reason that for the bug is because the higher-order component is doing this thing and it was invisible it introduces magic and it's something I worry about with hooks as well as you got growing codebase when your codebase is smaller there's three of you and you all know where everything is in where everything is it's great okay in my codebase I wrote half the stuff and I have no idea where this and and people it's it's you know several years of cruft and redesigns and things that get changed and and changes in product and pivoting as we call it andrey deciding what we want the product to do and then adding new modules on top and all kinds of things and then developers leave developers come new team members it's hard to follow and and keeping code simple is a really important goal however these tools allow you to separate your code out and make them more usable and and herein lies the the challenge we're going to talk about towards the end about the trade-offs here but in in you know if you have a higher two component that's easier to reuse it because you have your view your higher component just has the logic the state manipulation or your hope can if it's a you know 2019 but but you don't know where the code is because it's not it's not explicit it's not in front of your eyes when you when somebody complains about a bug and says this screen isn't working the first place you go is the component and you have to find all the different places that are impacting it think about this carefully but the thing that I left on a new slide because I think it stands on its own is smaller modular views and this is I think the most important piece of the architecture decision if you take a an app your app and you look at it very carefully you look at the Android version and you look at the iOS version and you think wow these are like totally different new eyes so different and then you look again more carefully you might realize that they're basically the same what do I mean what often happens is you haven't you have a UI that's 99% the same except that last 1% the trimming so to speak makes it look super different to the to the I when you first see it what happens is you you have an input box and you have a header and you have a you know a navbar and a menu and this and that and because Android and iOS have different design patterns they're in different places on the screen maybe you have a tab bar here and here you have a menu here and things like that except the stuff in the menu is the same the individual pieces are the same they're just organized differently if you think about your your screen like a big Lego contraption the little blocks are the same they're just built in different ways and if you make your views small little pieces then you'll be able to compose them and you won't have to have this redundancy of code let's go back to the input box example I mentioned composition briefly now let's get back to that you have an input box okay maybe part there's an input box and there's a Save button you know I don't know and you think to yourself okay this is like one component input and save except now the input needs a different design for Android and iOS so if you make two different pieces two different components now you have to duplicate the safe but if you had the save in a separate component that was just included in the input or actually a third component that wrapped it okay the wrapper that has the input and the save and then a third component now the only thing that you need to separate is just this one little piece of the input if you really want to go to a lower resolution you can make just the borders to be separate you have to choose how far you go with that but the smaller and the more modular your views the easier it is for you to compose more complex and very different looking things with most of the same building blocks and only very small differences there's nothing new about this idea by the way this is essentially a rephrase a rephrasing of the single responsibility principle which is an old idea in software every function should do one thing and one thing well that's what this is just said for components every component should do just one thing if you have a component with a lot of JSX in it it's probably too much if the component just does one thing and it does only that one thing and it doesn't that one can get exactly right then you'll be able to build your views in a much more reusable way and now we get to web apps about questions so far disagreements Wow all right don't you think it should go the other way in terms of you said that you compose the third Robert Rucker of two components because like some of them like the search button should be platform-specific but maybe you should go from one view of rapper and then as you see that you have two different platform asipi components we extract yeah I wasn't thinking much about the order and with with which you build the thing there are times that it makes sense to do it that way there are times that in fact if you see a really big component you should probably get up right away in my opinion my experience tells me that that that that refactoring often doesn't really happen because like I said about the logic in the views they sneak up on you it's easy to say I used to be the guy said no logic in views like like crazy I like electrons rule of thumb by the way but it's easy to say it's hard to do sometimes I I would I would do I probably would break it up then and then we break it up again later in reality because in reality I'm gonna discover things I didn't know you always discover things you didn't know the important thing is that you think about it you won't make the right decisions but at least you thought about it so you didn't make the wrong decision by accident let's talk about web apps this happens also frequently we say okay react native great I'm gonna write code and it's gonna be basically the same opportunity hundred nine whereas everything's just gonna work but I already have a react app I have a web app and it's basically the same thing right so like how much can I reuse and there's a lot of confusion about this because if you've never done react native you might have the wrong idea in your head so I will try to set this straight but I'll tell you the punchline right in the beginning architecture matters how you organize your web app will make a difference in how you can organize your erect native app and vice versa depending on which one came first and if you built your web app the way most people built your web app their web app then it will probably be pretty hard to reuse a lot of it but if you build your web app from scratch together with the react native app it will be a bit easier and in our own experience it took us until the rewrite of the web app till we could really reuse code in my team to experience that I want to clarify something just that there isn't any misunderstanding here so when I mentioned that there are about 70 developers working on the Wix app and that was a separate into many many teams and what I say here just like one said what he says is his personal opinion at least some of it what I say here is pretty much all my personal opinion based on my experience in my team in Wix which is the chat team but other teams have done things very differently or pretty decentralized and diverse and I don't know feel free to disagree if you think you know if your experience tells you otherwise this is what I what I had for the last few years this is what I learned but other teams have tried other things other companies have tried other things and maybe I don't know maybe there's a better way but I'll tell you what I learned and and I hope it has some value to you and one of the things that happened to us was we when we first started our our react native chat it was hard to reuse stuff from the web boosts not built for it but then when we had to do a rewrite anyway in round 2 we did a much better job taking lessons I'm about to share with you and actually being able to share serious portions of the code what do we have to do well first of all we have to accept that our you eyes will be completely separate ok this is just the baseline there have been projects that attempt to take a react native view and make it render on the web or vice versa I haven't even tried them ok that's how much I believe in them no because because it's kind of like oh we can do this just because we can but really your your web view your web UI is different than your react native does not even attempt to to say that like this is not fungi we don't attempt to say oh yeah no problem just take your your web app and make it into a native app because that's not what we're trying to do we're trying to build a native app that looks native that feels native that is native it interacts like a native app so having the same UI is not even the goal the goal is to have a UI that feels and looks and interacts natively and the goal on the web is to have a web UI and any kind so far anything I've seen any clever you know way to somehow magically convert a react native view into a web view and vice versa my opinion misses the point keep your UI separate except that you have a different UI but because you kept your logic out of your views you'll have reusable application logic but first let's talk about always creating separate modules sorry and always a crazy separate module ok this is a something that also comes up sometimes in questions can you have one repo yeah you can have one repo you can have a mono repo but you don't want to have one NPM module that has your web app and your and your react native app it doesn't make sense I mean you could hopefully optimize your way out of it out of the mess you made by true shaking but they don't go together okay you need to have a web app react native app and then your shared stuff somewhere else in the third npm module and that third one will have your reusable application logic the bringing of your application what does this mean I don't know I mean why it might be your whole redux tour okay it could be that you can take an entire redux tour entire box don't just drop it in and boom you're not in reality it's usually not because your store also knows about flows and actions that happen in the application and and people interact with the web app differently there's different actions different CTAs different things you can do with the web app native app so unless your native app is really a one-to-one mirror of your web app then dropping the whole store and probably doesn't make sense either you need to find the level at which the level of Logica which the stuff is common maybe it's the services maybe it's a lower level store and there's a wrapper store you think about this you think about it from the beginning because if you if you make a big ball of mud for your web app then it'll be really hard to make that web app work for your native app or vice versa if you think carefully in the beginning about how you can separate your pieces out and say okay this is the stuff that is for the web this is the stuff that's for native and this service is shared you pull it out into a separate NPM module from day one you'll have an easier time of it but you need to know that now you enter a little bit of a pain why because the web the web needs different things than reactive react native for example wreck native modules if I'm building react native app I want to import something MPM module I don't want it compiled I don't want to transport I want in es7 plus I want is nice because I know the package will take care of it the react native packager comes and just compiles everything for me and mix it in one nice bundle and I like my own node modules to be raw and readable but this the standard in the web world is not that the standard in the web world is why I need to compile your code that doesn't make sense how am I supposed to know which Babel plugins you want how have a configure your web pack this shared piece of code that was going to work for the web and for mobile I don't know how to make it look well how do I publish it so I publish it rod when I publish a compiled if I publish a compiled the react native people get upset if I publish it raw the web people get upset so in some cases in our example and our in our case and some some of our modules we actually published two different distribution packages so that everybody's happy it's a pain okay and you have to fiddle with it and then and then then there's another consumer that doesn't that can't use es5 they can only use the I don't know a lot common j/s or something some other kind of format they need and you have to always think about all these different use cases and the last part that really is annoying is linking does anybody here know what NPM link is anybody not know what NPM link is okay I'll tell you so let's say you have two modules because I told you you have to create a separate module so you have now let's just say you're only working on the neither side so you're working on the native code you know you're working on react native stuff and then ooh I didn't make a change in the part that I separated out into the common stuff except now it's in a different place it's not part of your react native app so you have two options why don't you go into your node modules and you make a change except now wha now you made a change in new modules how do you commit that source control copy paste you do crazy things I don't know it confused so another option you have is you go to your to the other your other placing your on your local machine and where you develop your your library so to speak let's call it and you make changes there except now you can reload as many times as you want your react native simulator and you don't see the change so whether you can do now you're gonna make the change commit it publish reentry install everything in MPM i hope everything worked oh crap I forgot something I made a typo okay now I got to fix it so come NPM Lincoln says this is no problem what we'll do is we'll set up a symlink from the consuming library to the source library ok the consuming library is no module to these to the source when you make a change in the source the consuming library just sees it directly and so from your you can now develop the the library and the consumer so to speak on one machine together at the same time it's great it really is great there's one problem it doesn't work with react native and okay it used to not work officially with react native because react native packaged we didn't follow symlinks and then there was some new version of react native and it did work always for the city said but I don't know I sometimes it works okay sometimes it works sometimes I feel like this okay and I'm not the only person to happen everybody in my team is always saying that they yeah it works until it stops working you don't know if it works if you use yarn sometimes it works better than if you use NPM but sometimes if you use NPM it's fine okay some people have given up already in just the copy paste the code eh time no I don't have a solution now I'm just telling you that sorry okay which leads me to the last section which is what happens when you have multiple projects yeah multiple react native projects maybe you want to reuse your code across those or maybe you just have one react native project but you want to share some your code with other reactant projects is an open source well the same principle architecture matters okay it in Wix I can't remember who coined this phrase above open source from day one but it was popular in the in the react native world that works which is basically says if you start your code if you start your whatever thing you're doing open source it will stay open source if you're doing it won't what do I mean by this this is a very common pattern which is that the somebody is says okay we need in our app I don't know a camera kit okay we need something with camera and but this isn't something out there so let's make one and so they build it right inside the app okay if they do that then they say oh you know there's nothing really super specific to our app about this we could probably separate it out and make it open source yeah it's a bit too late not too late but it's a lot of work now what happens you accidentally leaked your logic into the component it's too it's too tightly baked to your specific use case it's hard to separate out and also also you're embarrassed you don't know which I separate out I didn't finish all the tests it's not polish no it might not look good I don't really wanna publish it let me first fix it up and then I'll publish it yeah it's like a to-do in code okay we all know what that means so if you do open search from day one you avoid all those problems when you do open source from day one you get over the the the shame so to speak of imperfect code it's not supposed to be perfect you just started you said I want to make a camera kit you go right away you start adding you say I'm gonna make a camera kit it's going to be separates gonna be open source where is this forced you to do it forces you to always think what belongs in the camera kit open source and what belongs in my my application what's common to the whole world belongs there what belongs in my application belongs in my application you now have a cleaner architecture it's easier if for you to separate things because you're forced to so are things good of course not you have to be old binaries in the in the old world of plain JavaScript you didn't need to think about transitive dependencies if I'm a builder of some library and I decide you know huh I'm gonna take this piece out and just separate into a another library no problem I could do that like let's say app some code in the code you ask the pad zeros on the left of a string right no problem I'll just make a left back and nobody will even know left pad exists until I unpublish it but in react native that doesn't work transitive dependencies are now not invisible why because sometimes they have binaries and if I want to use your library and your library has native code in it true native code then I need to now deal with that I need to link those binaries I need to worry about them I need to maintain all that it's another whole piece of overhead that isn't natural to JavaScript developers who are used to just doing MPM install on top of that comes dependency he'll versions can bump into one another versions are not always compatible with one another this is only compatible with this specific version of react native or this has native code native binaries that can't be able to native binaries or if you don't deal with the correct version of native buying the reason you won't be able to upgrade my NPM package and so that's a whole nother level of overhead that you have to deal with and what I have found having to deal with all those things is that I don't really know what I'm doing and I suspect most people know neither not sure about that but I suspect and so I caution you what's all this to say basically I give you a very negative picture yeah everything sucks all right which isn't entirely true you know things are good like yeah sometimes it works right sometimes yes sometimes you debugging it turns out that the bug you had isn't really on you you know so there's good things in life but no it seriously it there's a lot of trade-offs here this is what I'm trying to present to you here can you get 85% code reviews from react native absolutely at least in the parts of your logic probably higher than 85% well you have to work for it yes between Android and iOS you won't have to work that hard you just have to be responsible keep your logic out of your views don't do stupid thing you know yeah you'll have some hawks you'll have some hoaxes you'll have state here you'll have a store that isn't super clear but if you if you basically follow best practices so to speak and you don't clutter up your views with tons of component lifecycle things and then all kinds of junk and make these huge views that have tons of things in it you'll be okay and you'll get a good chunk of queries but when you move to the next level of trying to reuse with your web app you really need to think and and there's pain involved there's there's complication you end up with a lot of modules you end up with my web application my native application my common application my thing that's only common to-to-to-to my application but the thing that's common to all the different consumers of the similar code the open source now every time you have you go into work every morning you're working on six different modules just the other day when my co-workers is sitting there looking at me like how am I supposed to work I don't even know where any of this stuff is right it's and he knows what he's doing it just it's difficult there's a lot of overhead involved of this is it worth it that's a conversation that sac uestion you need to ask yourself but you need to go into it with your eyes open to understand how much it will cost okay and don't go crazy in the beginning the same time when you see that you're gonna you're gonna grow and I mean grow in terms of how many millions of users you have a girl in terms of how much you have in your app then you might want to seriously think about organizing your code in a way that will make it reusable I'll give you a few examples I'll take questions one of the things that was very important one of the I would say brightest things that in our team we did and I don't take credit for this it was somebody else's decision was that we had to interact with firebase okay for some feature of our code and and to do it both our web app and and our native app would have to and this is at the time where our native app was our web app was still an angular and I Robert was react native but they both have to do a lot of similar logic we pulled that out into a separate library okay it's maybe three four files plus tests so like 15 vials and but it has a lot of logic in it that works okay 100% test coverage there's only logic in it there's nothing there's there aren't complicated things like native pieces that are hard to test it's a pure JavaScript and it hasn't really been touched in about three years and it still runs in production which is pretty incredible okay yeah I say that as testament to just how good that decision was to pull out that facade so to speak to firebase and I actually it wasn't the firebase facade at the time it was just the real-time facade because we weren't even using firebase when we did this we were using a different service then we transitioned from that service for a whole nother back-end to firebase without changing that the API there and it was completely transparent to both the web app in the native app everything just worked it was wonderful okay that's an example of when it makes sense to pull things out of course when you have to make changes there you have to remember to go there another thing is that the second the the rewrite or the second second rewrite of our chat act we basically pulled the entire brain of the chat out into a core library that's just JavaScript that's reused on multiple different web apps as well as our native app and works pretty well and this was only possible also because we learned the hard way about what it's like when you have all your redux tours and everything so tightly reached into your into your components when you keep things nice and clean and separate it's easier to to reuse them in fact one of these is the design principles we used when we did this was not to expose internally this library uses redux and we do not expose that to consumers so we didn't want the web app and the native app to have to know that our core library is even using redux why because we know that Redux will go out of fashion and then already happened and and marks will come in and then after my books there'll be a notion maahox or something else and we don't want that make all the consumers tightly coupled to have to connect directly to our store so instead we make an interface okay now that's probably over engineering for most cases when it's the third time that you're rewriting your app and you've dealt with the pain you think about these things but what I want you to start thinking about the architecture now because picture matters think about it you won't always know the answer your to your point I think you sometimes you're gonna make the wrong decision okay because you don't know the future you don't know where your apps gonna go you don't know how many times you're gonna redesign your products gonna change but at least make that decision on purpose make the wrong decision on purpose instead of making the wrong decision just because he didn't even think about it all right that's the bottom line that architecture matters thank you [Applause]

Channel: Wix Engineering Tech Talks

Views: 1,367

Keywords: Wix.com, Wix Tech Talks, Tech Talks, Wix Engineering, Wix Eng, React Native

Id: sDq6YOunL7o

Length: 42min 27sec (2547 seconds)

Published: Wed Feb 27 2019