Django and React: Perfect Together
McCloy, Jack
React is a JavaScript library that makes it much easier to build dynamic single-page sites. I won't much dive into how React works, but the main advantage is that it allows you to build your view layer in a declarative way, and with reusable components. We'll start with an overview how React works, with an eye towards how it's different from interpretive libraries like jQuery. This overview will center around how state is managed in React vs. jQuery, which is the biggest hurdle for many developers when they're learning React. So if you haven't quite wrapped your head around the difference between "2-way data binding" and "1-way data binding", or if you've heard someone talk about "data-down/actions-up", "flux", or "redux" and weren't quite sure what they were talking about, this will clear all that up. Then we'll take a look at how you can integrate React into a Django project. We'll talk about how you might want to structure things if you're starting with a brand new project, but we'll also talk about ways you can start to take advantage of React's strengths even in projects that are already mature. Finally, we'll talk about some of the challenging parts of working with React for the first time - how to handle front-end permissioning in React based on your back-end API, how to think about url routing when you literally have two routers, deployment, and the general confusion that goes along with using npm and webpack for the first time.
 Come on, y'all! MUSIC Hi, everyone. Um, so my name is Jack, and I have to... There we go. Cool. I'm a software developer from New York City, and one of the reasons why I'm giving this talk is most of my recent projects, three out of my last four recent projects were Django projects that also used React. So I've dug deep into how the two can fit together, and I really like how they fit together. Hopefully, um, some... Has anyone here worked on any React projects? Okay, so a handful. So not a room full of beginners. That's exciting. If you are a beginner, I kind of geared this talk for people who know Django, but haven't really used React yet, or kind of just thinking about it and looking at it. So, um, I've been a Django user for over five years, a React user for about the last year or so, a little longer than that, and for what it's worth, I don't consider myself to be any kind of expert on either of those things, just someone who put in a lot of time working on Django projects and React projects, and might have a little bit to share. Um, I'm gonna try and talk fast. If I talk too fast, slow me down, but, um, it's kind of a broad scope to this talk, so I'm more worried about not having enough time than I am about, like, filling time. I'll try and save some time for Q&A at the end, but that's my contact info. You can hit me up on Twitter or GitHub if you have any questions that we didn't have time for today. And I'll also be around for the next couple days for the sprints. So, what are the goals of this talk? Uh, the title of the talk really could be a crash course in React for people who already know Django. Um, the first goal is to understand what React does, how React works, because a lot of people are talking about it, and people in the Django community, some people have kicked the tires on it, some people have used it heavily, but a lot of people haven't. So, it's kind of an intro to React for Django people. Um, and the goal is to build a mental map for React so that you know how to think about it. It's going to take longer than a 45-minute talk to build a good mental map for React, but hopefully this will be a good primer. Um, we're going to become familiar with some of the key parts of a React project and learn how to set up a React project inside of a Django environment. Um, one of the other big challenges of learning React is that a lot of React projects and most of the React boilerplate examples use JSX and a quote-unquote new JavaScript, ES6 or ES7. Um, so we'll be diving into a little bit of that just so you know what you're looking at. Um, it's one of the things that can add some intimidation to learning React. And then finally, we'll bring it all together by showing how Django and React can fit together in, uh, in a project. And we're actually going to start here a little bit at a high-level view, um, before digging into the, uh, React part. We'll look at the separation of concerns in a Django and React project that uses both. So Django follows the MVC pattern for building user interfaces. Uh, in the MVC pattern, uh, there are three parts, the model, the view, and the controller, and they're all interconnected. This is kind of how they're interconnected. The model updates the view. The view is what's seen by the user. The user can do stuff to manipulate the controller. Um, this is based on the user's interaction with the view. And then the controller, uh, updates the model. This is how Django works sort of. Um, there's a cool question on the Django fact page. Um, Django appears to be an MVC framework, but you call the controller the view and the view the template. How come you don't use the standard names? And the answer that Django gives is in our interpretation of MVC, the view describes the data that gets presented to the user. It's not necessarily how the data looks, but what data is being presented. Uh, it's sensible to separate content from presentation, and that's where Django templates come in. It's kind of a pedantic answer to, uh, that question, but that's also part of the reason why I like it. But what they're saying essentially is that in Django, the view part of the MVC is split into two things. The view that you keep in views.py that renders data to your templates that actually are the view that the user sees. So the map of an MVC from Django's perspective looks more like this, where the model corresponds to your models.py file, your views corresponds to your views.py, they render data to your templates, um, which is what the user sees. Uh, he or she interacts with the templates to manipulate the controller, which is kind of like the framework itself, and the controller updates the model. React fits here. React fits where the templates are. It replaces, uh, your Django templates, and based on how the user interacts with those templates, dispatches actions that then update Django, that update the controller. So this is what your MVC looks like in a React project. Um, the first thing about React, uh, to understand is that it's not a full MVC framework, and it doesn't try to be. Uh, if you use it in a Django project, it'll fit where your templates, um, used to fit. It won't replace anything else in a Django project. Um, and keep in mind, templates, like it's the broad view of templates. It's not just the templates files, but also the files and packages that your templates use. JQuery, potentially CSS, all of your JavaScript files, uh, that are imported into your templates. So, why would you want to do this? Django templates work perfectly well. Why would you want to start, uh, stop using them and start using something that is significantly more complicated? No, sorry about that. Uh, that you have to learn from scratch, and that's outside the Django ecosystem that you already know real well and love. Um, and the answer to that is maybe you don't. Maybe you don't want to use React, and it would be overengineering to use React. Uh, Django templates are perfectly fine for plenty of sites, um, and we all know that because we've used that for plenty of sites. They work. Um, but React lets you do certain things that would be really, really hard to do, if not impossible to do, um, using just Django templates. The first thing, um, that React templates let you do is it lets you turn your site into a single page app. Um, from the user's perspective, single page apps, when they're built the right way, they are faster, they feel more modern. Um, it's something that's really been popular in the JavaScript community for a couple of years now, and has been a little bit slower to become popular in the Django community. And the, uh, Ruby community, I know that channels are doing some work to be able to use templates to build single page apps, but this is a big reason why React is deserving of a look. Another thing that you get with React is the ability to reuse parts of your code base for iOS and Android in addition to just your web app. Um, I'm not going to dive too much into this, um, but it basically works like this. Your React, your React templates are made up of components. They're like building blocks that you assemble together to form your UI, and each one of those building blocks does two things. It performs some internal logic, and then based on that internal logic, it renders a chunk of what your users see. It renders a chunk of UI. With React Native, you get to keep the part of your templates that perform that logic and use them across platforms, and then render out different code, either HTML or, uh, iOS or Java, based on the platform that the user is using. And then finally, and this is probably the biggest reason why React is, quote, on as big as it has, is it makes it much easier to manage and manipulate complicated state. Um, in most small projects, there isn't complicated state. The state is simple. So there's not much to manage. You can keep it all in your head more or less. When you start working on a bigger project, um, managing state can become a real nightmare, and I'm sure it's something that you've, uh, potentially run into. That is the biggest selling point of React and the biggest thing that it makes much, much easier. So we're going to zoom in for a bit on the React part of this map, um, so that you can understand, uh, and get a feel for that. And then we're going to zoom back out and look at how Django and React work together as part of a full system. Oh, and one more thing. Since one, uh, since React is taking care of your UI, your views are going to feed it raw data. Uh, your view layer is really just an API layer. React doesn't care what the rest of your stack is, but using something like Django REST framework is, uh, it makes a heck of a lot of sense, um, because then your views are just an API layer by default. So the homepage for React highlights a couple of things that differentiate it from other UI frameworks. Um, if you understand these three things, you'll understand the fundamentals of React. The first one we already talked about, it's that React doesn't make assumptions about the rest of your technology stack. React is your UI layer. It provides a really good tool set, arguably the best tool set for, uh, building your UI, and it doesn't try to do anything else other than that. The second point on the homepage is that React is declarative, and this one is a little bit tougher to grok. Um, React makes it painless to create interactive UIs. You might put an asterisk after the word painless. Um, it's painless once you go through the significant pain of, like, learning how to use it, but once you understand that it is pretty painless, it's actually very painless. Um, and, yeah, it's quite easy to use once you get it. Um, you design simple views for each state in your application, and React will efficiently update and render the right components when your data changes. So basically this means that when you use React, your application state is kept separate from your DOM. You declare what your DOM should look like, given a certain, um, state that your application is in. Then when your application state changes, your DOM changes as a result of that, but React controls this change. You don't control this change. You only manage the state and what the state, and what the DOM is supposed to look like given a state. Uh, and then finally, declarative views make your code more predictable and easier to debug. It also makes your code a heck of a lot easier to test. So, how a declarative component compares with doing things the interpretive way with, uh, jQuery? Let's say you've got a very simple page. You've got a button and a div, and you'll have two views where state one is the button shows the word hide, and the div is there. State two, the button shows the word show, and the div is not there. This is how you'd code it out in jQuery. Um, I'm not including the actual HTML page where the DOM elements are declared, but you'd have a JavaScript file. You'd bind the click event to your button. That click event will call a function every time it's fired. That function's gonna check what state the div is in, uh, whether the div is visible or not, and then interpret from that state whether or not the, um, div should still be showing. It'll interpret your application state based on what it sees, and from that interpretation, it's either gonna show the div or hide the div. The state is interpreted from your DOM. I know this is really bad jQuery, by the way. Um, but, yeah, how you would do the same thing in React, it's gonna look very differently. React uses components. We already talked about that a bit, and, uh, this file represents a single React component. The, uh, easiest way to think about components is as a container for some part of your UI, and, uh, this code looks, uh, it uses ES6, so it might look a little bit different than the JavaScript that you used to seeing. We'll talk about that for just one second. ES6 is the 2015 JavaScript specification. It adds a whole bunch of stuff to JavaScript that never was there before. It adds classes. It adds modules, so you can import and export JavaScript, uh, from files just like you can with, uh, Python packages. It adds iterators and generators, promises. Uh, there's also an ES7, which was finalized, uh, last month, but isn't really widely supported yet. The point is, though, JavaScript's evolving, and as it does, it's becoming way more Pythonic. Uh, these are a handful of tweets that I found, just of people noticing the similarities between modern JavaScript and Python, my favorite, um, is, it turns out ES, it's up in the corner on the right, turns out ES6 is basically Python with the added bonus of irritating front-end devs. Uh, and this is me joking a year ago that by the time they get to ES9, JavaScript and Python are going to be syntactically identical. Um, so back to the React component that we're looking at, it represents a single section of your UI, and it does two things, um, inside. Uh, the first thing that it does is it manages the state of this UI section, and the second thing it does is it renders the component itself. It actually renders the DOM elements based on this state. The internal functions, I collapse them, uh, so that we can see the component as a whole at the top. Uh, we have the, um, we import React and component, uh, because this file is going to be a React component. We create our component as a class that extends the base React component. We can do that now. Um, inside our class, inside our React component, we have three functions. The constructor, a function called toggle showing, and the render function. And then we'll look at all three of those in a moment. But all the way at the bottom, uh, we have our export statement to export the component. So this is one thing that Python and JavaScript are a little bit different, um, on. In Python, every named object is exported automatically. In JavaScript, you have to explicitly export the things that you want to export, um, to be able to import them somewhere else. So let's go back and look at those three internal functions. The constructor looks like this. It sets the properties and the initial state of your component. Uh, we haven't talked about, uh, properties and we probably won't get a chance to talk about them, but they're essentially immutable parameters that, that come from other components. You cannot change them in the context of the component that you're looking at. In this case, there are no properties, but there is some state. There's a state made up of a single Boolean saying whether or not the div is showing. Toggle showing is a function that when called, toggles the is showing value, the state, from true to false or from false to true. Uh, we use this.setState to do that. It's how you manage internal state inside a react component. And then finally, the render function is exactly what you'd expect it to be. It's what, it's what gets rendered. In this case, one of two things can be rendered and it all depends on the value of this.state.isShowing. What's rendered is JSX. It's very similar to HTML, but you can use variables inside JSX the same way that you can use variables inside, um, Django templates. And, uh, yeah, I just want to talk for a second about the onClick property that we put on each one of those, um, buttons. It calls that toggle showing function that we defined that switches the internal state. And since the component states change, the component is then re-rendered based on the new state. If you've ever heard the expression data down actions up or one way data binding or one directional data binding, this is what people are talking about. When you hit the click button, that action, the onClick event travels up the component. It changes the component state and then that new state causes the render function to be recalled based on that new state and that data flows down. The actions go up and the data goes down. Back to the why. It might not seem like this pattern is any easier and it's definitely a more, um, complicated pattern for simple sites. Um, in this example, there's very little state where react shines is in examples where there is a lot of state to manage and when different components are affected by the same state. So that brings us to the components themselves. React, if you haven't picked up on this already, is component based. You build encapsulated components that each manage their own state and then you compose them to make complicated UIs. Since the component logic is written in JavaScript instead of templates, you can easily pass rich data through your app and keep state totally unrelated to your DOM. So we just built a single component. The way to build a complex React UI is to assemble these single components together like Legos. Your React app shouldn't be a monolith. It should be a collection of components that each ideally does a single thing or renders a single part of your UI. So let's look at an example where you have a single page app that has two views, a landing page and a pricing page. We want to build this as a single page app. So the top of our component, so the top component in our tree is going to be the same in both cases. I think I called it index. Having the same parent all the way at the top, that's what makes it a single page app. There's a plugin called React Router that I'm not going to have time to cover. It handles URL routing inside a React app, but I just wanted to let you know it exists. And then the index component is going to render one of two possible components based on the properties it gets from React Router. It's going to either render landing or pricing. Landing is a component that renders your landing page. Pricing is a component that renders your pricing page. Each of those pages might be made up by other components, might be made up by a whole tree of other components. But the render page of your index method is going to look something like this. Where our top component index is not rendering HTML, it's rendering other components based on the properties that it gets from the router. So render can render one of two things. It can actually render DOM or it can render other components that eventually further down the tree, render DOM. And when the path name from your router changes, what's rendered changes without a page reload. So your application is built like a giant tree where the current view is made up of all of the components being rendered all the way down to the base of the tree. And when your application state changes, all the components below it that are being rendered are going to internally check whether they need to change too. And if they do, they'll re-render. It sounds like that would be super inefficient. The way that it works is actually very efficient. I'm not going to get into that, but it's really fast and performant. There's way more to say about React, but I want to bring it back and show you how to integrate React with a Django project because that's what this talk is about. So lightning round. This is how you get started using Django and React together. The first thing is that you need Node for it. Node is what's going to manage all of your JavaScript packages, including React. So you want to install Node and NPM, which is the Node package manager, and then you want to initialize NPM inside your Django project. And this is going to create a file called package.json, and package.json is similar in terms of what it does to requirements.txt for PIP. You want to install the Node packages that you need, and the way to do this is NPM install package name and then have a little flag at the end to define whether you want that package installed globally, whether you want that package installed for dev dependencies for development only, or for development and production. So here is what selection from my package.json from one of my projects. Just a couple of things. These are all the dependencies for this project that's needed for prod and also for dev. A couple of things to focus in on. All of the stuff that starts with Babel. Babel is a shim, for lack of a better word, that takes your ES 2016 or 2015, your ES6 JavaScript, and reduces it down to JavaScript that older browsers can read. Radium is a package that you probably won't use in a typical React project. I like it a lot because I have the Vendetta against CSS, and one of the things that React lets you do is eliminate all CSS. Radium helps you do it by letting you do media queries within React without using CSS. Webpack stuff, all the stuff that starts with Webpack. Webpack is a module builder. It builds the bundle for your app that your Django template is going to read from and build the app from, both for prod and for dev. It's probably for you going to eliminate the need for tools like grunt and gulp. It also gives you hot reloading. Just like when you change a Python file, your server restarts. When you change a JavaScript file, your known server will be able to restart if you use Webpack. It's not the only way to do it. It's just kind of the preferred way to do it, I guess, or a preferred way to do it. Finally, something that I am probably not going to get a chance to talk about is Redux, which is something you should learn and make use of. It's a package. It's also a pattern for managing an updating application state that lets all of the state updates happen in the same place. So you can simplify state management even further and also put dev tools there so it's easier to see what's going on. So, yeah, the next step is learn Redux. It's 100% worth the time it takes to learn. There's a really good video course by the creator of Redux that I linked to here. I'll publish these slides afterwards, by the way, but you should definitely check that out if you care to learn React. Then the next step is you make a server.js file. This is the file that you use to run your known server in your dev environment. It's kind of like manage.py run server. You can do known.server.js to start your known server. It's, mine looks like this. And it basically just tells your webpack development server how to run, and it makes use of a configuration file where you store all your webpack configurations. Making that configuration file is the next step. The config file, I couldn't fit the whole thing on here. Let me see if I can actually, can you see that or no? Hang on. Can you see it now? No. All right. This is just to it. So I'm going to have to describe this without showing it, unfortunately. Now I've made it so that I can't see it. But in your webpack config, it gives you the ability to use different loaders, to use different modules, to use different inputs and outputs. The inputs, they're called entries, and the outputs, which is just called output, is the part that you're going to be most concerned about. What the output does is it tells webpack where to put that big old bundle that it creates, so that JavaScript knows where to, so that Django knows where to look for it. And then entry defines what the top component in your React component tree is. So if you want to slowly integrate React into an existing Django project, you might have multiple entries. A small React app inside Django to manage a small thing that can grow over time. But you can have multiple entry points, multiple React trees, I guess you would call them, and you would define them in your webpack config. I only have one, and I call it main. There we go. And I can see my notes again. But yeah, there's a gist to that in there. There's also your index.jsx file, which is your top most React file, which I included a gist to. And then two more components that index.jsx uses. AppRoot, which is where your apps roots are defined. And app.jsx, which is the uppermost component that has the potential to render DOM and not just render other components. It'll render other components too, but it can also render DOM, like a loading DOM. And then finally, here's how you hook the two of them together. You install Django webpack loader, which is a nice little package that lets you call your webpack bundle. So all of that React code and the other JavaScript packages that you're using lets you call that from inside a Django template. And you add webpack loader to your installed apps. And if you have multiple entry points, you'll want to do some additional configuration that's really well documented on webpack loader's GitHub. And then finally, the last step is inside a Django template, you load render bundle from webpack loader at the top of the page. And then inside the HTML of the page, we render the bundle that we're trying to render. We called it main in webpack config, so it just says render bundle main. And that's it. That is basically how to integrate it into a project. So I have more stuff that I can cover and I'm prepared to cover, but I figured now would be a decent time to stop for like two or three minutes of questions in case anyone wants to jump in because I know that it might be green territory. We use the same code base, it sounds amazing, but I would like to know what is the reality of that because I'm glad to say it's exactly the same, but I don't think you have your component, your logic, right, and then your render. Sure. You render different things, right, and you, in a web application, you have different components as well. So that, what is the reality of that? Yeah, I mean, I haven't worked too much with it, but I know several people that have the kind of, you're talking about with React Native, right? Yeah. So React, the, first of all, iOS React Native is more mature than Android React Native right now. So most of the problems that people are having seem to be coming from Android React Native. It's good for certain types of applications, applications that like render template views. It's bad for applications that are super animation heavy and have a lot of like interstitial animations is also what I've heard in terms of structuring that project. React lets you do it one of two different ways. Inside a component, you can render different code based on the, based on whether it is a web app or an iOS app or an Android app. Another thing that you can do is you can have different components to define what your app is. So you can have index component.jsx next to index component.ios.jsx and you will just import that as index component and React is smart enough to know that if you're building an iOS app, it wants to use the one that's iOS and if you're building, if it's a web app, it wants to use the one that's JSX. Does that answer it at all? Yes. Okay. Yeah, I mean, I think that the benefit is if you want your mobile app to do totally different things than your web app, you probably wouldn't. But if you want your mobile app, if it's really just a distribution game where you want your Android app and your iOS app to be very similar to one another, then being able to share the same code base, I think makes a heck of a lot of sense. So I have two quick questions. You mentioned Django Restraimer and React. Yeah. What's the workflow look like for login, for example, and sending back a CSRF token? Am I simply just grabbing that token on the JavaScript side from the cookie and impending it to a request? Yeah. Or what's the React way of doing that? Yeah, I'll show you some code afterwards or if you're around for the next couple of days. The way that I do it is I have Ajax calls inside my Redux workflow where I make a, from the perspective of a component, I just have a call that says get artists or something like that. And inside that get artists function that I'll define, it's going to check what artists I already have in my Redux store. Redux is kind of like the back end of your front end, and I'm getting deeper than I wanted to on this, but it'll check if I need to make a fetch. First of all, it'll check if I need to make an Ajax call. If I do, it'll make that Ajax call, get the response, and then load it into my browser's local store. Okay, cool. Yeah, I appreciate that that probably doesn't fully answer your question. No, that's a good sense. My next question is, React can get really complicated, as you know. You can have models and a lot of business logic on the front end. You can do the same thing on the back end. In your experience, how do you handle where that logic should land as far as Django models or models in React? Where do we draw that line? Sure, React doesn't have models, it has modules. So you're like importing modules from, it's not like Django models so much. Yes, your React data stores could be similar to modules, but those would be populated by your Django models. So what I would typically do is I would get the data from Django, put it into React, so I don't have to get it again if I need it again, and sort of use it the same way that you would kind of use like SQLite, if you were building an iOS app where you have like a local data store just for that user, just for that session. And then everything else just lives in Django, and you have a workflow where you check if you need it. If you do, you grab it from Django. If you already have it, then you don't. Thanks. Yeah, of course. Hey, it's a lovely talk. I've really been appreciating a lot of the conversation I've heard around Django and React together. My question for you is about style management and CSS. You don't like CSS, and then you're using Radium for a media queries. Sure. Are you using any other libraries? Khan Academy has one, I forget the name of it, to manage inline styles in virtual DOM elements? No. I'm not using those. Basically, my CSS is, so I've put a kind of rigid separation between components that render pages are only made up of other DOM components that don't manage any internal state. So I have a component for button, and I have a component for div and things like that. And I define what those should look like by passing props to them, and then all of the Radium calls are done internally. And I really actually only use Radium for the hover and focus media queries, things like that, for things like width. I do that declaratively by having a reducer that manages the window width so I can access that in declarative fashion. Does that answer your question? Yeah, it does a bit. How do you reuse any style share between components? Sure. You just have it inherit from a parent. Like, if you're using the same button everywhere, you really don't have to. You're importing the button into your component, so it's not like your button almost becomes a composite of the DOM element and also the style in the same way that it would be if you had a button that you put, like, I don't know, a button success on if you're using bootstrap. Right. Thank you. Yeah. My question is about a little bit of architecture or maybe deciding when you are where you should migrate your application to something like React. Like, for example, the the button example that you made is trivial in jQuery, right? Yep. But how do you know when, hey, I could really use something that manages my state instead of just adding classes to my stuff and checking with jQuery. But, you know, installing React is not like, oh, oh, one command thing. Right. You really have to commit to it. It's probably going to change your build and a bunch of stuff. Yeah. So when do you know, hey, we should really be using something more robust than just jQuery, you know? I mean, I would say if you're starting a new project and you already know React, it makes a lot of sense because it's no harder to do it that way if you're starting from scratch. If you have an existing project that isn't using React, I mean, you'll know when you're spending a lot of time debugging jQuery because managing state is an issue. So like how you do that exact calculus of whether or not the investment is worth it really has a lot to do with how much of a headache it is to fix problems that happen when you're state and you're DOM or like intermixed. So. Thanks for the talk. I have heard a lot of different opinions about combining like front end and back end, especially in our Django projects. And I'm wondering how you handle packaging up your project for deployment since a lot of people have opinions about separating front end and back end bundles and whatnot. Sure. I mean, a lot of people that I work with are really against having PIP be dependent on NPM. And I tend to agree with them, but I wanted to see what you thought about that. Yeah, I mean, I tend to agree with that as well. Like Python Django has to run on the server. It's back end. React can either be deployed on the server or on the client. It's front end. I like to keep them separate. Yeah. Does that answer your question? Thanks for the talk. This really demystifies React and makes it clear this is a state based view technology. Yep. So the previous questioner somewhat got into the issue that I wanted to know about, which is when you're in development, you mentioned running Node. Both as sort of compass like watcher and also as a server for development to serve up some resources Django is going to call for. In production and deployment, I gather that you don't do that. And I just wanted to verify that that's true. That's exactly right. Yeah. Okay. Thank you. So, cool. We have five minutes left. There's any more questions if not I'll jump into some stuff that I wanted to cover but didn't have time to. Awesome. So stuff I wish I had time to cover. This is also a really good like, I don't know, study guide for what to do next if you're going to start doing any React development. The first thing is the component lifecycle. So inside every React component, there are seven things that can potentially change the props or the state of that React component. It's only seven, but knowing what they are, knowing when they're called in terms of when a component gets instantiated, when a component gets released. They call it mounted and unmounted can be really helpful. I have a slide in this deck that you can look at that like does a brief description of what each one of them is. The next thing is flux and redux. So flux was the little history. React came out. Some people found that managing state in between components in React was sometimes challenging. Someone solved it with a pattern called flux that let state be stored in one place relative to a component. And then other components lower down the tree would access that state indirectly. They would access that state as properties, so they couldn't edit it directly. But then they could pass actions back to a flux store that would then cause it all to update. The problem with that is you would have a whole bunch of different flux stores at different levels of your app. Redux, which is kind of a flux-like architecture that everyone's moving towards, it is like flux, except it says all of your state transformations, all of your state transitions should happen in exactly the same place, in a redux store, a reducer. And what that lets you do is you have your application state all in exactly one place as a giant json tree, basically. And your application renders from that. And if you want to change anything in your application, if you have a button click or whatever, you don't do it internally in the component. You dispatch an action to your redux store. And what redux does is it preserves your last state, but also creates a new state for your app to transition into. What it lets you do is debug things a lot more easily because you have what your state was and what your state now is. So any time, you can hook up so that any time an error gets thrown for a user, that it sends their entire state history to a server so that you can debug more easily. It lets you see what your application state is all at one time, all in one place. It's super useful to learn. React Router and Redux Router, those are the two routers that people use for URL routing inside of a React app. They do essentially the same thing. React Router is simple and perfect for most apps. Redux Router adds some more functionality that React Router doesn't have. It's probably too complicated. It's probably over-engineering for most apps, but if you need it, it's great. And then, yeah, I will put some gists for authentication and access restriction using Django because that's something that I kind of scratched my head on for a while. I'll add that to the slide before I publish it. Basically, you wrap your components inside an authentication wrapper that checks whether or not a user is logged in prior to rendering the component. And then, yeah. Cool. I'll guess I'll end with this. Routing React isn't hard because it's hard. It's hard because it includes a heck of a lot of patterns that you're probably not already familiar with if you haven't used it before. There are a bunch of little things to learn that are each easy on their own, but altogether, it makes learning React feel overwhelming at the beginning, or at least it did for me. But once you know React, it can make state management inside a complicated app much, much easier. It plays really nice with Django because it doesn't try to do the stuff that Django already does well. It tries to do one thing, manage your templates, and it does a really, really good job at that. So like I said, feel free to reach out to me. I'm on Twitter, I'm on GitHub, and I'll be here for the next couple of days for the sprints. Thank you all so much for your time. Thank you.
 Come on, y'all!  MUSIC  Hi, everyone.  Um, so my name is Jack, and I have to...  There we go.  Cool. I'm a software developer from New York City,  and one of the reasons why I'm giving this talk is most of my recent projects,  three out of my last four recent projects were Django projects that also used React.  So I've dug deep into how the two can fit together,  and I really like how they fit together.  Hopefully, um, some... Has anyone here worked on any React projects?  Okay, so a handful.  So not a room full of beginners. That's exciting.  If you are a beginner, I kind of geared this talk for people who know Django,  but haven't really used React yet,  or kind of just thinking about it and looking at it.  So, um, I've been a Django user for over five years,  a React user for about the last year or so, a little longer than that,  and for what it's worth, I don't consider myself to be any kind of expert on either of those things,  just someone who put in a lot of time working on Django projects and React projects,  and might have a little bit to share.  Um, I'm gonna try and talk fast.  If I talk too fast, slow me down, but, um, it's kind of a broad scope to this talk,  so I'm more worried about not having enough time than I am about, like, filling time.  I'll try and save some time for Q&A at the end, but that's my contact info.  You can hit me up on Twitter or GitHub if you have any questions that we didn't have time for today.  And I'll also be around for the next couple days for the sprints.  So, what are the goals of this talk?  Uh, the title of the talk really could be a crash course in React for people who already know Django.  Um, the first goal is to understand what React does, how React works,  because a lot of people are talking about it, and people in the Django community,  some people have kicked the tires on it, some people have used it heavily, but a lot of people haven't.  So, it's kind of an intro to React for Django people.  Um, and the goal is to build a mental map for React so that you know how to think about it.  It's going to take longer than a 45-minute talk to build a good mental map for React,  but hopefully this will be a good primer.  Um, we're going to become familiar with some of the key parts of a React project  and learn how to set up a React project inside of a Django environment.  Um, one of the other big challenges of learning React is that a lot of React projects  and most of the React boilerplate examples use JSX and a quote-unquote new JavaScript, ES6 or ES7.  Um, so we'll be diving into a little bit of that just so you know what you're looking at.  Um, it's one of the things that can add some intimidation to learning React.  And then finally, we'll bring it all together by showing how Django and React can fit together in, uh, in a project.  And we're actually going to start here a little bit at a high-level view, um, before digging into the, uh, React part.  We'll look at the separation of concerns in a Django and React project that uses both.  So Django follows the MVC pattern for building user interfaces.  Uh, in the MVC pattern, uh, there are three parts, the model, the view, and the controller, and they're all interconnected.  This is kind of how they're interconnected.  The model updates the view.  The view is what's seen by the user.  The user can do stuff to manipulate the controller.  Um, this is based on the user's interaction with the view.  And then the controller, uh, updates the model.  This is how Django works sort of.  Um, there's a cool question on the Django fact page.  Um, Django appears to be an MVC framework, but you call the controller the view and the view the template.  How come you don't use the standard names?  And the answer that Django gives is in our interpretation of MVC, the view describes the data that gets presented to the user.  It's not necessarily how the data looks, but what data is being presented.  Uh, it's sensible to separate content from presentation, and that's where Django templates come in.  It's kind of a pedantic answer to, uh, that question, but that's also part of the reason why I like it.  But what they're saying essentially is that in Django, the view part of the MVC is split into two things.  The view that you keep in views.py that renders data to your templates that actually are the view that the user sees.  So the map of an MVC from Django's perspective looks more like this, where the model corresponds to your models.py file,  your views corresponds to your views.py, they render data to your templates, um, which is what the user sees.  Uh, he or she interacts with the templates to manipulate the controller, which is kind of like the framework itself,  and the controller updates the model.  React fits here. React fits where the templates are.  It replaces, uh, your Django templates, and based on how the user interacts with those templates,  dispatches actions that then update Django, that update the controller.  So this is what your MVC looks like in a React project.  Um, the first thing about React, uh, to understand is that it's not a full MVC framework, and it doesn't try to be.  Uh, if you use it in a Django project, it'll fit where your templates, um, used to fit.  It won't replace anything else in a Django project.  Um, and keep in mind, templates, like it's the broad view of templates.  It's not just the templates files, but also the files and packages that your templates use.  JQuery, potentially CSS, all of your JavaScript files, uh, that are imported into your templates.  So, why would you want to do this?  Django templates work perfectly well.  Why would you want to start, uh, stop using them and start using something that is significantly more complicated?  No, sorry about that. Uh, that you have to learn from scratch, and that's outside the Django ecosystem that you already know real well and love.  Um, and the answer to that is maybe you don't.  Maybe you don't want to use React, and it would be overengineering to use React.  Uh, Django templates are perfectly fine for plenty of sites, um, and we all know that because we've used that for plenty of sites.  They work.  Um, but React lets you do certain things that would be really, really hard to do, if not impossible to do, um, using just Django templates.  The first thing, um, that React templates let you do is it lets you turn your site into a single page app.  Um, from the user's perspective, single page apps, when they're built the right way, they are faster, they feel more modern.  Um, it's something that's really been popular in the JavaScript community for a couple of years now, and has been a little bit slower to become popular in the Django community.  And the, uh, Ruby community, I know that channels are doing some work to be able to use templates to build single page apps, but this is a big reason why React is deserving of a look.  Another thing that you get with React is the ability to reuse parts of your code base for iOS and Android in addition to just your web app.  Um, I'm not going to dive too much into this, um, but it basically works like this.  Your React, your React templates are made up of components.  They're like building blocks that you assemble together to form your UI, and each one of those building blocks does two things.  It performs some internal logic, and then based on that internal logic, it renders a chunk of what your users see.  It renders a chunk of UI.  With React Native, you get to keep the part of your templates that perform that logic and use them across platforms,  and then render out different code, either HTML or, uh, iOS or Java, based on the platform that the user is using.  And then finally, and this is probably the biggest reason why React is, quote, on as big as it has, is it makes it much easier to manage and manipulate complicated state.  Um, in most small projects, there isn't complicated state. The state is simple.  So there's not much to manage. You can keep it all in your head more or less.  When you start working on a bigger project, um, managing state can become a real nightmare, and I'm sure it's something that you've, uh, potentially run into.  That is the biggest selling point of React and the biggest thing that it makes much, much easier.  So we're going to zoom in for a bit on the React part of this map, um, so that you can understand, uh, and get a feel for that.  And then we're going to zoom back out and look at how Django and React work together as part of a full system.  Oh, and one more thing. Since one, uh, since React is taking care of your UI, your views are going to feed it raw data.  Uh, your view layer is really just an API layer. React doesn't care what the rest of your stack is, but using something like Django REST framework is, uh, it makes a heck of a lot of sense, um, because then your views are just an API layer by default.  So the homepage for React highlights a couple of things that differentiate it from other UI frameworks.  Um, if you understand these three things, you'll understand the fundamentals of React.  The first one we already talked about, it's that React doesn't make assumptions about the rest of your technology stack.  React is your UI layer. It provides a really good tool set, arguably the best tool set for, uh, building your UI, and it doesn't try to do anything else other than that.  The second point on the homepage is that React is declarative, and this one is a little bit tougher to grok.  Um, React makes it painless to create interactive UIs. You might put an asterisk after the word painless.  Um, it's painless once you go through the significant pain of, like, learning how to use it, but once you understand that it is pretty painless, it's actually very painless.  Um, and, yeah, it's quite easy to use once you get it.  Um, you design simple views for each state in your application, and React will efficiently update and render the right components when your data changes.  So basically this means that when you use React, your application state is kept separate from your DOM.  You declare what your DOM should look like, given a certain, um, state that your application is in.  Then when your application state changes, your DOM changes as a result of that, but React controls this change.  You don't control this change. You only manage the state and what the state, and what the DOM is supposed to look like given a state.  Uh, and then finally, declarative views make your code more predictable and easier to debug.  It also makes your code a heck of a lot easier to test.  So, how a declarative component compares with doing things the interpretive way with, uh, jQuery?  Let's say you've got a very simple page. You've got a button and a div, and you'll have two views where state one is the button shows the word hide, and the div is there.  State two, the button shows the word show, and the div is not there.  This is how you'd code it out in jQuery. Um, I'm not including the actual HTML page where the DOM elements are declared,  but you'd have a JavaScript file. You'd bind the click event to your button.  That click event will call a function every time it's fired.  That function's gonna check what state the div is in, uh, whether the div is visible or not, and then interpret from that state whether or not the, um,  div should still be showing. It'll interpret your application state based on what it sees,  and from that interpretation, it's either gonna show the div or hide the div.  The state is interpreted from your DOM. I know this is really bad jQuery, by the way.  Um, but, yeah, how you would do the same thing in React, it's gonna look very differently.  React uses components. We already talked about that a bit, and, uh, this file represents a single React component.  The, uh, easiest way to think about components is as a container for some part of your UI,  and, uh, this code looks, uh, it uses ES6, so it might look a little bit different than the JavaScript that you used to seeing.  We'll talk about that for just one second.  ES6 is the 2015 JavaScript specification. It adds a whole bunch of stuff to JavaScript that never was there before.  It adds classes. It adds modules, so you can import and export JavaScript, uh, from files just like you can with, uh, Python packages.  It adds iterators and generators, promises. Uh, there's also an ES7, which was finalized, uh, last month, but isn't really widely supported yet.  The point is, though, JavaScript's evolving, and as it does, it's becoming way more Pythonic.  Uh, these are a handful of tweets that I found, just of people noticing the similarities between modern JavaScript and Python, my favorite, um, is, it turns out ES, it's up in the corner on the right,  turns out ES6 is basically Python with the added bonus of irritating front-end devs.  Uh, and this is me joking a year ago that by the time they get to ES9, JavaScript and Python are going to be syntactically identical.  Um, so back to the React component that we're looking at, it represents a single section of your UI, and it does two things, um, inside.  Uh, the first thing that it does is it manages the state of this UI section, and the second thing it does is it renders the component itself.  It actually renders the DOM elements based on this state.  The internal functions, I collapse them, uh, so that we can see the component as a whole at the top.  Uh, we have the, um, we import React and component, uh, because this file is going to be a React component.  We create our component as a class that extends the base React component.  We can do that now.  Um, inside our class, inside our React component, we have three functions.  The constructor, a function called toggle showing, and the render function.  And then we'll look at all three of those in a moment.  But all the way at the bottom, uh, we have our export statement to export the component.  So this is one thing that Python and JavaScript are a little bit different, um, on.  In Python, every named object is exported automatically.  In JavaScript, you have to explicitly export the things that you want to export, um, to be able to import them somewhere else.  So let's go back and look at those three internal functions.  The constructor looks like this.  It sets the properties and the initial state of your component.  Uh, we haven't talked about, uh, properties and we probably won't get a chance to talk about them,  but they're essentially immutable parameters that, that come from other components.  You cannot change them in the context of the component that you're looking at.  In this case, there are no properties, but there is some state.  There's a state made up of a single Boolean saying whether or not the div is showing.  Toggle showing is a function that when called,  toggles the is showing value, the state, from true to false or from false to true.  Uh, we use this.setState to do that.  It's how you manage internal state inside a react component.  And then finally, the render function is exactly what you'd expect it to be.  It's what, it's what gets rendered.  In this case, one of two things can be rendered and it all depends on the value of this.state.isShowing.  What's rendered is JSX. It's very similar to HTML, but you can use variables inside JSX  the same way that you can use variables inside, um, Django templates.  And, uh, yeah, I just want to talk for a second about the onClick property  that we put on each one of those, um, buttons.  It calls that toggle showing function that we defined that switches the internal state.  And since the component states change, the component is then re-rendered based on the new state.  If you've ever heard the expression data down actions up or one way data binding  or one directional data binding, this is what people are talking about.  When you hit the click button, that action, the onClick event travels up the component.  It changes the component state and then that new state causes the render function  to be recalled based on that new state and that data flows down.  The actions go up and the data goes down.  Back to the why. It might not seem like this pattern is any easier  and it's definitely a more, um, complicated pattern for simple sites.  Um, in this example, there's very little state where react shines is in examples  where there is a lot of state to manage and when different components are affected by the same state.  So that brings us to the components themselves.  React, if you haven't picked up on this already, is component based.  You build encapsulated components that each manage their own state  and then you compose them to make complicated UIs.  Since the component logic is written in JavaScript instead of templates,  you can easily pass rich data through your app and keep state totally unrelated to your DOM.  So we just built a single component. The way to build a complex React UI is to assemble these single components together like Legos.  Your React app shouldn't be a monolith.  It should be a collection of components that each ideally does a single thing  or renders a single part of your UI.  So let's look at an example where you have a single page app that has two views,  a landing page and a pricing page.  We want to build this as a single page app.  So the top of our component, so the top component in our tree is going to be the same in both cases.  I think I called it index.  Having the same parent all the way at the top, that's what makes it a single page app.  There's a plugin called React Router that I'm not going to have time to cover.  It handles URL routing inside a React app, but I just wanted to let you know it exists.  And then the index component is going to render one of two possible components based on the properties it gets from React Router.  It's going to either render landing or pricing.  Landing is a component that renders your landing page.  Pricing is a component that renders your pricing page.  Each of those pages might be made up by other components, might be made up by a whole tree of other components.  But the render page of your index method is going to look something like this.  Where our top component index is not rendering HTML,  it's rendering other components based on the properties that it gets from the router.  So render can render one of two things.  It can actually render DOM or it can render other components that eventually further down the tree, render DOM.  And when the path name from your router changes, what's rendered changes without a page reload.  So your application is built like a giant tree where the current view is made up of all of the components being rendered all the way down to the base of the tree.  And when your application state changes, all the components below it that are being rendered are going to internally check whether they need to change too.  And if they do, they'll re-render.  It sounds like that would be super inefficient.  The way that it works is actually very efficient.  I'm not going to get into that, but it's really fast and performant.  There's way more to say about React, but I want to bring it back and show you how to integrate React with a Django project because that's what this talk is about.  So lightning round.  This is how you get started using Django and React together.  The first thing is that you need Node for it.  Node is what's going to manage all of your JavaScript packages, including React.  So you want to install Node and NPM, which is the Node package manager, and then you want to initialize NPM inside your Django project.  And this is going to create a file called package.json, and package.json is similar in terms of what it does to requirements.txt for PIP.  You want to install the Node packages that you need, and the way to do this is NPM install package name and then have a little flag at the end to define whether you want that package installed globally,  whether you want that package installed for dev dependencies for development only, or for development and production.  So here is what selection from my package.json from one of my projects.  Just a couple of things.  These are all the dependencies for this project that's needed for prod and also for dev.  A couple of things to focus in on.  All of the stuff that starts with Babel.  Babel is a shim, for lack of a better word, that takes your ES 2016 or 2015, your ES6 JavaScript, and reduces it down to JavaScript that older browsers can read.  Radium is a package that you probably won't use in a typical React project.  I like it a lot because I have the Vendetta against CSS, and one of the things that React lets you do is eliminate all CSS.  Radium helps you do it by letting you do media queries within React without using CSS.  Webpack stuff, all the stuff that starts with Webpack.  Webpack is a module builder.  It builds the bundle for your app that your Django template is going to read from and build the app from, both for prod and for dev.  It's probably for you going to eliminate the need for tools like grunt and gulp.  It also gives you hot reloading.  Just like when you change a Python file, your server restarts.  When you change a JavaScript file, your known server will be able to restart if you use Webpack.  It's not the only way to do it.  It's just kind of the preferred way to do it, I guess, or a preferred way to do it.  Finally, something that I am probably not going to get a chance to talk about is Redux, which is something you should learn and make use of.  It's a package.  It's also a pattern for managing an updating application state that lets all of the state updates happen in the same place.  So you can simplify state management even further and also put dev tools there so it's easier to see what's going on.  So, yeah, the next step is learn Redux.  It's 100% worth the time it takes to learn.  There's a really good video course by the creator of Redux that I linked to here.  I'll publish these slides afterwards, by the way, but you should definitely check that out if you care to learn React.  Then the next step is you make a server.js file.  This is the file that you use to run your known server in your dev environment.  It's kind of like manage.py run server.  You can do known.server.js to start your known server.  It's, mine looks like this.  And it basically just tells your webpack development server how to run, and it makes use of a configuration file where you store all your webpack configurations.  Making that configuration file is the next step.  The config file, I couldn't fit the whole thing on here.  Let me see if I can actually, can you see that or no?  Hang on. Can you see it now?  No. All right. This is just to it.  So I'm going to have to describe this without showing it, unfortunately.  Now I've made it so that I can't see it.  But in your webpack config, it gives you the ability to use different loaders, to use different modules, to use different inputs and outputs.  The inputs, they're called entries, and the outputs, which is just called output, is the part that you're going to be most concerned about.  What the output does is it tells webpack where to put that big old bundle that it creates, so that JavaScript knows where to, so that Django knows where to look for it.  And then entry defines what the top component in your React component tree is.  So if you want to slowly integrate React into an existing Django project, you might have multiple entries.  A small React app inside Django to manage a small thing that can grow over time.  But you can have multiple entry points, multiple React trees, I guess you would call them, and you would define them in your webpack config.  I only have one, and I call it main.  There we go. And I can see my notes again.  But yeah, there's a gist to that in there. There's also your index.jsx file, which is your top most React file, which I included a gist to.  And then two more components that index.jsx uses.  AppRoot, which is where your apps roots are defined.  And app.jsx, which is the uppermost component that has the potential to render DOM and not just render other components.  It'll render other components too, but it can also render DOM, like a loading DOM.  And then finally, here's how you hook the two of them together.  You install Django webpack loader, which is a nice little package that lets you call your webpack bundle.  So all of that React code and the other JavaScript packages that you're using lets you call that from inside a Django template.  And you add webpack loader to your installed apps.  And if you have multiple entry points, you'll want to do some additional configuration that's really well documented on webpack loader's GitHub.  And then finally, the last step is inside a Django template, you load render bundle from webpack loader at the top of the page.  And then inside the HTML of the page, we render the bundle that we're trying to render.  We called it main in webpack config, so it just says render bundle main.  And that's it. That is basically how to integrate it into a project.  So I have more stuff that I can cover and I'm prepared to cover, but I figured now would be a decent time to stop for like two or three minutes of questions  in case anyone wants to jump in because I know that it might be green territory.  We use the same code base, it sounds amazing, but I would like to know what is the reality of that because I'm glad to say it's exactly the same,  but I don't think you have your component, your logic, right, and then your render.  Sure.  You render different things, right, and you, in a web application, you have different components as well.  So that, what is the reality of that?  Yeah, I mean, I haven't worked too much with it, but I know several people that have the kind of, you're talking about with React Native, right?  Yeah.  So React, the, first of all, iOS React Native is more mature than Android React Native right now.  So most of the problems that people are having seem to be coming from Android React Native.  It's good for certain types of applications, applications that like render template views.  It's bad for applications that are super animation heavy and have a lot of like interstitial animations is also what I've heard in terms of structuring that project.  React lets you do it one of two different ways.  Inside a component, you can render different code based on the, based on whether it is a web app or an iOS app or an Android app.  Another thing that you can do is you can have different components to define what your app is.  So you can have index component.jsx next to index component.ios.jsx and you will just import that as index component and React is smart enough to know that if you're building an iOS app,  it wants to use the one that's iOS and if you're building, if it's a web app, it wants to use the one that's JSX.  Does that answer it at all?  Yes.  Okay.  Yeah, I mean, I think that the benefit is if you want your mobile app to do totally different things than your web app, you probably wouldn't.  But if you want your mobile app, if it's really just a distribution game where you want your Android app and your iOS app to be very similar to one another,  then being able to share the same code base, I think makes a heck of a lot of sense.  So I have two quick questions.  You mentioned Django Restraimer and React.  Yeah.  What's the workflow look like for login, for example, and sending back a CSRF token?  Am I simply just grabbing that token on the JavaScript side from the cookie and impending it to a request?  Yeah.  Or what's the React way of doing that?  Yeah, I'll show you some code afterwards or if you're around for the next couple of days.  The way that I do it is I have Ajax calls inside my Redux workflow where I make a, from the perspective of a component, I just have a call that says get artists or something like that.  And inside that get artists function that I'll define, it's going to check what artists I already have in my Redux store.  Redux is kind of like the back end of your front end, and I'm getting deeper than I wanted to on this, but it'll check if I need to make a fetch.  First of all, it'll check if I need to make an Ajax call.  If I do, it'll make that Ajax call, get the response, and then load it into my browser's local store.  Okay, cool.  Yeah, I appreciate that that probably doesn't fully answer your question.  No, that's a good sense.  My next question is, React can get really complicated, as you know.  You can have models and a lot of business logic on the front end.  You can do the same thing on the back end.  In your experience, how do you handle where that logic should land as far as Django models or models in React?  Where do we draw that line?  Sure, React doesn't have models, it has modules.  So you're like importing modules from, it's not like Django models so much.  Yes, your React data stores could be similar to modules, but those would be populated by your Django models.  So what I would typically do is I would get the data from Django, put it into React,  so I don't have to get it again if I need it again, and sort of use it the same way that you would kind of use like SQLite,  if you were building an iOS app where you have like a local data store just for that user, just for that session.  And then everything else just lives in Django, and you have a workflow where you check if you need it.  If you do, you grab it from Django.  If you already have it, then you don't.  Thanks.  Yeah, of course.  Hey, it's a lovely talk.  I've really been appreciating a lot of the conversation I've heard around Django and React together.  My question for you is about style management and CSS.  You don't like CSS, and then you're using Radium for a media queries.  Sure.  Are you using any other libraries?  Khan Academy has one, I forget the name of it, to manage inline styles in virtual DOM elements?  No.  I'm not using those.  Basically, my CSS is, so I've put a kind of rigid separation between components that render pages are only made up of other DOM components that don't manage any internal state.  So I have a component for button, and I have a component for div and things like that.  And I define what those should look like by passing props to them, and then all of the Radium calls are done internally.  And I really actually only use Radium for the hover and focus media queries, things like that, for things like width.  I do that declaratively by having a reducer that manages the window width so I can access that in declarative fashion.  Does that answer your question?  Yeah, it does a bit.  How do you reuse any style share between components?  Sure.  You just have it inherit from a parent.  Like, if you're using the same button everywhere, you really don't have to.  You're importing the button into your component, so it's not like your button almost becomes a composite of the DOM element and also the style in the same way that it would be if you had a button that you put, like, I don't know, a button success on if you're using bootstrap.  Right.  Thank you.  Yeah.  My question is about a little bit of architecture or maybe deciding when you are where you should migrate your application to something like React.  Like, for example, the the button example that you made is trivial in jQuery, right?  Yep.  But how do you know when, hey, I could really use something that manages my state instead of just adding classes to my stuff and checking with jQuery.  But, you know, installing React is not like, oh, oh, one command thing.  Right.  You really have to commit to it.  It's probably going to change your build and a bunch of stuff.  Yeah.  So when do you know, hey, we should really be using something more robust than just jQuery, you know?  I mean, I would say if you're starting a new project and you already know React, it makes a lot of sense because it's no harder to do it that way if you're starting from scratch.  If you have an existing project that isn't using React, I mean, you'll know when you're spending a lot of time debugging jQuery because managing state is an issue.  So like how you do that exact calculus of whether or not the investment is worth it really has a lot to do with how much of a headache it is to fix problems that happen when you're state and you're DOM or like intermixed.  So.  Thanks for the talk.  I have heard a lot of different opinions about combining like front end and back end, especially in our Django projects.  And I'm wondering how you handle packaging up your project for deployment since a lot of people have opinions about separating front end and back end bundles and whatnot.  Sure.  I mean, a lot of people that I work with are really against having PIP be dependent on NPM.  And I tend to agree with them, but I wanted to see what you thought about that.  Yeah, I mean, I tend to agree with that as well.  Like Python Django has to run on the server.  It's back end.  React can either be deployed on the server or on the client.  It's front end.  I like to keep them separate.  Yeah.  Does that answer your question?  Thanks for the talk.  This really demystifies React and makes it clear this is a state based view technology.  Yep.  So the previous questioner somewhat got into the issue that I wanted to know about, which is when you're in development, you mentioned running Node.  Both as sort of compass like watcher and also as a server for development to serve up some resources Django is going to call for.  In production and deployment, I gather that you don't do that.  And I just wanted to verify that that's true.  That's exactly right.  Yeah.  Okay.  Thank you.  So, cool.  We have five minutes left.  There's any more questions if not I'll jump into some stuff that I wanted to cover but didn't have time to.  Awesome.  So stuff I wish I had time to cover.  This is also a really good like, I don't know, study guide for what to do next if you're going to start doing any React development.  The first thing is the component lifecycle.  So inside every React component, there are seven things that can potentially change the props or the state of that React component.  It's only seven, but knowing what they are, knowing when they're called in terms of when a component gets instantiated, when a component gets released.  They call it mounted and unmounted can be really helpful.  I have a slide in this deck that you can look at that like does a brief description of what each one of them is.  The next thing is flux and redux.  So flux was the little history.  React came out.  Some people found that managing state in between components in React was sometimes challenging.  Someone solved it with a pattern called flux that let state be stored in one place relative to a component.  And then other components lower down the tree would access that state indirectly.  They would access that state as properties, so they couldn't edit it directly.  But then they could pass actions back to a flux store that would then cause it all to update.  The problem with that is you would have a whole bunch of different flux stores at different levels of your app.  Redux, which is kind of a flux-like architecture that everyone's moving towards, it is like flux,  except it says all of your state transformations, all of your state transitions should happen in exactly the same place,  in a redux store, a reducer.  And what that lets you do is you have your application state all in exactly one place as a giant json tree, basically.  And your application renders from that.  And if you want to change anything in your application, if you have a button click or whatever,  you don't do it internally in the component.  You dispatch an action to your redux store.  And what redux does is it preserves your last state, but also creates a new state for your app to transition into.  What it lets you do is debug things a lot more easily because you have what your state was and what your state now is.  So any time, you can hook up so that any time an error gets thrown for a user,  that it sends their entire state history to a server so that you can debug more easily.  It lets you see what your application state is all at one time, all in one place.  It's super useful to learn.  React Router and Redux Router, those are the two routers that people use for URL routing inside of a React app.  They do essentially the same thing.  React Router is simple and perfect for most apps.  Redux Router adds some more functionality that React Router doesn't have.  It's probably too complicated.  It's probably over-engineering for most apps, but if you need it, it's great.  And then, yeah, I will put some gists for authentication and access restriction using Django  because that's something that I kind of scratched my head on for a while.  I'll add that to the slide before I publish it.  Basically, you wrap your components inside an authentication wrapper that checks whether or not a user is logged in  prior to rendering the component.  And then, yeah.  Cool. I'll guess I'll end with this.  Routing React isn't hard because it's hard.  It's hard because it includes a heck of a lot of patterns that you're probably not already familiar with  if you haven't used it before.  There are a bunch of little things to learn that are each easy on their own,  but altogether, it makes learning React feel overwhelming at the beginning, or at least it did for me.  But once you know React, it can make state management inside a complicated app much, much easier.  It plays really nice with Django because it doesn't try to do the stuff that Django already  does well.  It tries to do one thing, manage your templates, and it does a really, really good job at that.  So like I said, feel free to reach out to me.  I'm on Twitter, I'm on GitHub, and I'll be here for the next couple of days for the  sprints.  Thank you all so much for your time.  Thank you.
