React Van | Client-Side Architecture of a React/Redux Application

it's just get myself started here yeah I love this me up it's I've been coming out for the past six or seven months and it's always so informative and definitely a very passionate and engaged crowd so I really like that so well tonight I want to talk about client-side architecture and because I think it gets it gets confusing okay we'll get to that my slides but I want to kind of go back to basics and as an educator I'm always thinking about like how can I communicate things to people in a way that's kind of straightforward and simple so and when it gets into building software and particularly through the react world there's so much things going on and so I think it's it's easy to get lost so I think I want to talk about some things that I've noticed is I've built react applications and try and bring things back to the basics submit about me I'm actually from Toronto and I've been here for a year and so I climbed the chief here and I was looking at it was very very beautiful and we do not have that of Ontario so I definitely is from someone East it was very very cool experience so I do work a train station and I am an educator there I do the full-time web development program and we do full stack we do teach reacts so we focus on kind of a Merton stack style we do just you know the backend the front end we teach you react and so if you're interested in learning this stuff in a really serious way check out rain station that's what we do as a sidenote we are also looking expanding on educator team so if anyone out there is a developer as familiar with react can learn react is interested in education let me know because we are actively growing we've been doing this program for a year now in Vancouver we've been having great success great results for our students so if you want to be part of that let me know effective close to something on the slack channel as well okay so I've been at all her for a lot of years and you know front end back end kind of became full stack in the past couple years I've been doing reactive stuff I mean teaching react this past year I did a couple of draft applications real-world applications and so I learned a few things I'd like to share some of my experience of what I encountered as I faced trying to build client-side applications is react world can anyone so who's like completely new to be out here okay so this is a small employer kind who's done like less than six months okay so maybe like half or so I guess a lot of my students that's good who's been using racks in like you have a deployed application production let's give you okay so so what I want to talk about is this sort of when you you go out to start now start an application and just you have a client or your job that your boss says to you we want to do yeah if you heard what we act we want to take our legacy code into like a client application so you're starting an application you're decide to use react right react is like by far right now you know the framework or the library within JavaScript that everyone is using so of course you're gonna use that you're trying to get to speed you're reading blogs you're reading tutorials you're watching videos you're checking out you know sample code on github and you've heard of that well these reusable components and like you know it's not opinionated so it seems like a really really good thing you can do what you want with it so you're thinking yourself how bad can this be and this is literally you you're kind of going out into the water right trying to figure things out and in this kind of space and then it ends up that it gets out of control and it can actually get really bad and I think this movie was really bad I didn't watch it but probably not worth watching so more specifically it's like this right you start looking at things and then you start going wait a second I'm reading about all this stuff at Remo props in state and I think I understand that and then I heard it over ducks but these other weird things like ma backs or flocks and then there's thumbs and sagas and we got containers and hawks and you know for a while it's you kind of get a sense of like because all these things I'm trying to learn and you kind of lose track of the forest for the trees right so you were setting out to build a know great application that's gonna solve people's problems but all of a sudden you're swimming in you know all these new terms and react you're trying to figure out how you use them and you kind of lose sense your path okay so sighs that you're getting a bit lost so these are things that I encountered in a couple projects that I worked on this year and I just noticed some things going on that made me feel queasy and when you look at the code and you know what's going on you start to feel that things were just not right here okay so some of the things that I noticed in react applications that seem to be a problematic was you have a lot of stuff inside of state and so you have like you know this the statement here and it's just stopped with in this case it looks like it's a lot of poor kind of code but you have a lot of other things that can get stuck in here and if your spaces have been really big it just starts getting really complicated and we just kind of change it or modify it it just starts getting out of control another thing that I would see is a lot of this kind of stuff where you just kind of have this like global object and you just pass that object down into your app or eat your component do I need to make I like large skittle upper-level objects just gonna pass them down at your component the components pick off the first day heat okay so that's something I noticed that really bothered me and make me feel very uncomfortable of the code the other issue that occurs it's kind of related is state showing up everywhere okay and what the thicker project I was working on had like you know dozens and dozens of components and all these components have all this state a lot of them kind of like a lot of a really big state to they're trying to manage all these things but it gets kind of overwhelming it's ready to start getting confused as to what you know what's what you try to travel this state second for the second or third day is that you're a slight limited it makes also notice pattern and some of this code does something yeah where you have back-end code in your components that kind of bothered because I looked at this and I was like I've got this promise here I've got some async code that's going on I'm actually checking like packet and status codes here and then I'm trying to like show modal if there's like problems with the backend connection and so that was something I thought that's a sign that things here are getting out of control the final thing that I want to give an example of is what I noticed happening is my callback massively not control components and that's the ones that just keep getting bigger and bigger and bigger and bigger and then you've got this huge amount of state stuck in them you've got all these functions handlers this is a regular here up in the flight 296 and all this is literally just render logic and we're definitely like I know like 75 lines later and there's still no UI code here it's just all like variables and logic to try and get around what you're gonna display and this particular example was like over 750 lines of code and there was late in this particular code base like dozens and dozens of components that are all except on a fifty to a thousand lines each so very very much you manage and after a while you're like forget what you're trying to do you're looking at it you're searching through the code like it becomes a very very big problem and I think this problem occurs because you start thinking about components and so you started trying to stick things and components bit by bit the components are getting bigger bigger bigger and after a while it just becomes unmanageable becomes the main component so when you're in this situation text becomes impossible right you've got back in code stuck with your front-end code it's not very easy to test I'd be used as a real problem right because you're actually how these you know it's so complicated it's very hard to be used any of these things and then in terms of understanding its market follow it's easily to track of what you're trying to do you might it's easy to use bugs so it's T's stressful if you're trying to you actually may change your code or add new features at the end of the day what happens is your waste your mind your energy basically it's what happens you're in the one actually we're done in the woods you can always smell bears because they're really stinky and smelly so this is like bad code smell and you know if you have to make changes or you're under pressure to add new features and things you're just you're not in a good situation okay so what I thought about it I thought you know obviously there's obviously very simple best practices to kind of get out of the situation and then what I'll do is I combine those together to general kind of the device that architecture that helps to address these issues so the first is that where we're getting huge amounts of state are cute very very large estate objects or if we're just passing like big objects into our pots as a good chance that were have a bunch of data components that we don't really need right or we should try and break our components down smaller so we're using more specific props to those specific points rather than these massive components they're just taking it huge among objects and trying to process them we should use containers to try and just map necessary props you know in to the components that need them and also recognize that there are different types of speed so maybe that means those different places where we can we can play state in different locations based on its use rather than just snuffing everything inside of this state object inside of the book it's a state could be for example data right so it's user data or back-end data that were receiving it could be form data some things they happen to be saw as a lot of for natives just getting stuff inside the state we can location arriving information session and the communication loading type of status state so those are all things where maybe we devise strategies that we just don't keep everything in this one sort of state object that's a little quick little example something like this instead just possibly act down into some components what we could do is actually you'll pick off the props that we need and as well as a functions that we need and just pass those so now our component particularly is prop types we can create components that have specific purposes with specific props that's a lot clearer or what's going on the problem with a big huge object I mean have styling I don't know what what do I need on this object like I have to dig into my my component I just figure out like what props are being used here okay okay it's taking everywhere we should try to take control of our state instead just keep state specific components so state if a component needs state for itself it should use that state for itself but if the state is shared that state should probably go global stores that's where products comes in a stick your state serve at a management things like your ducts and then finally we should try and strive to have stateless functional components which are components that have no state at all they just take props they do their job that's it right that will make our code generally easier to manage by the side notes there's a different ways that we can't so one way is the global score so this is really great for shared state them to kind of get across your application we stick it up in here and then any containers that you can get it and always pass it down to the cops the second ways you could just have local state when you look at a lot of tutorials or blogs online you try to learn yeah this is what you see a lot right because we were just showing you a little demo of here's how reactor works here's an example and they'll just make everything locally in the state right and so if you follow that and you're learning a bit by bit and you're trying to grow your codebase you just start getting these components where your state gets out of control we can have relatives see where maybe we have some state in a serval local container that passed and down towards children or we can have a contest so we could have state has provided at a high level that sort of passed down through the entire application so there's these different ways that we depend of state commenter's of energy so with the backend calls I feel that we should never have a cat who ate the canary components we should decouple that and I'll show you that in the architecture async functions we should put that stuff in we've got a sled and reduc so that our art or global store managed that back-end code and we just do a dispatch to Renatus for ducks handles you know whatever you need for the backend you show us up at our store and then we have access to it and then if we do really need to do some binding cause maybe we should have some service helper functions that contain on that logic and we just do a little call and then whenever that call finishes we can update our state or whatever in terms of handling these massively how to control components I think the principle of do one thing well works so every component that you millage do one thing really well and if you try to have a component that's doing two things three things for things you're going to start to risk that you start having this like ballooning component that's hard to understand is just doing too much stuff take advantage of containers so then basically containers handle this situation where we've got data coming into our half and then these containers just pass props down to the cords that need it that we're not sort of mixing up our call or back the calls with our global data with local stage and all that medicine and then finally just bit along I guess it's kind of stench that the one thing well which is your component should be as small as possible there are simply small tablets are in build and then build them all up from there so instead you have a collection of these smaller components that are easy understand that you're kind of piecing together okay so that leaves me to decide open very creative about the common sense architecture and that is the idea of just let's take the basic software principles we all know instead of getting lost in the world of react and lost in all the cool things that we happens doing though the change that happened let's just apply some common sense to the use of all these different yeah so if we get back to those basics we have separation of concerns right so let's think about building small components that do one thing right spread out the concerns don't put the book the back end code in with your front end logic right keep your code rights obviously of all avoid repeating code through your code base loose coupling patterns so same idea of like don't be putting your back at your front end code too closely together and then finally is configuration obviously sexual education don't have URL strings scattered throughout your entire code base right it's if it's a small little project that you're doing personally it's not a big deal but once you get out into the real world larger code base real users production Norman's kind of stuff all these things start to really matter so the approach of architecture that we could do is something that's later like this right and so we keep proud of that a few logic up front right we're basically I'll show a couple for the public record graphic in a second and then we kind of put the backend stuff in there at the bottom okay so at the bottom level we build everything on services that are responsible we're talking to the backend right and so if I once use those services I can use those in this level with either maybe contact the binders keep them or in my Redux store needs to you know get some data from the server right and then basically I put everything into containers and some containers basically provide kind of a buffer width between my view logic and my global store so any sort of global data being shared my container can access it and then pass it down the line to these view so few layers here really just worry about presenting the UI to the user whereas sort of the data layers are lower and in between we could have these containers that mount back and forth okay so the more sort of topographical bayonne would look like this we have a user on the front end we have the back end services there some sort of database and API calls we can basically just go through your system we've got our services if we need some global data that we got from the backend we can put them here we've got some async functions our context provider if it needs anything from the backend you can get it a lot of that might be more static and kind of data that we're using routing data and then we can kind of split this screen area here into sort of the container side which is kind of like a controllers mapping data from the front end into the back end and then these few layers and one thing we have here is really that low-level UI logic and then maybe like layout logic so particularly when we're doing responsive websites and stuff it might have written things we're using so we can put that in a layout and the layer just uses a bunch of these like UI components that used to actually interact with and see information okay I just quickly go through this part here so you I should be small be useful components largely stateless functional components so at this point it's really just about getting input from a user pasinetta put down the line displaying information from the user so you're kind of trying to keep that simple it's focused just on what the user needs your layout shouldn't really how much logic it's literally grids and things that you're using to kind of structure the overall page that you have or screen in this case containers are responsible for the mapping so we want to be seen this is kind of this plethora right from he's got a back end things to this like front end stuff and then basically the containers will just pass the props into like delay up in the UI together collectively info projects I worked on I was like oh these are screens what I'm building here screens so I started to have a collection of supreme this right and I've got my home page and I've got its a login page and I guess if we're building apps they're not really pages right there were like screens inside of the top and so collectively we can put those together maybe go together so every screen bases container that passes prompts into all of the presentational components that are required for that screen then of course we have our global store so any shared state that we need to share amongst its components or maybe share across the screens that can all go in our Redux store and so we have dynamic data we've got actions about easing functions in there this magic all that shared state context dividers are much more more static type of data so these are themes globalization this is routing information okay so maybe it's not much change over there maybe there's some back-end data and so they get this context provider information but it's much more static information that's used to kind of be passed down here on fire then finally we have the surface level which is more your protocol API level stuff which is air as you can have click here you can do some caching here in the PWA world this is kind of like maybe we have service workers that are kind of responsible for that back-end conversation so that makes a lot of sense there okay so the benefit is that when you think of your code in this kind of way you just kind of know where everything goes right when I was looking at this project I had this code I showed you before because think it's really hard to tell it where to put stuff right whereas when you have kind of structure like this it becomes a lot clearer right everything has its own place a nice thing actually this separation is you can easily swap out this example if you want to do native applications you want to use like yeah creative what you could do is all this stuff here stays on the same right and you just need to swap this out you're kind of react native this point is still all be on you see this which I've got you later so there's a nice simulation that comes there it's easy that idea features because we just keep following the pattern we need a service not good data we need to configure our global score we need to make a new screen write our new screen is made up of related components there may be shareable components not there may be shared from screen to screen and then the code is understood by looking at its place within the structure as opposed to trying to figure out the logic so if we're digging around component trying to figure out what it's doing it's doing it's really hard right but if you can look at the structure of the code in terms of where it is your overall architecture then you kind of know what is this thing doing what is this piece responsible and it finally testing becomes possible because we can actually test our code in isolation we can test the layers individually so I can test how my services make sure they all work but that I can also integrate them so I can start to do end-to-end testing and it becomes easy to sort of work either across the layers or in the individual layers okay so basically instead from the poop emoji to the bottom og me more of a comment I just had to totally awesome agreed go ahead just fine with the kind of structure Oh see what I struggle with you're starting out if you may you do as well you're trying place don't like this I really know what are my screens or should this be container the green thing will react if you'll probably agree with this for example at your big MOOC or the massively but you can start coding in it and maybe along later like you know what these for this big employer should be broken out into four smaller ones so the great move over adapters you can come on the fly refactor things to go on the right spot if you're not quite sure [Music] oh it's reusable components it's like all it is is this like little few layer you features the deadlines just keep growing these components to the imagination any other questions do you ever recommend it older structure based on this architecture yeah actually I didn't get around to doing like a demo example but basically you know services would be one folder and then you have your global store stuff in here there's a really cool tool called be match that's really really great for managing for you actually stuff everything to like that the content providers might be sort of blended in with some but yeah then what I would have is like a screens folder and then every screen basically corresponds to around so when you're doing your client site routing basically every route you've got a screen and so that's a really easy mapping and then you might have support complex reps or whatever as well or nested roads but at least at that level consider your obvious and then within a screen I would have maybe components or because you like boys and I Wade have a good general component to the shared kind of components that you're using across your application this is something like that is what I want if you have some politicians for example for more business logic more advantage such as what additions also be that goes not only when particular fields but how did relate to the other ones where would the places so if you have my more validation if I'm more complex business logic that you have to run

Channel: ReactJS Vancouver Meetup

Views: 1,694

Keywords: iMovie

Id: dfucG9rvb4E

Length: 24min 17sec (1457 seconds)

Published: Sun Nov 25 2018