 So thank you for coming today to my talk. Just very briefly about me, so I've worked with Django since 2007, I've been a Django core committer since 2011, and if you're ever interested in what I'm saying, you can always check out my Twitter account. I work on Neuron. We are a web agency based in San Francisco and have offices all around the world, and I encourage you to check out our website. If you'd like to see where we are too. So about this talk. So this talk is about Django and React, and while it does assume that you know a little bit about React, I'm still going to cover some of the basic principles of Flux and React, and then I'll show some examples of how Django and React can work together. So first, about Flux. So Flux is an architecture whose core principle is based on a unidirectional data flow. Now, that core principle is not particularly novel or groundbreaking. It's been used for a long time in many disciplines like video games, for example. And you may also argue that it's been used in the web in general with traditional websites if you consider the traditional HTTP request, server-side, template rendering, response cycle over and over. But it is a bit new in the world of rich client-side web application. So let's see how it all works. Typically, it starts with an action. An action is basically an event that is triggered by various things. It could be triggered by a user clicking on something on the user interface. It could be also a regular event that is triggered at a regular interval by a timer. It could also be data being pushed via web sockets from a server. So whenever an action is triggered, that action is caught by a dispatcher, which we then pass that action along to store. A store is just responsible for holding the state of your application. So when the store may modify the state and the internal data, and then pass that data over to the views. And then the view is responsible for rendering itself. It may also have sub-views. So in that case, we pass along that data down to its sub-views, and then the sub-views we render themselves, and so on. So what's very important in this architecture is that whenever something changes, needs to change in the state of your application, what you want to do is to trigger a new action. So for example, if a user will click somewhere on the interface, then you will trigger an action, a new action. And then that action would be caught by the dispatcher. And then you will enter this whole cycle again. You will then go through this entire cycle of re-rendering the entire interface. React itself is really just about this view system. It just focuses purely on rendering. Everything that sits outside, while there are several implementations available out there, I can cite for example, Redux, Reflex, Flamux, Flexor, and I don't know, Alt, multi-design, about a couple dozens extra. It's still pretty new. There are no clear winners at this point, so it really comes down to personal preference and to the nature of your application. Hopefully within the next few months, there will be one or two that emerge as de facto standards, but for now, I just encourage you to try it a few and see which one feels the best. So let's see now what some of the advantages of Flux are. So first of all, it streamlines the rendering process. As we just saw, anytime that anything happens, that might impact the state of your application, you enter the same entire rendering process, which means that you will approach the rendering of your page initially, the first time the same way as on the second time, the third time, et cetera. And because of that, it means that your cognitive load is drastically reduced because you don't really need to worry about how the different views impact each other as the state of your application changes. You can really focus on one particular view at a time. That then makes for a simpler code base because you don't have to deal with mutations for your views that eliminates a whole class of potential bugs that you basically never have to worry about. And that is very liberating. So all of that put together really makes for consistent predictable behaviors and that goes a long way in making you as a developer more confident about your application. Now let's see some advantages of React specifically. So React abstracts the DOM with components. It allows you to think of the architecture of your application really in terms of modules and submodules. And again, you can always focus on one piece at a time. It also handles all of the DOM mutations automatically. Mutating the DOM is something that can be quite complex sometimes, especially to do in an efficient way. Well, React will handle all that for you. And it is also agnostic about the rest of the stack. The only thing that React really cares about is that you feed it some data and then it will take care of all the rendering. It really doesn't matter in which context React is used. It could be used to render your entire application, but it can also be used to just render one little piece of an existing website, for example. And it also doesn't matter where the data came from, why the data changed, how it was changed, which means that you can use it with pretty much any backend. And obviously, in our case, we'll be using Django. So to illustrate some of those concepts, I'm going to walk you through a small demo app that I've built. It's very simple. It's just a list of photos. You may filter those photos based on whether it's black and white or color. And you can also then select some of those photos to mark them as your favorites. But first, let's see what are the pieces involved. So first, we have Django, which will be responsible for providing a REST API that allows you to access and manipulate the data server side. And then we'll have React that will be responsible for rendering the UI client side and to handle all the user interactions. Now let's see how those pieces fit together. So first, we have the client, so that in this case, it will be the browser. React will be rendering the page. And then whenever the user will click on the photos, a post request will be emitted to the server, to the API. And then Django will update the database. We then serialize the current state of the data and then pass it over to back to the client. And then React will be able to rerun the page to reflect the changes that have been made. And we'll try and follow this unidirectional flow of data. Now you may be wondering, okay, so how does React do to render the page initially? How does it have access to the data to hydrate the stores, meaning to load the stores with initial data? I'm going to cover a couple of different methods. One that you might think of as conventional is when the server will first return a pretty much empty HTML document and then we'll do another Ajax request just to fetch the data so we can then render the content of that page. Another method which you might think of as conventional is when the server, so in this case Django, will serialize the data and stick the data into the initial HTML document and pass it as a global JavaScript variable. And that is, for example, how Instagram does it. So now let's take a look at the working demo. Okay, so can you all see, make it a bit bigger, right? So here we have our application, we have all our photos to the left. You may filter the photos and whether they are black and white or color. You can also represent the same list in two different ways. You can represent it here as a list or as a grid of thumbnails. And whenever you click on a photo, you will see that first it will highlight the photo and it will also update the panel to the right which just lists all of the favorites that have been selected. So what's important to, what I wanna emphasize here is whenever I click on an event, oh, sorry, on a photo, whenever I click on any of those buttons, the entire page gets refreshed. You can't really see it because React is really fast at doing that but any event here triggers a full page refresh. And you can see also here that whenever I click photo, it sends a request to the server, so post request, delete request. All right, so now let's see how, what the code looks like. Going to start with the model. So it's really simple stuff here. Can you all see? Yeah, I'll make it a little bit bigger. So we only have two models here, a photo which will hold just all of the photos. Each photo has a URL, also has a Boolean flag that will indicate whether it's color or black and white. And then another model, the favorite model which will hold basically all of the pointers to the photos that have been favorited. Then the API, the API here was built with Django REST framework. If you're familiar with Django REST framework, it should all look pretty standard. The only thing that I'm doing here that is a little bit different is for the favorite endpoint when I add or remove a favorite. So for example, when I add a favorite, so that's the create method here, I will first do the actual action of adding the favorite to the database. But then I will also serialize all of the current favorites and send that back with the response. And this is just a small optimization here that I'm doing. And I'll just explain why I'm doing this. And you can see here that I'm doing the same for the desktop method, which is called when you delete or remove a favorite. Okay, so then let's take a look at the view. The view is extremely simple. It's this one at the top, Ajax hydration. All it does really is that it will run on this template and it's basically empty. There's nothing in there. We just have the links to our JavaScript and CSS. And here I've just added a header. And as you can see here, initially we basically have absolutely nothing. So we do need to do that second Ajax request to load the data. So that is done with this function here. So this function gets called as you first display the page, that empty page in the browser. So first we will render our react main view. So this render method here is going to get called. So the very first time that this is going to get called, the store won't be hydrated. It won't be any data at this point. So we will first display this progress bar. So this is what you can see here when I refresh the page. Okay. Then here I'm just waiting for a second is just to simulate a slow connection to the internet. But really what this does is that it would then call this method fetch data. Fetch data, really all it does is it just runs a couple Ajax calls to, so we call our API fetch that data and once we receive all of it, then we are ready to hydrate the store. So we basically load that data into our store. At that point, our view is automatically going to be re-rendered. So this render method is going to get called again. And at that point we're still displaying the progress bar. The progress bar is still displayed on the page. But at that point the store has been hydrated so we are going to render this instead, which is the album component that's a custom component that I've made. And React will be smart enough to know that it needs to remove the progress bar and instead dump our album component. By the way, you can see here that I'm using progress bar, that's just a pre-made component that I've taken from the React Bootstrap library, which is a React implementation of Bootstrap, but it kind of shows how you can build your application a bit like Lego pieces. So now let's drill down into our album component. Again, very simple. Here all that we do is to add two subcomponents. The photo panel, which is basically the grid of photos to the left and the February panel, which is the small panel to the right that displays all of the favorites that have been selected by the user. In each case we also pass down some data. So the photo panel needs to know about the photos so you can render the photos and also the favorites so he knows how to highlight the different photos that have been favorited. And whereas the February panel only needs to know about the favorites. So here you can see that we're passing down data to the subviews. Let's take a look at the photo panel that's probably the most complex. Again, this random method is going to get called automatically at this point. First thing that we do here is to just filter the data set that we have based on those, I'm not sure what's looking so big here because of the resolution. Yeah, okay, looks better like this. Okay, so it's going to look for whatever is selected here to filter down and to know exactly what photos we need to display. And that's just a custom method here, just a little bit of JavaScript that's going to go through the list and only return the photos that we actually want to display. All right, so now that we have the list of the photos to display, we then render some more components, some more subcomponents. Here, I'm going to call this function here, render photos, it's just a custom method that I have here in this class, in this components class. All I do here is to loop through all the photos. I do a little bit of computation and I try and find out, for example, if the current photo is fabricated, so I can figure out what color if I need to display any highlighting around it. So that's the style here. And then based on what we've selected between the thumbnails here or the list option, we are going to take two different paths. So in this case, if we have decided that we wanted to show as a thumbnail, then we're gonna render this particular photo as a thumbnail. That's another component that I've picked from the React Bootstrap library. And then we assign the URL, et cetera, and the given style. Or if at this point I have selected this piece, then this function is gonna get called and I'm going to render it as a list group item component. Again, you can see here that there's absolutely no code that says remove the thumbnail, add the list items instead of vice versa. All I have to say, I can code this component in a very declarative way. I can only focus on a given state and say this is how you should display given this state. Or you display this way given this state. All of the transitions here are basically handled by React because it's going to go through that method every time. And you can see here that I'm passing an action to both methods here. So whether I click on photo here or a list item here, the same action is going to be triggered. It's called toggle favorite. Now you can see what is going to catch that action and deal with it. So it's this method here. First, we try and figure out whether the current photo that's been clicked is a favorite. If it is, then we are going to remove it from our favorites. If it's not, then we are going to add it. So let's take a look for the bullet adding. And now here I'm going to do two things. And really this first thing is not particularly React specific. It's more of an optimization for the user experience. I do not want to wait for the round trip to the server to be able to display feedback to the user that photo has been favorited. So what I'm doing here is I'm holding a local data structure which is basically an array that holds all of the current favorites. And I will add that photo to that local data structure. And then I will call this method here, PropagateState, which is going to trigger full render of the entire page, which is going to cause the photo you just clicked to already be highlighted. And this is called an optimistic update, is when you trust that the backend is most likely going to work and you just don't want to let the user wait too long before they see anything change on the interface. And then this is when we actually change the actual data server side. So for that, we need to run a post request to our API and I will pass down the photo. Then what I do here, and again, this is, this piece is optional. If you remember earlier, I said that whenever I run an API call, I always return the current state of the data server side, because this is really the authoritative data. This is the data I really trust, one that is staying on the server. I returned that from the server so then I can replace my local data structure with the data that was provided from the server. And here I'm only doing this just to give myself some extra confidence that the UI reflects the actual state of the data server side. If everything went well, really, nothing is going to change, but React is going to be smart enough to figure that out. Because here I replace the data that came back from the server. I replace it with into the local store and then propagate the state. So that's going to trigger another full render. However, React is going to be smart enough to know that, okay, well, I had already made that chance previously. I had already highlighted that photo and I see that you're asking me to highlight that photo again so I'm not gonna do anything. So this is not, it's going to have very low impact on the performance. And this catch method here is if something ever went wrong on the server, then I'm going to fetch the data again from the server and then that is also going to retrigger a full render. And that's going to allow me to roll back. Previously I had optimistically updated interface, but if something went wrong on the server, that's going to basically revert that change. And I do the same thing when I want to remove a server here, a favorite here, I first optimistically remove that favorite from my local, my local storage, and then trigger full render and then same thing, I send the request to the server and same thing again, I replace the local data with the server, the data that came back from the server and re-render everything. So that was for the Ajax hydration that I mentioned earlier. There is another technique for the purely the initial rendering and that is this one. So this is exactly the same table. It looks and works exactly the same. The only thing that changes here is that we are going to be calling this view serialized hydration. So what we do here, we first serialize the data using the serializers from my API, the same ones. I then dump it, all of that stuff into a JSON object and I pass that over to my template. And here we just dump that JSON object into the HTML inside a global variable. So this is here where you can see if I show the source, you can see that's the object. So what's good about this, what's interesting about this is that it saves you from doing an extra Ajax call. So it means that along with the initial HTML document, you will already have the data, you'll be able to right away start rendering things. Now you wanna be cautious if you have a gigantic amount of data that might not be suitable because it's gonna make the initial call to the server slower. So you need to find out what method works best for you, either the Ajax hydration or that pre-serialized method. Okay, so that was for a brief demo. There's something else I wanted to talk about which is server-side rendering. So server-side rendering may be interesting in different cases. First of all, if you're concerned about SEO, obviously it would be much more easier for search engines to crawl your site and to index the content of your site if all of that good stuff or that content was pre-rounded as part of the HTML document. Doing server-side rendering also is also good for if your audience has a large amount of mobile devices. That it's also good because it will save some resource and CPU processing on your device because that will save them the effort of rendering the page initially inside the browser. And it's also good because since the page comes pre-rounded, you can already start consuming it. You don't have to wait a little time for it to render. And React make that actually pretty easy to do. The cool thing about it is that, again, I mentioned that React really doesn't care in which context it's being used. It means that you can actually use exact same code to render things on the server as you would and as I showed earlier in the browser. And that is called universal JavaScript. Universal just stands for the fact that it's the actual same code that you use. That is sometimes also referred as isomorphic JavaScript. And it's actually easy to implement if you use the right tools. I recommend using Python React. It's a small, nifty Python application that will allow you to do server-side rendering with any Python frameworks. And it does come with Django support. You will also need to use a very simple node HTTP server to do this. So let's see how all those pieces fit together. So first, in the client, so that's our browser, one of the user will first type in the URL to access your website. So there will be a get request sent to the server. Django will then fetch the data, serialize it as JSON, and send that over via HTTP to that separate node server. That node server, all that it does is just to render HTML. It will use the data that you provided and then use the React component, so those JavaScript React component, to render whatever component you want. And then it will return some HTML. Django will put all that together and send it over to the client. And past that point, any subsequent refresh that needs to happen will be done by React client-side, exactly the same way as I showed earlier. And the cool thing is that it will use exactly the same code, the same React components that I showed earlier. So let's take a look at a quick demo. So it is this function, this URL here. Again, exactly the same thing. Works and behaves the same. It's the exact same code, basically. Now let's see what happens server-side. So here, this is the view, the Django view that's going to get called. Here again, I first serialize the data using the same serializers from my API. I will then call this small function. That's a function that's provided by Python React. All that you need to pass to that function is the reference to the component that you want to render and then the data that you've just serialized. So in the background, that function is going to call that separate node server. It's going to send all that data to that server via HTTP. That node server is also very simple. It's basically just a dozen line of code. It will receive the data passed from Django via HTTP that contains both a specification of which component to render and then with which data. And then call that React render function, which is going to use a same component that I was showing earlier. And then it will result into some HTML, which we are going to return back to Django. So this is where we are now. Now we have all of our rendered HTML and we're ready to pass it down to our Django template. And here we basically just output that HTML into our template. And you can see here that we have all of the HTML that has been pre-rounded. And past that point, the exact same React component take it over from there and the same happens. It's exactly the same thing. Okay. There's another couple of topics I wanted to cover. First about asset pipelines. I personally recommend using something like Webpack, Gulp and Browser, or Gulp and Browserify for bundling all of your JavaScript code. Up until about a year ago, I was using pretty heavily Django pipelines and Django Compressor to do that sort of stuff. But the tooling in the JavaScript world has improved a lot in the past year. And now I think it's a bit more flexible to use those JavaScript tools to handle that stuff. And also front-end developers are already used to using those tools and they feel much more comfortable using those as opposed to more opaque tools like Django Pipelines or Django Compressor. I also recommend using Babel for the JSX transpiling. A JSX is that template-ish syntax that I was showing in the code samples earlier that React uses. And Babel, we just transform that into actual JavaScript that your browser can execute. And then finally, when the time comes to push code to production, then I recommend using Django Study Files app and also the manifest Study Files storage which will apply a unique hash to each of your assets which will guarantee that all the caches in your browser in the CDNs, et cetera, will be busted and your users will be using the very latest version of your assets. And finally, also wanting to talk a bit about testing. A good test treat should contain some unit tests and for that you could use some JavaScript frameworks like just minimal care, just Qunit. Also, I recommend doing some functional testing. For that, you can use something like Selenium and Django Dascom with some support for that, in particular with the Liferor test case. If you're interested in all that stuff, you should stick around because there's gonna be a talk right after this that's gonna cover some of those topics. But also wanting to cover one particular method which is sort of a hybrid between unit and the integration testing. That is actually using the same tools as I was describing earlier about server-side rendering. Even if you don't really care about server-side rendering, you could use the same tools to do some amount of testing. I'm gonna show you how that works. So here we have a very simple test case method. In the setup here, I just create a bunch of photos, photo one, two, and three, and I'm going to create some favorites. So just marking photo two and three as favorites. So then in the test method, I first serialize the favorites data, again using the same serializer from my API. We then call the same render component method from Python React. So what this is going to do is going to render our favorite panel component by passing the favorite data over to the node server that's running in the background, and then render that component. Again, here we're talking about this one to the right, and just that component in this case. So then you basically retrieve all of the HTML that's been rendered for that component, and then you can basically test the content of that HTML. You could test for example, which of the photos are present inside that HTML. So here I check that photo one, since it's not a favorite, I check that it's not in the HTML, and I check that photo two and three actually are. You may also use something like a tool called PyQuery. It's a pretty nifty Python library, which sort of mimics the API from jQuery, except in Python. That allows you to select pieces of your HTML. So in this case, I'm selecting the div that has the batch class. So it's this thing here. And I just check that its text is two, since we only have two favorites in this case. And you may also use a method that comes with the Django testing framework, assert HTML equal where you can compare two blocks of HTML. So here I'm inspecting the HTML from the H4 tag, and that's this whole thing here, so favorites and the badge. And I'm checking that it actually is exactly that HTML. Now I don't recommend using this for huge amounts of HTML, but if you're strategic about it, it can be pretty powerful, because essentially we're here using Python and Django to test JavaScript, because in the background, this is actual JavaScript that's been used to render that HTML. And that's about it for my talk. So thanks again for coming. I've published all the code. If you're interested in checking that out, and I also published my slide later, and I'm happy to try and answer some of your questions. Thank you. Great talk. Thank you. I'm curious if you've explored good ways to integrate this with Django Forms at all. Django Forms. Yeah. Forms, Formsets, or if this is geared more towards application style, or native style web page rendering. Right. So I assume you're talking about validating the data. I don't know. I have not. I don't see why you wouldn't, but I guess, so at the end of the day, if you're going to use React to render your forms, you do want to use React components. So you cannot use just the output that the Django Forms would give you. But there might be a way of turning that into instead of rendering raw HTML, you could configure your forms to instead render React components. You could take that route. Otherwise, you could still use the Forms validating process, but just hand over all of the rendering to React. I guess the reason I bring it up is I like the convenience of Django Forms, right? You can just set it all up and then render with Asp, or anything like that. But then I found it difficult to construct native style apps and so on and so forth. Native style apps. And so generally, I would gravitate more towards this method if that's what I were trying to do. So I was just curious about what your experience was with that. Yeah, so again, I have not used Django Forms with this, but I believe you would have to sort of reimplement the outputting of HTML from the Django Forms. So that would be a cool project actually. It'd be awesome if somebody wanted to take that on. And that's something I'll definitely look into, it's interesting. Thank you. Hey there, so I've been using React lately kind of similarly to how you presented it here. It's been really useful and it's been very fun, but the one thing that still makes me very uncomfortable is JSX, and it also makes the front end developers that I work with very uncomfortable because they're used to working in something like handlebars, for example. And so embedding, even having things like if you're specifying a class on a DOM component, it use class name, camel cased attribute instead. Is there any compelling reason to use JSX over trying to use one of the alternatives? Really, I think it comes down to personal preference. I personally actually really like it, and I know that the community is pretty divided about it. Some love it, some hate it. I just advise you just go with whatever works best for you. Just something you might be interested in looking into is React templates. It's a library that it's basically an interface in between, so you will be able to write templates that kind of look like Angular templates, but will output JavaScript. So it's basically a replacement for JSX. So you might want to look into that. It will definitely look a lot more familiar, and you'll be able to use regular HTML-ish or attributes and tags. Do you think there's any downside to doing that, or is it really just personal preference? No downside that I can think of. At the end of the day, it's basically just JavaScript. What I like about it is that it gives you a bit more power than you would have with templates typically because you have all the power of JavaScript constructs and data structures and processing that you can use to your advantage to do cool things for looping through lists and doing some kind of computation. So I personally like that, but I do understand that it's a bit off-putting for if you feel more comfortable with just HTML-like syntax. Thank you. Okay, so my question is, with a Django, you're showing here that it looks like Django effectively is being reduced to Django rest framework, purely serving the API portions of what's going on, and maybe some really, really light templating to put up the initial page that then React is doing all of the actual hard work here. Is this a question where Django's place in the world is just changing, or is there room for Django to interact better with these parts, or is there some intersection conglomerate of the two that we can use, preferably one that means I don't have to write JavaScript for a living? No, I don't think so at all. So what I think is great with React is that it's great for doing really complex, dynamic sites that when you have lots of things that change all over the place, but that's not all websites. Not all websites, I like that. And so some websites are a bit more static and Django is perfect for those. So the traditional Django, not just the API side of Django, but you can then still use React to focus on the small bits of your site that may be a little bit more dynamic. So I just see React as a complement to you as a Django developer, totally not as a replacement for Django at all. It has to be used, React really shines when you have things that change that are dynamic, but that doesn't mean that all websites need that. Or if they do, it sometimes is just a small portion of the site. And in both cases, you can use React. Thank you, Julian. Yeah, thank you.