DjangoCon_US_2016_-_Django_and_React__Perfect_Together_by_Jack_McCloy_zYHv6U86X0Y_0_59.png DjangoCon_US_2016_-_Django_and_React__Perfect_Together_by_Jack_McCloy_zYHv6U86X0Y_60_155.png DjangoCon_US_2016_-_Django_and_React__Perfect_Together_by_Jack_McCloy_zYHv6U86X0Y_156_251.png DjangoCon_US_2016_-_Django_and_React__Perfect_Together_by_Jack_McCloy_zYHv6U86X0Y_252_371.png DjangoCon_US_2016_-_Django_and_React__Perfect_Together_by_Jack_McCloy_zYHv6U86X0Y_372_2675.png DjangoCon_US_2016_-_Django_and_React__Perfect_Together_by_Jack_McCloy_zYHv6U86X0Y_2676_5831.png DjangoCon_US_2016_-_Django_and_React__Perfect_Together_by_Jack_McCloy_zYHv6U86X0Y_5832_7199.png DjangoCon_US_2016_-_Django_and_React__Perfect_Together_by_Jack_McCloy_zYHv6U86X0Y_7200_9119.png DjangoCon_US_2016_-_Django_and_React__Perfect_Together_by_Jack_McCloy_zYHv6U86X0Y_9120_10475.png DjangoCon_US_2016_-_Django_and_React__Perfect_Together_by_Jack_McCloy_zYHv6U86X0Y_10476_10691.png DjangoCon_US_2016_-_Django_and_React__Perfect_Together_by_Jack_McCloy_zYHv6U86X0Y_10692_10883.png DjangoCon_US_2016_-_Django_and_React__Perfect_Together_by_Jack_McCloy_zYHv6U86X0Y_10884_11003.png DjangoCon_US_2016_-_Django_and_React__Perfect_Together_by_Jack_McCloy_zYHv6U86X0Y_11004_11195.png DjangoCon_US_2016_-_Django_and_React__Perfect_Together_by_Jack_McCloy_zYHv6U86X0Y_11196_14543.png DjangoCon_US_2016_-_Django_and_React__Perfect_Together_by_Jack_McCloy_zYHv6U86X0Y_14544_15323.png DjangoCon_US_2016_-_Django_and_React__Perfect_Together_by_Jack_McCloy_zYHv6U86X0Y_15324_17951.png DjangoCon_US_2016_-_Django_and_React__Perfect_Together_by_Jack_McCloy_zYHv6U86X0Y_17952_19667.png DjangoCon_US_2016_-_Django_and_React__Perfect_Together_by_Jack_McCloy_zYHv6U86X0Y_19668_21239.png DjangoCon_US_2016_-_Django_and_React__Perfect_Together_by_Jack_McCloy_zYHv6U86X0Y_21240_26615.png DjangoCon_US_2016_-_Django_and_React__Perfect_Together_by_Jack_McCloy_zYHv6U86X0Y_26616_27419.png DjangoCon_US_2016_-_Django_and_React__Perfect_Together_by_Jack_McCloy_zYHv6U86X0Y_27420_29231.png DjangoCon_US_2016_-_Django_and_React__Perfect_Together_by_Jack_McCloy_zYHv6U86X0Y_29232_29795.png DjangoCon_US_2016_-_Django_and_React__Perfect_Together_by_Jack_McCloy_zYHv6U86X0Y_29796_30575.png DjangoCon_US_2016_-_Django_and_React__Perfect_Together_by_Jack_McCloy_zYHv6U86X0Y_30576_36839.png DjangoCon_US_2016_-_Django_and_React__Perfect_Together_by_Jack_McCloy_zYHv6U86X0Y_36840_37175.png DjangoCon_US_2016_-_Django_and_React__Perfect_Together_by_Jack_McCloy_zYHv6U86X0Y_37176_37307.png DjangoCon_US_2016_-_Django_and_React__Perfect_Together_by_Jack_McCloy_zYHv6U86X0Y_37308_42335.png DjangoCon_US_2016_-_Django_and_React__Perfect_Together_by_Jack_McCloy_zYHv6U86X0Y_42336_42959.png DjangoCon_US_2016_-_Django_and_React__Perfect_Together_by_Jack_McCloy_zYHv6U86X0Y_42960_43799.png DjangoCon_US_2016_-_Django_and_React__Perfect_Together_by_Jack_McCloy_zYHv6U86X0Y_43800_44075.png DjangoCon_US_2016_-_Django_and_React__Perfect_Together_by_Jack_McCloy_zYHv6U86X0Y_44076_44195.png DjangoCon_US_2016_-_Django_and_React__Perfect_Together_by_Jack_McCloy_zYHv6U86X0Y_44196_44543.png DjangoCon_US_2016_-_Django_and_React__Perfect_Together_by_Jack_McCloy_zYHv6U86X0Y_44544_45311.png DjangoCon_US_2016_-_Django_and_React__Perfect_Together_by_Jack_McCloy_zYHv6U86X0Y_45312_45911.png DjangoCon_US_2016_-_Django_and_React__Perfect_Together_by_Jack_McCloy_zYHv6U86X0Y_45912_46379.png DjangoCon_US_2016_-_Django_and_React__Perfect_Together_by_Jack_McCloy_zYHv6U86X0Y_46380_46931.png DjangoCon_US_2016_-_Django_and_React__Perfect_Together_by_Jack_McCloy_zYHv6U86X0Y_46932_48323.png DjangoCon_US_2016_-_Django_and_React__Perfect_Together_by_Jack_McCloy_zYHv6U86X0Y_48324_48431.png DjangoCon_US_2016_-_Django_and_React__Perfect_Together_by_Jack_McCloy_zYHv6U86X0Y_48432_48503.png DjangoCon_US_2016_-_Django_and_React__Perfect_Together_by_Jack_McCloy_zYHv6U86X0Y_48504_51335.png DjangoCon_US_2016_-_Django_and_React__Perfect_Together_by_Jack_McCloy_zYHv6U86X0Y_51336_51407.png DjangoCon_US_2016_-_Django_and_React__Perfect_Together_by_Jack_McCloy_zYHv6U86X0Y_51408_51467.png DjangoCon_US_2016_-_Django_and_React__Perfect_Together_by_Jack_McCloy_zYHv6U86X0Y_51468_51551.png DjangoCon_US_2016_-_Django_and_React__Perfect_Together_by_Jack_McCloy_zYHv6U86X0Y_51552_51923.png DjangoCon_US_2016_-_Django_and_React__Perfect_Together_by_Jack_McCloy_zYHv6U86X0Y_51924_51971.png DjangoCon_US_2016_-_Django_and_React__Perfect_Together_by_Jack_McCloy_zYHv6U86X0Y_51972_52163.png DjangoCon_US_2016_-_Django_and_React__Perfect_Together_by_Jack_McCloy_zYHv6U86X0Y_52164_52739.png DjangoCon_US_2016_-_Django_and_React__Perfect_Together_by_Jack_McCloy_zYHv6U86X0Y_52740_52787.png DjangoCon_US_2016_-_Django_and_React__Perfect_Together_by_Jack_McCloy_zYHv6U86X0Y_52788_52931.png DjangoCon_US_2016_-_Django_and_React__Perfect_Together_by_Jack_McCloy_zYHv6U86X0Y_52932_52991.png DjangoCon_US_2016_-_Django_and_React__Perfect_Together_by_Jack_McCloy_zYHv6U86X0Y_52992_53483.png DjangoCon_US_2016_-_Django_and_React__Perfect_Together_by_Jack_McCloy_zYHv6U86X0Y_53484_57551.png DjangoCon_US_2016_-_Django_and_React__Perfect_Together_by_Jack_McCloy_zYHv6U86X0Y_57552_63227.png DjangoCon_US_2016_-_Django_and_React__Perfect_Together_by_Jack_McCloy_zYHv6U86X0Y_63228_64235.png DjangoCon_US_2016_-_Django_and_React__Perfect_Together_by_Jack_McCloy_zYHv6U86X0Y_64236_64643.png DjangoCon_US_2016_-_Django_and_React__Perfect_Together_by_Jack_McCloy_zYHv6U86X0Y_64644_64751.png DjangoCon_US_2016_-_Django_and_React__Perfect_Together_by_Jack_McCloy_zYHv6U86X0Y_64752_64907.png DjangoCon_US_2016_-_Django_and_React__Perfect_Together_by_Jack_McCloy_zYHv6U86X0Y_64908_64941.png
Come on, y'all! MUSIC Hi, everyone. Um, so my name is Jack, and I have to... There we go. Cool. I'm a software developer from New York City, and one of the reasons why I'm giving this talk is most of my recent projects, three out of my last four recent projects were Django projects that also used React. So I've dug deep into how the two can fit together, and I really like how they fit together. Hopefully, um, some... Has anyone here worked on any React projects? Okay, so a handful. So not a room full of beginners. That's exciting. If you are a beginner, I kind of geared this talk for people who know Django, but haven't really used React yet, or kind of just thinking about it and looking at it. So, um, I've been a Django user for over five years, a React user for about the last year or so, a little longer than that, and for what it's worth, I don't consider myself to be any kind of expert on either of those things, just someone who put in a lot of time working on Django projects and React projects, and might have a little bit to share. Um, I'm gonna try and talk fast. If I talk too fast, slow me down, but, um, it's kind of a broad scope to this talk, so I'm more worried about not having enough time than I am about, like, filling time. I'll try and save some time for Q&A at the end, but that's my contact info. You can hit me up on Twitter or GitHub if you have any questions that we didn't have time for today. And I'll also be around for the next couple days for the sprints. So, what are the goals of this talk? Uh, the title of the talk really could be a crash course in React for people who already know Django. Um, the first goal is to understand what React does, how React works, because a lot of people are talking about it, and people in the Django community, some people have kicked the tires on it, some people have used it heavily, but a lot of people haven't. So, it's kind of an intro to React for Django people. Um, and the goal is to build a mental map for React so that you know how to think about it. It's going to take longer than a 45-minute talk to build a good mental map for React, but hopefully this will be a good primer. Um, we're going to become familiar with some of the key parts of a React project and learn how to set up a React project inside of a Django environment. Um, one of the other big challenges of learning React is that a lot of React projects and most of the React boilerplate examples use JSX and a quote-unquote new JavaScript, ES6 or ES7. Um, so we'll be diving into a little bit of that just so you know what you're looking at. Um, it's one of the things that can add some intimidation to learning React. And then finally, we'll bring it all together by showing how Django and React can fit together in, uh, in a project. And we're actually going to start here a little bit at a high-level view, um, before digging into the, uh, React part. We'll look at the separation of concerns in a Django and React project that uses both. So Django follows the MVC pattern for building user interfaces. Uh, in the MVC pattern, uh, there are three parts, the model, the view, and the controller, and they're all interconnected. This is kind of how they're interconnected. The model updates the view. The view is what's seen by the user. The user can do stuff to manipulate the controller. Um, this is based on the user's interaction with the view. And then the controller, uh, updates the model. This is how Django works sort of. Um, there's a cool question on the Django fact page. Um, Django appears to be an MVC framework, but you call the controller the view and the view the template. How come you don't use the standard names? And the answer that Django gives is in our interpretation of MVC, the view describes the data that gets presented to the user. It's not necessarily how the data looks, but what data is being presented. Uh, it's sensible to separate content from presentation, and that's where Django templates come in. It's kind of a pedantic answer to, uh, that question, but that's also part of the reason why I like it. But what they're saying essentially is that in Django, the view part of the MVC is split into two things. The view that you keep in views.py that renders data to your templates that actually are the view that the user sees. So the map of an MVC from Django's perspective looks more like this, where the model corresponds to your models.py file, your views corresponds to your views.py, they render data to your templates, um, which is what the user sees. Uh, he or she interacts with the templates to manipulate the controller, which is kind of like the framework itself, and the controller updates the model. React fits here. React fits where the templates are. It replaces, uh, your Django templates, and based on how the user interacts with those templates, dispatches actions that then update Django, that update the controller. So this is what your MVC looks like in a React project. Um, the first thing about React, uh, to understand is that it's not a full MVC framework, and it doesn't try to be. Uh, if you use it in a Django project, it'll fit where your templates, um, used to fit. It won't replace anything else in a Django project. Um, and keep in mind, templates, like it's the broad view of templates. It's not just the templates files, but also the files and packages that your templates use. JQuery, potentially CSS, all of your JavaScript files, uh, that are imported into your templates. So, why would you want to do this? Django templates work perfectly well. Why would you want to start, uh, stop using them and start using something that is significantly more complicated? No, sorry about that. Uh, that you have to learn from scratch, and that's outside the Django ecosystem that you already know real well and love. Um, and the answer to that is maybe you don't. Maybe you don't want to use React, and it would be overengineering to use React. Uh, Django templates are perfectly fine for plenty of sites, um, and we all know that because we've used that for plenty of sites. They work. Um, but React lets you do certain things that would be really, really hard to do, if not impossible to do, um, using just Django templates. The first thing, um, that React templates let you do is it lets you turn your site into a single page app. Um, from the user's perspective, single page apps, when they're built the right way, they are faster, they feel more modern. Um, it's something that's really been popular in the JavaScript community for a couple of years now, and has been a little bit slower to become popular in the Django community. And the, uh, Ruby community, I know that channels are doing some work to be able to use templates to build single page apps, but this is a big reason why React is deserving of a look. Another thing that you get with React is the ability to reuse parts of your code base for iOS and Android in addition to just your web app. Um, I'm not going to dive too much into this, um, but it basically works like this. Your React, your React templates are made up of components. They're like building blocks that you assemble together to form your UI, and each one of those building blocks does two things. It performs some internal logic, and then based on that internal logic, it renders a chunk of what your users see. It renders a chunk of UI. With React Native, you get to keep the part of your templates that perform that logic and use them across platforms, and then render out different code, either HTML or, uh, iOS or Java, based on the platform that the user is using. And then finally, and this is probably the biggest reason why React is, quote, on as big as it has, is it makes it much easier to manage and manipulate complicated state. Um, in most small projects, there isn't complicated state. The state is simple. So there's not much to manage. You can keep it all in your head more or less. When you start working on a bigger project, um, managing state can become a real nightmare, and I'm sure it's something that you've, uh, potentially run into. That is the biggest selling point of React and the biggest thing that it makes much, much easier. So we're going to zoom in for a bit on the React part of this map, um, so that you can understand, uh, and get a feel for that. And then we're going to zoom back out and look at how Django and React work together as part of a full system. Oh, and one more thing. Since one, uh, since React is taking care of your UI, your views are going to feed it raw data. Uh, your view layer is really just an API layer. React doesn't care what the rest of your stack is, but using something like Django REST framework is, uh, it makes a heck of a lot of sense, um, because then your views are just an API layer by default. So the homepage for React highlights a couple of things that differentiate it from other UI frameworks. Um, if you understand these three things, you'll understand the fundamentals of React. The first one we already talked about, it's that React doesn't make assumptions about the rest of your technology stack. React is your UI layer. It provides a really good tool set, arguably the best tool set for, uh, building your UI, and it doesn't try to do anything else other than that. The second point on the homepage is that React is declarative, and this one is a little bit tougher to grok. Um, React makes it painless to create interactive UIs. You might put an asterisk after the word painless. Um, it's painless once you go through the significant pain of, like, learning how to use it, but once you understand that it is pretty painless, it's actually very painless. Um, and, yeah, it's quite easy to use once you get it. Um, you design simple views for each state in your application, and React will efficiently update and render the right components when your data changes. So basically this means that when you use React, your application state is kept separate from your DOM. You declare what your DOM should look like, given a certain, um, state that your application is in. Then when your application state changes, your DOM changes as a result of that, but React controls this change. You don't control this change. You only manage the state and what the state, and what the DOM is supposed to look like given a state. Uh, and then finally, declarative views make your code more predictable and easier to debug. It also makes your code a heck of a lot easier to test. So, how a declarative component compares with doing things the interpretive way with, uh, jQuery? Let's say you've got a very simple page. You've got a button and a div, and you'll have two views where state one is the button shows the word hide, and the div is there. State two, the button shows the word show, and the div is not there. This is how you'd code it out in jQuery. Um, I'm not including the actual HTML page where the DOM elements are declared, but you'd have a JavaScript file. You'd bind the click event to your button. That click event will call a function every time it's fired. That function's gonna check what state the div is in, uh, whether the div is visible or not, and then interpret from that state whether or not the, um, div should still be showing. It'll interpret your application state based on what it sees, and from that interpretation, it's either gonna show the div or hide the div. The state is interpreted from your DOM. I know this is really bad jQuery, by the way. Um, but, yeah, how you would do the same thing in React, it's gonna look very differently. React uses components. We already talked about that a bit, and, uh, this file represents a single React component. The, uh, easiest way to think about components is as a container for some part of your UI, and, uh, this code looks, uh, it uses ES6, so it might look a little bit different than the JavaScript that you used to seeing. We'll talk about that for just one second. ES6 is the 2015 JavaScript specification. It adds a whole bunch of stuff to JavaScript that never was there before. It adds classes. It adds modules, so you can import and export JavaScript, uh, from files just like you can with, uh, Python packages. It adds iterators and generators, promises. Uh, there's also an ES7, which was finalized, uh, last month, but isn't really widely supported yet. The point is, though, JavaScript's evolving, and as it does, it's becoming way more Pythonic. Uh, these are a handful of tweets that I found, just of people noticing the similarities between modern JavaScript and Python, my favorite, um, is, it turns out ES, it's up in the corner on the right, turns out ES6 is basically Python with the added bonus of irritating front-end devs. Uh, and this is me joking a year ago that by the time they get to ES9, JavaScript and Python are going to be syntactically identical. Um, so back to the React component that we're looking at, it represents a single section of your UI, and it does two things, um, inside. Uh, the first thing that it does is it manages the state of this UI section, and the second thing it does is it renders the component itself. It actually renders the DOM elements based on this state. The internal functions, I collapse them, uh, so that we can see the component as a whole at the top. Uh, we have the, um, we import React and component, uh, because this file is going to be a React component. We create our component as a class that extends the base React component. We can do that now. Um, inside our class, inside our React component, we have three functions. The constructor, a function called toggle showing, and the render function. And then we'll look at all three of those in a moment. But all the way at the bottom, uh, we have our export statement to export the component. So this is one thing that Python and JavaScript are a little bit different, um, on. In Python, every named object is exported automatically. In JavaScript, you have to explicitly export the things that you want to export, um, to be able to import them somewhere else. So let's go back and look at those three internal functions. The constructor looks like this. It sets the properties and the initial state of your component. Uh, we haven't talked about, uh, properties and we probably won't get a chance to talk about them, but they're essentially immutable parameters that, that come from other components. You cannot change them in the context of the component that you're looking at. In this case, there are no properties, but there is some state. There's a state made up of a single Boolean saying whether or not the div is showing. Toggle showing is a function that when called, toggles the is showing value, the state, from true to false or from false to true. Uh, we use this.setState to do that. It's how you manage internal state inside a react component. And then finally, the render function is exactly what you'd expect it to be. It's what, it's what gets rendered. In this case, one of two things can be rendered and it all depends on the value of this.state.isShowing. What's rendered is JSX. It's very similar to HTML, but you can use variables inside JSX the same way that you can use variables inside, um, Django templates. And, uh, yeah, I just want to talk for a second about the onClick property that we put on each one of those, um, buttons. It calls that toggle showing function that we defined that switches the internal state. And since the component states change, the component is then re-rendered based on the new state. If you've ever heard the expression data down actions up or one way data binding or one directional data binding, this is what people are talking about. When you hit the click button, that action, the onClick event travels up the component. It changes the component state and then that new state causes the render function to be recalled based on that new state and that data flows down. The actions go up and the data goes down. Back to the why. It might not seem like this pattern is any easier and it's definitely a more, um, complicated pattern for simple sites. Um, in this example, there's very little state where react shines is in examples where there is a lot of state to manage and when different components are affected by the same state. So that brings us to the components themselves. React, if you haven't picked up on this already, is component based. You build encapsulated components that each manage their own state and then you compose them to make complicated UIs. Since the component logic is written in JavaScript instead of templates, you can easily pass rich data through your app and keep state totally unrelated to your DOM. So we just built a single component. The way to build a complex React UI is to assemble these single components together like Legos. Your React app shouldn't be a monolith. It should be a collection of components that each ideally does a single thing or renders a single part of your UI. So let's look at an example where you have a single page app that has two views, a landing page and a pricing page. We want to build this as a single page app. So the top of our component, so the top component in our tree is going to be the same in both cases. I think I called it index. Having the same parent all the way at the top, that's what makes it a single page app. There's a plugin called React Router that I'm not going to have time to cover. It handles URL routing inside a React app, but I just wanted to let you know it exists. And then the index component is going to render one of two possible components based on the properties it gets from React Router. It's going to either render landing or pricing. Landing is a component that renders your landing page. Pricing is a component that renders your pricing page. Each of those pages might be made up by other components, might be made up by a whole tree of other components. But the render page of your index method is going to look something like this. Where our top component index is not rendering HTML, it's rendering other components based on the properties that it gets from the router. So render can render one of two things. It can actually render DOM or it can render other components that eventually further down the tree, render DOM. And when the path name from your router changes, what's rendered changes without a page reload. So your application is built like a giant tree where the current view is made up of all of the components being rendered all the way down to the base of the tree. And when your application state changes, all the components below it that are being rendered are going to internally check whether they need to change too. And if they do, they'll re-render. It sounds like that would be super inefficient. The way that it works is actually very efficient. I'm not going to get into that, but it's really fast and performant. There's way more to say about React, but I want to bring it back and show you how to integrate React with a Django project because that's what this talk is about. So lightning round. This is how you get started using Django and React together. The first thing is that you need Node for it. Node is what's going to manage all of your JavaScript packages, including React. So you want to install Node and NPM, which is the Node package manager, and then you want to initialize NPM inside your Django project. And this is going to create a file called package.json, and package.json is similar in terms of what it does to requirements.txt for PIP. You want to install the Node packages that you need, and the way to do this is NPM install package name and then have a little flag at the end to define whether you want that package installed globally, whether you want that package installed for dev dependencies for development only, or for development and production. So here is what selection from my package.json from one of my projects. Just a couple of things. These are all the dependencies for this project that's needed for prod and also for dev. A couple of things to focus in on. All of the stuff that starts with Babel. Babel is a shim, for lack of a better word, that takes your ES 2016 or 2015, your ES6 JavaScript, and reduces it down to JavaScript that older browsers can read. Radium is a package that you probably won't use in a typical React project. I like it a lot because I have the Vendetta against CSS, and one of the things that React lets you do is eliminate all CSS. Radium helps you do it by letting you do media queries within React without using CSS. Webpack stuff, all the stuff that starts with Webpack. Webpack is a module builder. It builds the bundle for your app that your Django template is going to read from and build the app from, both for prod and for dev. It's probably for you going to eliminate the need for tools like grunt and gulp. It also gives you hot reloading. Just like when you change a Python file, your server restarts. When you change a JavaScript file, your known server will be able to restart if you use Webpack. It's not the only way to do it. It's just kind of the preferred way to do it, I guess, or a preferred way to do it. Finally, something that I am probably not going to get a chance to talk about is Redux, which is something you should learn and make use of. It's a package. It's also a pattern for managing an updating application state that lets all of the state updates happen in the same place. So you can simplify state management even further and also put dev tools there so it's easier to see what's going on. So, yeah, the next step is learn Redux. It's 100% worth the time it takes to learn. There's a really good video course by the creator of Redux that I linked to here. I'll publish these slides afterwards, by the way, but you should definitely check that out if you care to learn React. Then the next step is you make a server.js file. This is the file that you use to run your known server in your dev environment. It's kind of like manage.py run server. You can do known.server.js to start your known server. It's, mine looks like this. And it basically just tells your webpack development server how to run, and it makes use of a configuration file where you store all your webpack configurations. Making that configuration file is the next step. The config file, I couldn't fit the whole thing on here. Let me see if I can actually, can you see that or no? Hang on. Can you see it now? No. All right. This is just to it. So I'm going to have to describe this without showing it, unfortunately. Now I've made it so that I can't see it. But in your webpack config, it gives you the ability to use different loaders, to use different modules, to use different inputs and outputs. The inputs, they're called entries, and the outputs, which is just called output, is the part that you're going to be most concerned about. What the output does is it tells webpack where to put that big old bundle that it creates, so that JavaScript knows where to, so that Django knows where to look for it. And then entry defines what the top component in your React component tree is. So if you want to slowly integrate React into an existing Django project, you might have multiple entries. A small React app inside Django to manage a small thing that can grow over time. But you can have multiple entry points, multiple React trees, I guess you would call them, and you would define them in your webpack config. I only have one, and I call it main. There we go. And I can see my notes again. But yeah, there's a gist to that in there. There's also your index.jsx file, which is your top most React file, which I included a gist to. And then two more components that index.jsx uses. AppRoot, which is where your apps roots are defined. And app.jsx, which is the uppermost component that has the potential to render DOM and not just render other components. It'll render other components too, but it can also render DOM, like a loading DOM. And then finally, here's how you hook the two of them together. You install Django webpack loader, which is a nice little package that lets you call your webpack bundle. So all of that React code and the other JavaScript packages that you're using lets you call that from inside a Django template. And you add webpack loader to your installed apps. And if you have multiple entry points, you'll want to do some additional configuration that's really well documented on webpack loader's GitHub. And then finally, the last step is inside a Django template, you load render bundle from webpack loader at the top of the page. And then inside the HTML of the page, we render the bundle that we're trying to render. We called it main in webpack config, so it just says render bundle main. And that's it. That is basically how to integrate it into a project. So I have more stuff that I can cover and I'm prepared to cover, but I figured now would be a decent time to stop for like two or three minutes of questions in case anyone wants to jump in because I know that it might be green territory. We use the same code base, it sounds amazing, but I would like to know what is the reality of that because I'm glad to say it's exactly the same, but I don't think you have your component, your logic, right, and then your render. Sure. You render different things, right, and you, in a web application, you have different components as well. So that, what is the reality of that? Yeah, I mean, I haven't worked too much with it, but I know several people that have the kind of, you're talking about with React Native, right? Yeah. So React, the, first of all, iOS React Native is more mature than Android React Native right now. So most of the problems that people are having seem to be coming from Android React Native. It's good for certain types of applications, applications that like render template views. It's bad for applications that are super animation heavy and have a lot of like interstitial animations is also what I've heard in terms of structuring that project. React lets you do it one of two different ways. Inside a component, you can render different code based on the, based on whether it is a web app or an iOS app or an Android app. Another thing that you can do is you can have different components to define what your app is. So you can have index component.jsx next to index component.ios.jsx and you will just import that as index component and React is smart enough to know that if you're building an iOS app, it wants to use the one that's iOS and if you're building, if it's a web app, it wants to use the one that's JSX. Does that answer it at all? Yes. Okay. Yeah, I mean, I think that the benefit is if you want your mobile app to do totally different things than your web app, you probably wouldn't. But if you want your mobile app, if it's really just a distribution game where you want your Android app and your iOS app to be very similar to one another, then being able to share the same code base, I think makes a heck of a lot of sense. So I have two quick questions. You mentioned Django Restraimer and React. Yeah. What's the workflow look like for login, for example, and sending back a CSRF token? Am I simply just grabbing that token on the JavaScript side from the cookie and impending it to a request? Yeah. Or what's the React way of doing that? Yeah, I'll show you some code afterwards or if you're around for the next couple of days. The way that I do it is I have Ajax calls inside my Redux workflow where I make a, from the perspective of a component, I just have a call that says get artists or something like that. And inside that get artists function that I'll define, it's going to check what artists I already have in my Redux store. Redux is kind of like the back end of your front end, and I'm getting deeper than I wanted to on this, but it'll check if I need to make a fetch. First of all, it'll check if I need to make an Ajax call. If I do, it'll make that Ajax call, get the response, and then load it into my browser's local store. Okay, cool. Yeah, I appreciate that that probably doesn't fully answer your question. No, that's a good sense. My next question is, React can get really complicated, as you know. You can have models and a lot of business logic on the front end. You can do the same thing on the back end. In your experience, how do you handle where that logic should land as far as Django models or models in React? Where do we draw that line? Sure, React doesn't have models, it has modules. So you're like importing modules from, it's not like Django models so much. Yes, your React data stores could be similar to modules, but those would be populated by your Django models. So what I would typically do is I would get the data from Django, put it into React, so I don't have to get it again if I need it again, and sort of use it the same way that you would kind of use like SQLite, if you were building an iOS app where you have like a local data store just for that user, just for that session. And then everything else just lives in Django, and you have a workflow where you check if you need it. If you do, you grab it from Django. If you already have it, then you don't. Thanks. Yeah, of course. Hey, it's a lovely talk. I've really been appreciating a lot of the conversation I've heard around Django and React together. My question for you is about style management and CSS. You don't like CSS, and then you're using Radium for a media queries. Sure. Are you using any other libraries? Khan Academy has one, I forget the name of it, to manage inline styles in virtual DOM elements? No. I'm not using those. Basically, my CSS is, so I've put a kind of rigid separation between components that render pages are only made up of other DOM components that don't manage any internal state. So I have a component for button, and I have a component for div and things like that. And I define what those should look like by passing props to them, and then all of the Radium calls are done internally. And I really actually only use Radium for the hover and focus media queries, things like that, for things like width. I do that declaratively by having a reducer that manages the window width so I can access that in declarative fashion. Does that answer your question? Yeah, it does a bit. How do you reuse any style share between components? Sure. You just have it inherit from a parent. Like, if you're using the same button everywhere, you really don't have to. You're importing the button into your component, so it's not like your button almost becomes a composite of the DOM element and also the style in the same way that it would be if you had a button that you put, like, I don't know, a button success on if you're using bootstrap. Right. Thank you. Yeah. My question is about a little bit of architecture or maybe deciding when you are where you should migrate your application to something like React. Like, for example, the the button example that you made is trivial in jQuery, right? Yep. But how do you know when, hey, I could really use something that manages my state instead of just adding classes to my stuff and checking with jQuery. But, you know, installing React is not like, oh, oh, one command thing. Right. You really have to commit to it. It's probably going to change your build and a bunch of stuff. Yeah. So when do you know, hey, we should really be using something more robust than just jQuery, you know? I mean, I would say if you're starting a new project and you already know React, it makes a lot of sense because it's no harder to do it that way if you're starting from scratch. If you have an existing project that isn't using React, I mean, you'll know when you're spending a lot of time debugging jQuery because managing state is an issue. So like how you do that exact calculus of whether or not the investment is worth it really has a lot to do with how much of a headache it is to fix problems that happen when you're state and you're DOM or like intermixed. So. Thanks for the talk. I have heard a lot of different opinions about combining like front end and back end, especially in our Django projects. And I'm wondering how you handle packaging up your project for deployment since a lot of people have opinions about separating front end and back end bundles and whatnot. Sure. I mean, a lot of people that I work with are really against having PIP be dependent on NPM. And I tend to agree with them, but I wanted to see what you thought about that. Yeah, I mean, I tend to agree with that as well. Like Python Django has to run on the server. It's back end. React can either be deployed on the server or on the client. It's front end. I like to keep them separate. Yeah. Does that answer your question? Thanks for the talk. This really demystifies React and makes it clear this is a state based view technology. Yep. So the previous questioner somewhat got into the issue that I wanted to know about, which is when you're in development, you mentioned running Node. Both as sort of compass like watcher and also as a server for development to serve up some resources Django is going to call for. In production and deployment, I gather that you don't do that. And I just wanted to verify that that's true. That's exactly right. Yeah. Okay. Thank you. So, cool. We have five minutes left. There's any more questions if not I'll jump into some stuff that I wanted to cover but didn't have time to. Awesome. So stuff I wish I had time to cover. This is also a really good like, I don't know, study guide for what to do next if you're going to start doing any React development. The first thing is the component lifecycle. So inside every React component, there are seven things that can potentially change the props or the state of that React component. It's only seven, but knowing what they are, knowing when they're called in terms of when a component gets instantiated, when a component gets released. They call it mounted and unmounted can be really helpful. I have a slide in this deck that you can look at that like does a brief description of what each one of them is. The next thing is flux and redux. So flux was the little history. React came out. Some people found that managing state in between components in React was sometimes challenging. Someone solved it with a pattern called flux that let state be stored in one place relative to a component. And then other components lower down the tree would access that state indirectly. They would access that state as properties, so they couldn't edit it directly. But then they could pass actions back to a flux store that would then cause it all to update. The problem with that is you would have a whole bunch of different flux stores at different levels of your app. Redux, which is kind of a flux-like architecture that everyone's moving towards, it is like flux, except it says all of your state transformations, all of your state transitions should happen in exactly the same place, in a redux store, a reducer. And what that lets you do is you have your application state all in exactly one place as a giant json tree, basically. And your application renders from that. And if you want to change anything in your application, if you have a button click or whatever, you don't do it internally in the component. You dispatch an action to your redux store. And what redux does is it preserves your last state, but also creates a new state for your app to transition into. What it lets you do is debug things a lot more easily because you have what your state was and what your state now is. So any time, you can hook up so that any time an error gets thrown for a user, that it sends their entire state history to a server so that you can debug more easily. It lets you see what your application state is all at one time, all in one place. It's super useful to learn. React Router and Redux Router, those are the two routers that people use for URL routing inside of a React app. They do essentially the same thing. React Router is simple and perfect for most apps. Redux Router adds some more functionality that React Router doesn't have. It's probably too complicated. It's probably over-engineering for most apps, but if you need it, it's great. And then, yeah, I will put some gists for authentication and access restriction using Django because that's something that I kind of scratched my head on for a while. I'll add that to the slide before I publish it. Basically, you wrap your components inside an authentication wrapper that checks whether or not a user is logged in prior to rendering the component. And then, yeah. Cool. I'll guess I'll end with this. Routing React isn't hard because it's hard. It's hard because it includes a heck of a lot of patterns that you're probably not already familiar with if you haven't used it before. There are a bunch of little things to learn that are each easy on their own, but altogether, it makes learning React feel overwhelming at the beginning, or at least it did for me. But once you know React, it can make state management inside a complicated app much, much easier. It plays really nice with Django because it doesn't try to do the stuff that Django already does well. It tries to do one thing, manage your templates, and it does a really, really good job at that. So like I said, feel free to reach out to me. I'm on Twitter, I'm on GitHub, and I'll be here for the next couple of days for the sprints. Thank you all so much for your time. Thank you.
also used React. So I've dug deep into how the time working on Django projects and React React does, how React works, because a lot of people are talking about it, and people in the with some of the key parts of a React project and challenges of learning React is that a lot of look at the separation of concerns in a Django the first thing about React, uh, to understand is work perfectly well. Why would you want to start, biggest selling point of React and the biggest thing that it makes much, much easier. So we're raw data. Uh, your view layer is really just an a declarative component compares with doing things the interpretive way with, uh, jQuery? application state based on what it sees, and from easiest way to think about components is as a used to seeing. We'll talk about that for just actions up or one way data binding or one React, if you haven't picked up on this already, how to integrate React with a Django project install Django webpack loader, which is a nice JavaScript packages that you're using lets you different ways. Inside a component, you can afterwards or if you're around for the next would say if you're starting a new project and talk. I have heard a lot of different opinions wondering how you handle packaging up your talk. This really demystifies React and makes it but knowing what they are, knowing when they're in between components in React was sometimes is like flux, except it says all of your state the two routers that people use for URL routing