 Thank you so much for your patience. I've had a very busy day today. I was just at another bar. So my name is Preston So, welcome. I hope it's not a game. I'm Preston So, and it's my pleasure to be here at Drupal Commonwealth with all of you. And how's the process so far? Great. Great. As long as it's going well, I'm very excited to be here because I think it's just very, very cool. It's just a very, very cool space, and a very cool city, a very cool country. And I told many people actually on this trip so far, I was wondering if they'd move by, or would they? Even if they were, maybe I'd know. So thank you so much for being such a wonderful, wonderful host. So here's a little bit of information about me. I am an Octwin, and I've been working with you since 2007. And I'm also a great bunch of people. So here's what I'm going to talk about. The first thing is, I want to delve a little bit into what is decoupled Drupal. How many people have heard of decoupled? How many people have heard of what React is? How many people have heard of React? Okay, great. So we've got a lot of people who have been exposed to both. And then I want to dig into sort of a little bit more about React's architecture, and how you build components with React, and then talk a little bit about React and decoupled Drupal. And then also talk about how Drupal might fit into a larger Drupal ecosystem, as well as some sort of common areas of sort of work that could happen within Drupal. So I was just finishing up these slides now. Code highlighting might be a bit of an issue. There might be some problem with the slides. I apologize, but at the end of the conference, I will have a much better set of slides before we give them up. I just finished this the last two minutes. And I'm going to talk about React from a bit more of a surface level. I know that a lot of people have probably heard of Flux as well, which is an architectural approach to building React applications. I'm not going to dig into Flux because it's a bit out of this particular talk, but I do think that it's worth exploration and possibly in the next talk I give about this I will delve into that a little bit. So first of all, what is decoupled Drupal exactly? So as a bit of history, Drupal is a content-added system that many people consider to be quite monolithic It's a traditional CMS in the sense that the CMS provides a soup-to-nuts feature set. This means that anything that you need to do as a site-filler or a themeer or a developer is all wrapped up somehow in Drupal. And Drupal serves a framework which gives you the tools to do a whole lot of things. This includes things like server-side templating. All of the market I've been actually through a bunch of documentation is served to the client as a server-side render basically. So there's a big shift happening in the web these days which is that originally if you started working with web design way back in the early 90s or mid-90s honestly chances are you were probably working with flat-fronted assets, HTML, JavaScript, CSS. You would upload them via FTP. You would go your browser type of URL and that was it. For a lot of people this was very easy and the job position of web master was very popular back in those days. With Web 2.0 what really changed is that we had an introduction of a mediator or a CMS which would provide a templated engine through which data would travel and then this templated engine would produce a rendered markup, a form of rendered markup and a server-side would actually provide all the data. You wouldn't actually have anything happening on the client side. This is back in the days when JavaScript was not the most important language and the browser actually was one of the approaches to a lot of the methods you find in the JavaScript API. So as a result it came to a pretty real and what was introduced during this time period was a topic called AJAX originally known as asynchronous JavaScript and XML. Basically you would use XML HTTP request to make calls to your, asynchronous calls to your server and retrieve data that you could then use to replace a single domino or so on and so forth. Now in this Web 3.0 world where we're talking a lot more about multi-channel publishing we're talking a lot more about native mobile applications, single-page applications built with JavaScript and of course nowadays Internet of Things applications. Nowadays we're using a RESTful API as the mediator between the server and the client. What this means is that you make RESTful calls to your REST API using HTTP methods and oftentimes actually all the time this would be done asynchronously. So you would have a REST call getting sent out from your client-side application and the server would respond with a payload that could be JSON or XML or what have you which you would then parse into and manipulate it off to actually provide that new data to your client-side. So what is decoupled Drupal as a concept? Well, a lot of people call it headless Drupal and there's a bit of a controversy about that because in Wikipedia it defines headless software as software that does not require a GUI and a great example of this is like Drush or the Drupal console. So I prefer to term decoupled Drupal because it's much clearer that there's not just one single head that you're decoupling it could be a variety of different ones against a single backend. So this is a very important thing if you would mind is that terminology of course one of the two big problems in computer science is naming things, right? And then cash melody. Naming things we have to be very careful with our names to make sure that people are hitting the user. So simply put decoupled Drupal is the use of a RESTful API as a Drupal data provider. Now there's sort of two emerging types of architectures that are coming out in the wild that use this kind of architecture that uses this approach. And the first is what Drees calls fully decoupled Drupal which is Drupal serves solely as a JSON API, it serves JSON payloads so you have applications like your JavaScript applications or mobile applications and oftentimes you'll have a client-side framework, an empty star framework, a model view star framework, takeover, or sorry, a handle on the rendering. So this is often done isomorphically in which you have a Node.js server which does a server-side render which executes your framework on a server-side to give that initial render and then that gets served in the project in order to provide a very quick time to first interaction, no blank screen, and things like SEO. So that happens in a fully decoupled site. Now recently Drees published a very important blog post called The Future of Decoupled Drupal which I highly encourage all of you to read about the fact that fully decoupled Drupal has a lot of problems. There are some cases of this in the wild, namely weather.com which uses Drupal to render pages but then Angular actually takes over further client-side rendering. So in progressive decoupling, Drupal controls some of the render to provide the initial page structure or marker or important render information that you might need as a JavaScript developer and then JavaScript then takes over the further rendering that is required in the client-side. So what are some problems in decoupled Drupal? Well, one of the things to keep in mind is that when you fully decouple, namely when you use Drupal solely as a flexible data provider, you have a lot of issues. Hello? Hello? Hello? Oh my gosh. Alright, cool. Can everybody give me that? Okay, take that. So much of Drupal's robustness is lost. There are many things like cross-aversion requests, security. A lot of these frameworks have not really necessarily solved some core issues of security. There's a lot of discussion happening in the Node.js community about these issues. Authentication and passwords obviously are two very important topics for us as Drupal developers. Things like form validation. Drupal solves that for us. If you use Drupal model, all of that sort of stuff is solved using our form API. You don't really need to worry too much about form validation. And then for users of Drupal, namely site builders, content operators, content editors, things like content workflow management, right? So how do you use something like Workbench with a client-side application? How do you really work with these things that people are very used to and allow that to sort of filter into the client-side application? Things like layout and display management. Things like display suite, panels. Those things are sort of not really useful. Sometimes if you have a front-end application, you have the need to actually change the layout. You're going to have to get a Josh and Gopro involved to call up your genius on the client and say, hey, I really need you to change this morning, but I have no idea how this works. Also multi-lingual localizations. So Drupal, how many of you were at the multi-lingual session yesterday, like that one? Really awesome stuff. The thing is that each client-side framework tends to have its own approach to multi-lingual. Daniel Angular has a totally different approach to multi-lingual. And so the big problem is how do we actually bridge that gap, right? Because Drupal also has some client-side way of doing multi-lingual. Thank you. All right. So the last thing is... The last thing is accessibility and experience. So I like to call this sort of the beginning of the sort of new Wild West markup. In the early 2000s, we had the giant web standards movement by people like Jeffrey Zeltman who said, we need to really fix markup. And if you've ever heard Wharton DK's talks about the Angry Beamer and how markup is this huge issue that Drupal has, one of the things that is very important is we need to keep our markup as robust, as possible, valid, semantic markup. And the problem is that when you're using client-side... If you're developing a client-side application with a client-side framework, then you are pretty much on your own when it comes to figuring out things like accessibility, UX. I'm really worried about the future of those sorts of things. So now that we've talked about what these things are, how do you actually work with these things, right? So in Drupal 7, the Drupal 7 has no opinion-rest layer out of the box. Namely, when you install Drupal 7, there's no way to actually use it as a rest API. So there's the services module, which is a very, very popular solution for Drupal 7. I highly encourage you to check it out. It has built-in rest and XMLRPC interfaces. It exposes continuities at endpoints that you can sort of delineate. And then there's also the services in any module, which extends it to include all waiting types. There's also restWS and restful. RestWS is able to expose... You can use the same path based on headers, and basically the headers will help you differentiate what's returned, what the response is. Restful will expose endies, and you can actually begin to cater some of that data to the specific needs of your client. Now, what about Drupal 8? There's an empty bullet there. So one of the things that was very important in Drupal 8 was whiskey, and it's not... I'm not talking about alcohol. I'm talking about the web services and complex score initiative, which was led by Larry Garfield, a.k.a. Kral, which incorporated web services as a concept in Drupal 8.4. So the core rest modules that are in place in Drupal 8.0 allow for all continuities to be exposed, namely users, taxonomies, comments, what happened. And also if you go into views, there's actually a new slate type called restScore that you can use to basically get a really nice view of your actual query. Now, there are many issues with rest and core. I don't know how many of you may have seen Whitney's blog post recently about rest and actually the last blog I was just in was talking about the rest experience, which is how does it feel using our REST API core and what are some ways that we can fix that. So I highly encourage you to look at our REST experience tax issues in Drupal.org and begin to think about it because ultimately those sorts of things will impact hugely the market that Drupal has. There's also one other module that I want to mention, which is Relax. So Relax is a contributed module which extends the core rest API to include revisions, file attachments, and also one of the big issues of the core rest APIs is that there's no way to distinguish between, you know, basically it's very hard to provide unique identifiers that can be shared across environments. So if you deploy content and you need to reserve that commonality, it's very hard to do that without Relax. And Relax is also very important from the standpoint of content staging and offline first applications and explicitly uses the CouchDB API stacker. So how do you go about setting up RESTful Drupal? Well, the way that I would recommend going about doing it is to download OpWheat.desktop if you go to opweat.com.slashdownloads. This is basically a stack that you can use to basically develop Drupal locally. It's the most famous thing that's been on the Drupal site. You can just download the D8 distribution and get running. So just make sure that it's working locally. You want to check that here that's all set up. And then also Drush is the fastest way to sort of quickly download and install any dependencies that you might have. So now that you have a working Drupal site, Core actually does not enable these modules by default. So you want to go in and enable how basic auth, serialization, and REST. And now if you want to configure the Core REST, you can either download the RESTi by module, which is actually a very useful tool if you're more of a visual person, or you can also edit the animal vial to configure what's available. Let me actually just show that to you, believe me. So over here, let's see... So this is a site that I've already set up, which has quite a few things. Oh, sorry, this is cut off a little bit. But... Okay. So if we go down here, RESTUI, this gives you a very nice view of how it actually... of all of your methods over here. And basically allows you to go in, you can edit, and basically set permissions for all of these. I generally, for just development purposes, check all of these. Obviously, you don't want to do that all the time for security purposes. But that should give you an idea. And if you go to the... Actually, if you go back to the extent page, you can see that we have our REST modules down here, the web services modules here. So there we go. And then the next thing I would recommend doing, if you want to get started really quickly, is to just do Develop Generate, which allows you to just generate some content really quickly so you can have a sandbox to begin working. So just Enable Develop, and then Gen C, which is Generate some content, a little piece of color text, and you can create 20 nodes or however many you need to get started. Oh, okay. That was... Ah, interesting. Okay. So then I would also highly recommend using a tool called Postman, which is a very easy to use testing tool, REST Client to quickly test the REST API. Make sure that is provisioned correctly. You can get it as a Chrome extension or a desktop application. So, for example, this right here is fetching a single node of NID1. And I'll actually show you very quickly what that works like. So here's Postman. And as you can see, I've got my site set up here. And actually, so normally we want to have some kind of authentication header. I'll show you briefly what that looks like later. But for now, because I've set permissions so that any anonymous user can just go in and perform get requests across our nodes, if I go ahead and perform this request, you can see that I get a JSON payload back, which has all of the sort of basic information that I need. Great. Any questions so far? Okay. Now, the next thing is... Okay, where is... Here we go. The next thing that we might want to do is to perform a post. And this will actually allow us to create a new node. So let me actually go back to here and I'll show you very briefly what my current content looks like. If I go to the content view, you'll see that I've got some nodes here and there's not really... This is stuff you've all seen before. Now, if I go to Postman and I go to this, you know, pre-created request that I have, and as you can see, I'm using basic auth as a way to authenticate this interval. I'll update the request. And then if I look at the headers, you'll see that now I've got my token here. And if I send a request... Oh, I'm sorry, I need to put in some information here. So let me just go back here. This is really not the most fun I have. But if I go in and I create, and I go do this, paste that in there. Here's the type that I'm going to do. Let me make the title of Drupal Con and I'm going to go back. So now if I go over to... and I send this request, I get 201 created status code. And if I go back, what you'll notice is... I now have a new node, Drupal Con and I'm going to go back which says, now let's start this one. Great. So now we know if you can do things with just basically doing crud on those Drupal. If you want to read more about this, there's a whole lot of information on Drupal.org about this. And I'm going to sort of stop the demo here and move on. So if you want to update a node, for example, through the rest of the API, you can do that very easily. So that's a very quick introduction to the basics of how to set up the Drupal. And I think that, you know, what's very important at this point is that I'm just using the CoreRest API as it exists right now on all consumabilities. Normally, you know, a lot of times your API needs to be a lot more extensive than what CoreRest provides. And it's a very good idea philosophically to design your API spec before you actually begin running your client-side application because you don't really know who's going to use the API. You want to make sure that that's as robust as possible before. So with that in mind, that's why I wanted to introduce the couple of Drupal and sort of the way you set up RESTfulDrupal before digging into React. So with that in mind, now let me go ahead and dig a little bit into React. And once again, this is, you know, it's going to move pretty quick. But I think that overall, I want to give you a big picture of what's going on. And at some point, very soon, I'll have a GitHub repo which you can access, which has all of this stuff already built in. So what is React? Well, I think it might help to start by talking about the sort of history of React. React was started in 2013. If you think about the progression of various client-side frameworks and how they evolved, React is sort of the big... It's really quickly growing in popularity because of its, you know, declarative approach to state, its co-location of templates with ViewLogic, and it's really sort of un-opinionatedness. Ooh, hard work. Un-opinionatedness about the stack. What that means is that React doesn't really care a whole lot about what you're using in terms of your model control or if you're using the flux architecture, what you're doing before you dispatch your... So in the last few years, a bunch of laundry ecosystems growing around React and I'll talk a bit about that towards the end. So Facebook literally calls React a library for building composable user interfaces with reusable components. So these components can be nested, they can have arbitrary hierarchies, and many people choose to think of React as the V in NBC. NBC being the model of the control of the paradigm. And, you know, a lot of people argue that that's not the best description, but I think it's very useful from the standpoint of just getting a feedback with your model. So because React is a library that a lot of starter kits that you can use, if you just Google React Starter Kit, there's like a million results that come up, there's not really a canonically sort of standardized set of libraries to use. You sort of have to pick and choose and investigate based on your preferences and your sort of needs. In this presentation, I'm really only going to talk about React because if I talk about Starter Kit sort of like delve into a whole lot more, it's going to get really messy. So what are some differences of React from other frameworks? Oftentimes people will say it's not really useful to compare. React to NDC frameworks or these larger scale frameworks. But I actually think that the place where there's a lot of overlap in terms of how we can compare them is manipulation of the DOM. So traditionally, you know, up until about, let's say about two years, about a year ago, with these sort of traditional NDC frameworks that we know very well, like Backwood and Angular, you know, they use the deferred approach and two-way data binding. But they also need to apply changes directly on the DOM. And so if you've ever used Angular 1, how many people have ever seen like dollar scope in Angular 1 and messed around with that and then poured your hair out, right? This is like one of the big problems with Angular 1 is that actually, if you look at Angular, it was originally designed to be a prototype framework. And so when you need to manipulate a whole lot of DOM nodes, it really is a big route on performance. React uses what's called a virtual DOM, which I refer to as an abstract DOM, because there's a whole lot of other solutions out there for the same kind of things, mainly for Metal DOM, which is a dual project. And it's an abstract DOM which allows different states in your UI to be diffed against each other. And so what happens is, using this diff, React basically takes that diff and figures out the most efficient way to manipulate DOM to basically keep your performance really high. I'm not going to dig into virtual DOM. There's a whole lot of resources if you want to learn more about it. Now, what are some drawbacks of React? Well, this wouldn't be a fair presentation unless I talk a little bit about the disadvantages and why you might want to reconsider using React if I've been convincing you already. React is not a one-dots release yet of React, which means that it's still very unstable. There's a lot of changes that are happening. It's not the most easy thing to follow in terms of upgrade paths. And so there's quite a few backwards-compatibly-making changes in React. React builds are challenging also because there's not full coverage of the stack, right? What that means is that, as opposed to, let's say, Angular or Ember in particular, you really need to figure out your own way to do certain things with React. So Flux architecture is a lot of people have been talking about those. And there's also the Redux framework, which is basically a very popular approach to Flux architectures that I have in case you check out as well. Also, one thing to note is that React has a bit less focus on web components support. Angular 2 will be able to iterate, I believe, with Polymer. And Ember actually has an explicit roadmap for once web components become the W3C recommendation. There will be support for web components in Ember. Okay, so I'm going to talk a little bit about how to set up React. And I'm going to move through this pretty quickly, but I do want to note that, once again, I want to talk about this from a very high level. I've taken a lot of these examples from a very influential 24 ways article called Universal React by Jack Franklin, which is actually a very, very good resource in terms of learning about isomorphic approaches to JavaScript. Namely, JavaScript across the stack. So if you want to start from scratch, basically what you want to do is just pull it into the project. And basically, you use the install argument to provide certain libraries that you need to use. So for example, the save flag will save it into your package.json file as a dependency that you need for production or for builds. Not for development, right? So things like developer tools, like Gulp or Grunt, those are not considered dependencies with the save flag. For development dependencies, you want to use save them. So the next thing is that I'm going to be talking a little bit about ES6 or ES2015, ECMH for 2015 here, because I think it's very useful to sort of introduce some of these concepts of ES6 in this context as well. In order to do that, we need Babel. And Babel has gotten a lot of flack lately because it has some problems sometimes. So in your Babel, not Babel RC configuration file, you want to make sure that you have your ES2015 setting and your React setting so that JSX, which is the template language that React uses, and also ES6 can be transpiled to JavaScript if you run in the browser. We're also going to use an express server to actually get this going. And the reason why is because we want to provide some server-side rendering. Namely, we want to provide that initial state and not have a blank page when you start looking at your application. And then we'll also want to use React Router, which is a very popular solution for routing. So at the end of all of this, your package.json file should look something like this where you can set up your dependencies and depth dependencies. Now, in terms of setting up Express, you want to set up a server.js file which will basically house Express. And what's happening here is if you notice these import statements are basically calling other modules elsewhere to actually inject those dependencies. So what's happening here is if you notice actually down in right here, this is what's called an arrow function. And if you're familiar with anonymous functions in Drupal, or address functions in JavaScript, sorry, it's been a long time, anonymous functions in JavaScript, then arrow functions are basically, you know, imagine it's just function and then React address as your arguments that you're using for that function. What this is doing basically is it's saying let's set up an express server. Let's execute it. Let's basically create, let's use our ejs as our e-legend, and I'll show you briefly how that looks in terms of setting that up. And then on every single get request, basically the wild card asterisk says any wrap, right? We want to render index, okay? And then we have our, at the very end we have our server and basically we can, you know, get the console log out and stuff like that. That worked good, right? So the, okay, this got a little messed up. Okay, so this is, in order for Express to recognize our HTML though, we need to actually save it as u slash index dot ejs. This is just an ejs paradigm. And what this should be, I'm sorry this is messed up, but it should be an HTML file. You know, just type HTML, HTML, head title, and then of course your body. And if you've gotten this far, you should be able to set this up and you will see your express server actually serving this HTML. So the next thing is that we can start to server locally by executing server.js with battle node. And then, you know, if you have it installed globally, if you're using the gflat, then you can actually just use battle node. Okay, I am very sorry that these examples are so messed up. Basically, what's happening here is we're going to put in this thing right here, this markup variable, which will allow us to basically replace markup with other markup, right? So what's going on here is that we're applying a shell for our application to line. We have our head and title, which is where this Hello World title is. And then we have our body, and within the body we have div-ig-app, and then the markup, which will eventually be replaced. So anything that's inside this app div is going to be our application. So the next thing that we want to do is to do some routing. And this is very important from the concept that we want to have multiple paths in our application. We don't just want to have a phone page and that's it. So, you know, the way this works is that we're going to export an object that contains our routes and set up, you know, basically a hierarchy of routes. Basically, the slash route and the slash nodes route are pointing to the index component and those components, respectfully, in this example. And then trial routes of the overarching path, right? Of the overarching route. Then in our server.js file, underneath those import statements, we want an import react to provide server-side rendering, server-side execution of react. And then we want to include some of those dependencies. And finally, we want to include our routes, which we exported, if you remember, from routes.js. Now, here's our first component. So react operates with components, right? Now, if you're familiar with react, you might have seen this before, except for the first component. So we're going to have to import some of those components and then we're going to import some of those components. So we're going to import some of those components that you might have seen this before, except that you might have seen something like react.ca class. We're using object-oriented JavaScript here. Of course, object-oriented JavaScript is a bit of a misnomer because it's just prototypical inheritance and also object-orientation in JavaScript now. That's a debate for a whole other session. But right here, what's going on is we're giving a we're setting up a react component called app component, which is our overarching component and upon render, we're going to give and this right here, if you're seeing this HTML within the return statement, this is actually called JSX, which is the type of engine that react uses. So what react will do is it'll actually interpret all of this, put it into a series of JavaScript objects and then that will be what is actually executing in the browser or on your server. So, this.propstop.shorten refers to the child components which are accessible from this component. So basically, any other component that we're building is going to live inside this app component. So the first other component that we're going to build then is index component. Now, once again, if I go back, you can see that this.propstop.shorten is going to be where that index component resides eventually. So you can see how the nestable reusable components concept kind of works now. And in this case, we're just going to return a very easy string which is welcome to the home page. And then we also have another component which also lies inside the app component, which is going to be our nodes component. And I'm calling it nodes component because eventually we're going to fetch a node or fetch some nodes and sort it out to you to provide some sort of information to be added. So we want to make sure that when we do server-side rendering that our server, when we set it up, express actually executes. We want to recognize all of these components as well because eventually we want these components to be executed and visible on the client side immediately, as if it was a quick page load. And we don't want things to be rendering on a page loading. So what we're doing here is after our routes we're going to include our components and make sure that those are present as well. Now, further down this is a server-side rendering that is also taken from that 24 Ways article by Jack Franklin. What's going on here is that we're providing basically various handbooks. If you have a response code of 500 or if you have a re-elect or if you have props, which means that you actually have available components to render then you'll invoke Render to String and this should actually be routing context with routing in the context capitalist. But then basically what will happen is this will render all of the routes on the server-side. Does that make sense? This will render all the routes on the server-side so we have all of our components also rendered on the server-side. And then we're going to send that if you recall the original app.get function that we had this function that we had was just rendering to the index view but if you look here we're providing this additional argument which is market. And if you think way back to index.js with the 100% that is where that market all goes. And then of course if there's nothing at all then you want to have a 404. And chances are you might want to have a unique view for 404 that you write yourself. So the other thing that's really compelling about React Router is the concept of linking so you can actually we can provide a navigation bar with our application navigate between these routes. And once again these should be capitalized as I will fix these slides and put up a much better version of them after this session. And so what's happening here is that if you think about what app component will look like. Imagine that you have a massive app component and then you have your navigation bar which is a part of the app component. And then further down you're going to have your other components namely it could be index component based on the index route or it could be nodes component based on the nodes route. Then the next thing we want to do and once again this HTML is really messed up the next thing we want to do is to provide some client side rendering. Because not only do we want server side rendering in the sense of having our initial state already rendered on server, we also want to allow further re-rendering to take place on the client side. So we want to allow these components to sort of dynamically change based on new data that comes in and so on so forth. So what we need to do is we need to make this happen on client side as well. So you want to create a client.js or client, you can name this whatever you want because eventually we're going to actually put this in pipe this into a red tab. So you want to import react and react arm the router for client side routing and also our routes as well. So we're going to have basically isomorphic routes on both the server and the client. And then also you want to use create browser history which is part of the HTML5 history again which will allow things like back button functionality and things like that. And also our routing also provides a means of doing things like look on the loader. And then you want to render this. And you want to do this and you want to apply this to the app ID which you saw earlier. Now what's most important is to build our bundle to productionify our JavaScript so that we only serve a single JavaScript file because we want to aggregate and minify all our JavaScript. So let's use Webpack for that. Webpack is currently one of the more popular solutions. You can also use browser file if you so choose. And this is the config file on how it looks for Webpack. What we're doing is we're going to provide a client.js file as the input which will basically make Webpack take all of those import statements and basically put in all of the dependencies that we need. So what will happen is at the end of this we'll generate a .js file which will be used by the browser to actually execute all this JavaScript on the client side as well. So now this is a very key point. Now what we've got is we've got our server side stuff all rendering, all working rate and that is going to serve an initial state of our React application to the client side which is just flat market. That's very important to keep in mind. It's just flat market. Then what's happening is we're going to execute this bundle.js on the client side and this will basically take over from there and confuse the markup with your activity that we all know about. There's a very big concept in client side framework technologies called rehydration. You'll probably hear this more in the Enver or Angular context in which after you provided that initial server side provided markup rehydration involves let's fetch some of the new updated data and then update that initial state of the application if that has updated data with this new data. So you've always gotten a new state of your application regardless of what's happening. And then we want to execute Webpack and that will be a trauma for this. Okay. So now with that in mind how do we set up React to work with the couple of people? Because that's really what you all came to this session to hear about. So the first thing that you want to do is that you want to allow your React application to have access to Drupal back in. Drupal, if your React application is posted on a different domain, which is what it means most likely, you need to allow a network request to happen to Drupal. And Drupal will not just allow request from any domain for security reasons. There's a variety of ways to do this. You can do this in Apache 2. There's ways to do it in NGINX. There's a variety of ways to do it in this session, but this is just one example. And obviously there's a lot of security concerns which are way above my pay grade in terms of thinking about cross-order requests. And now with REST and React, in order to make calls, make REST calls to our Drupal REST API, I actually recommend using Super Agent which is something that WordPress also uses to make API calls to the WordPress API. It's a very lightweight API and it's actually very comparable to jQuery 8x, but if you don't want to use jQuery as a dependency which we are not in this case, then you can use Super Agent as a much more lightweight solution. So let's rewind. So about half an hour ago, which seems like 30 years ago, we made a get request to node slash 1 with the 40 program format equals JSON to actually get our JSON payload back. Right? Now let's make this happen with Super Agent. So there's a couple of important considerations here. The first is you want to integrate with Drupal and you have Drupal and you're using React universally, namely isomorphically across the stack. Any request that you make during the server side are going to be synchronous. So during the execution of that server side in JavaScript, you're going to make API calls to Drupal. And there's a lot of use cases where this makes sense. Imagine that you have a cricket website and you've got some stats that have the scores of all of the recent matches. That is going to probably be served through something like MongoDB, because it's very great at the data. Drupal is not the best at handling this really great sort of small scale data. I think you might have some articles that are served through Drupal that you can look at or something like that. You might have this content that needs to be sent out from Drupal that you want to have in your application. So it could be that you're using MongoDB with your MGS stack and you're also wanting to make these REST API calls on the server side to Drupal to fetch this content so that they will side by side in your React application. Now to make synchronous request earlier, the most common way to do this is to make a request prior to the indication of render to string. So you want to make this request before the actual string combination happens. And that makes it part of React's render market. This is tough because the way that components work in conjunction with better string is a bit brittle in that it's not very clear where in the process you can actually make this happen. So to make this really easy and to make this very sort of clear what I've done is to use this approach in the React API component didn't know which is you know, oftentimes used for both synchronous, mainly on the server side React on the server side, and asynchronous request mainly on the client side when you exit to React. And you can dynamically insert data into the virtual rock with this approach. So if we go all the way back to our notes component and we remember this is what it looked like originally. We had our, this is the notes page this is the flat HTML and we have our render function. We want to add some additional functions here because this will allow us to use React's state machine. So if you look here what we've done here is we've added one additional import statement that's super good. We've provided a get initial state which is going to be the initial blank state of our component. This is traditionally how we've defined sort of base default state of each part components. And if you look we have our title of body and that's it. Now this is kind of pseudo-code I didn't test this and I will provide a code base that you know so this may change. Please don't copy paste this or use this right now. But what's going on here is what we're going to do is in this component we're going to get super agent and use super agent methods to actually get our JSON payload. So what we're doing here is we're doing a get request against that path interval. We're setting a header which is a set application JSON and in this case we're not doing any authentication because if you recall we opened up the permissions to all of our users to perform a get request against then we're going to basically provide a a oh sorry this is actually wrong this should actually save note here but anyway so what's going on is we're actually setting the state by providing by traversing that JSON payload and getting the title of body in front of us. This should make sense conceptually even if this code is not correct I think conceptually should make sense. What we're doing is we're going to get the request we're going to perform the request we've got our payload, traversing payload providing that into the state machine. After all of that if it errors out we want to provide a board of server request and then finally if there are any actual render function we're going to return this.state.title because now our state has changed so anytime we are making this request we act will say oh okay has this changed, has this changed based on when and where it performs these requests and as a result we're going to get much more updated data. Now I'm going to warn you right now this is a very very simplistic example and probably not usable in the real world just because of the fact that many people recommend using Flux to do this. You get a directional flow of that so I highly recommend if you do want to delve a lot more deeply into how this could work look at Flux and those sorts of approaches it's a little bit beyond scope of the session. Okay, so with that in mind we're running out of time so I do want to sort of end with some food for thought and some sort of larger considerations that you might want to consider when decoupling your goal and using React as your frontend. You can use any frontend that you want with decoupled your goal it doesn't matter and they are very compelling use cases to do this approach. So the first is I want to talk about a couple of use cases in the wild that I've seen and that are very compelling. The first is the Lullabot.com design which was very recent and there was a big article about it on their blog I highly recommend you read about it. It is a fully decoupled REST application that is built on a Node.js stack against a CouchDB database which replicates which is the REST API that is used in front of you and this is good for things like caching and things of that nature. In terms of progressive decoupling this idea of Drupal constructing the initial page structure and then allowing a JavaScript application to take over further re-reguring this is a very compelling concept as well and you can see this in things like if you use the React module in Drupal for example or there is a very interesting POC product called Drupal React Loss which I encourage you to check out it's on GitHub might be a bit outdated and then the other, of course, example of this is weather.com where they use an Angular frontend to take over from Drupal render that provides server-side. In terms of sort of more fully decoupled applications where you still want to provide some awareness of Drupal's render pipeline and some of this information Drupal can provide this important information about Drupal server-side render to a JavaScript application so I would highly encourage you to check out the rest of the panels in module this was just part of my intention this morning and it's a really, really interesting solution namely that you export some information about panels through JSON to the JavaScript application which then uses that to construct the page and so this is a very, very interesting idea because it means that you no longer really you can have your site builder use panels and use the grid to actually change the column width but then export that to the client-side and we'll use that information intelligently there's a whole lot of interesting approaches that are that really are sort of across the spectrum and it's a very overarching question like where do you draw the line right do we just serve pure data from Drupal just content just these condensings do we serve some render information like restful panels in that we actually give some information about how these things would appear on our server-side and the worst ones were both the client-side or do we actually do more progressive decoupling where the client-side framework is very much a part of and inside Drupal there's a lot of different discussions that we can have with that one last thing I want to end on is that React is not alone React is part of the larger ecosystem open-source projects that Facebook has been working on and so two projects that I do want to highlight in our React and GraphQL I gave a small mini-session at the Acquia booth yesterday about GraphQL but basically these are two very compelling approaches to things like data fetching which could be very interesting because there's some weaknesses of the way that we build traditional restful architectures today so what I want to do is just highlight GraphQL very quickly there's a Drupal member who is working on a GraphQL server for Drupal which is a very, very nifty and compelling idea and I encourage you to follow this project because it's going to be a really interesting approach to data fetching from Drupal itself and so what I want to do before actually getting to that slide is I want to just very quickly show you a quick a very quick video of what GraphQL does as a demonstration of some of these things that we've been talking about I showed this video yesterday at the mini-session so what's happening here and this is sort of a way to abstract away all these considerations you don't need to use rest as a transport necessarily when you're using GraphQL it could be sober, it could be something else we've got our custom content type which is conference and what GraphQL is going to do is to actually submit is to make a request that will mirror the response you get back from the survey so what we're doing here for example is we're firing a request against any of Node ID and getting back only that one of the big problems with a lot of REST APIs is you really get too much information and if you're talking about things like single-paid application they have different data needs and oftentimes we want to talk about unifying these endpoints and making sure that our rest endpoints are very efficient so what's happening here is that we're actually querying use this is the traditional admin slash content using Drupal and we're only getting those conferences that are that are held in Europe and what we're going to do even further is to query also the additional custom fields that we have as well so GraphQL is a very very interesting example and one of the very exciting things is happening around the React ecosystem and if you're using React already in a decoupled way with your Drupal site you're actually a leg up in terms of being able to potentially use GraphQL as your sort of data fetching and querying that and so with that in mind I want to end briefly with let's see just let this go and it's also able to sing as well yeah yeah so let's go ahead and go to the last slide which is there's been a big debate right now in Drupal which is should Drupal adopt a client-side framework in order to basically keep a lot of the stuff that we like and enjoy with Drupal and that is useful for site builders this has been a topic of several blog posts by Grace Lately so I want you to think a little bit about how React fits in with Drupal does it make more sense as a fully decoupled growth does it make more sense as potentially something that could go out on top of Drupal as backbone does right now so with that thank you very much and I look forward to hearing from you.