 All right, looks like it's about time. Can everybody hear me okay in the back? Everything good? Cool, there's plenty of open seats. Please come in, sit down, we're gonna have some fun. This is Introduction to React Design Patterns. My name's Brandon Williams, I'm with Amazee Labs. Before we get too far into things, my stuff stopped working. There we go. Before we begin, I just wanted to ask quickly, how many of people have not done anything with React yet? Okay, the majority. What about like, have you played with it at all a little bit here and there? Okay. I wanna make sure we're kind of on the same page in terms of some terminology, some things we're gonna be talking about. This is a quick 25 minute session, so unfortunately I don't have time to go into real basics. If you've never heard of React or you've never looked at the basics of React, I'm not gonna be able to cover that. But what I do want to cover is some of the reasons why I think this talk is needed. And for that specifically about React, it's a JavaScript library used for building user interfaces. It's declarative and it's flexible and it makes creating interactive UIs way easier than it was for previous generation JavaScript libraries. But it is just a library. It's not a framework, it's not a CMS. And what that means is there's a lot of stuff that you have to figure out around React in order to actually build something useful. And that's where these design patterns come in. And also design patterns are formalized best practices and these are just my opinions. Not really formal, this is how everybody should do things. React is a lot like Drupal. There are a lot of ways you can accomplish the same goal and these are just the things that we've done that have worked for us. So why should you care about the things we've done? Little background. I'm the lead developer for Maisie Labs Austin. We've been doing Drupal 8 sites in production since Drupal Alpha. We've been doing React projects since 2016. We've done a whole broad spectrum of stuff. Everything from single page applications, large and small, small being like our Texas campsite, large being 12 separate React websites are running off one Drupal backend. We've built interactive lobby touch displays for clients. We've done embeddable widgets that you can put on different websites. And also just like improving one small search filter page, that kind of stuff. We've kind of done the whole gamut. Also my colleagues in the Zurich office have basically written and maintained the GraphQL module for Drupal and that's what we like to use when we do React projects to do data communication stuff. Just a little bit of background on us. So design patterns. Again, I don't really have enough time to go into a lot of really intricate detail on all these things. So what this talk is really designed to be is a list of stuff that you should go and Google later to figure out how to actually do the things. So first off, we have a classic Presentational Container Components. This is an old design pattern, old in terms of JavaScript land. It was from a blog post written in 2015 by Dan Abramov. And the idea is how do you separate out your business logic and your presentation logic? So he coined these terms for Presentational Container Components. A Presentational Component is concerned about how things look. What kind of HTML do you use? What kind of styles are there? There's little or no state in the component. You're not actually managing anything there. All the data and all the behaviors and interactions it needs, it receives via props. They're generally functional components, not React classes. And the similarity here with Drupal is really twig templates. In twig templates, you have some if then statements and you can do some programming things, but in twig you can't go call the database layer and do all these other stuff. Really, you need all the data that you're gonna render given to you. The flip side of that are Container Components. Container Components are concerned with how things work. They generally will themselves render more Presentational Components or other Container Components. They're the ones that actually handle all the data management, they'll go out and they'll call some REST API or whatever else and massage all the data needed to then give to the Presentational Components. And they're generally the ones that have and contain any of the state management that you would need in your React application. A small example of this is on your left, a Presentational Component, it's just a function. It accepts an argument of comments and it returns some JSX that just prints out all the comments. It doesn't go get data anywhere. It just says please give me the comments and I will spit them out for you. On the right we have a Container Component. This is written using a React Component. It's very not real code, but essentially in React on the Component did mount, it will go and it will fetch all the comments and then it will render the Presentational Components and pass the comments that I got previously. You have this clear separation between how stuff looks and how stuff works. So why would you do this? Separation of concerns, this is the same thing that everybody does, MVC, all these other styles of hey we don't want to mismatch our business stuff with our view stuff. Doing it this way, your Presentational Components are, especially if you use them as Functional Components, they're much more easy to test because you put one thing in, you get the same thing out and it's easier to put into style guides because you can load them with dummy data because they don't know anything about the real data. In terms of difficulty for how hard would it be to integrate this into your applications? I'm gonna get one star, meaning very, very easy. This should be something we're used to for any other kind of programming languages or architectures that we've done before. Next design pattern is Stateless Components and Functional Programming. I touched on this a little bit with Presentational Components. I said generally they are Functional Components. What does that actually mean? When I talk about Functional Components, I'm also talking about Functional Programming. This is a different paradigm than Object Oriented Programming. It uses pure functions. Pure functions are, you put in some data, you get the exact same result out. It has no side effects, a function won't do something else that affects something else somewhere else. Also, a function shouldn't be affected by something else somewhere else and the Functional Programming nature is more declarative instead of imperative. You might recognize that word because React is also a declarative library. Functional Programming prefers composition over inheritance. So instead of having an object inheriting from another object to share some base code, you would have two functions that get composed together that then share the same code. Especially in React with Functional Programming, we prefer immutable state, meaning when you pass something into a function, it won't change the thing it was given it, it will give you something new. The example here is a little more detailed. I have an input button that you pass three props, the label, a non-submit handler and whether or not it's disabled and it just renders those three things. So you can see that no matter what happens anywhere else in the application, the output of this function doesn't change and this function can't change any other state anywhere else in the application. Whatever you give it, it will give the same thing out no matter what. And that's just a simple, it's just a function we are used to writing functions. It's Functional Programming is just a little bit of extra stuff on top. And then a stateless component in my opinion is really just a pure function that just returns JSX. So why would you use stateless components in Functional Programming? For us, the declarative nature of Functional Programming really makes sense to use if you're already going to be using a declarative library like React. And declarative means you tell how something should look, not like how it should actually do the thing. So in React, you say please change the state so that the button is enabled. You don't have to write the JavaScript to change the enabled attribute, you just say it should be enabled and it just happens. The Functional Programming also uses that declarative nature where you don't have to define how to do something, you just define what it should be. When using the immutability kind of features of Functional Programming, especially with React and state, it helps to avoid any rendering errors. So React will re-render a component when its state has changed. But if you change the state in a way that's mutable where React didn't figure out that the state changed, then you won't get a re-render and now your data doesn't match your output. In my opinion, it's a lot easier to reason about your component dependencies. You can look at a functional component and see exactly what data it needs as its function arguments. And you can see exactly which behaviors it can call versus React class where you have to maybe go hunt for any of the lifecycle methods or any kind of inheritance. It's there in your face. You look at the arguments and you know exactly what this function is doing. I also enjoy the fun vocabulary that you get with Functional Programming, stuff like MapReduce, Functors, Monads, Monoids, Curring, stuff like that. You get a wow, all your non-functional programming nerds and make yourself look smarter than they are. In terms of difficulty for implementing this in your workflow, I'm giving it three stars because Functional Programming really is a paradigm shift. You have to change the way that you've thought about writing code than you have in an object-oriented world before. But it's not, you can start easy, right? You can write Functional Components and you don't have to go all full Functional Programming and map and reduce everything. Start with your Presentational Components, you just decide we're not gonna use classes for Presentational Components, we're gonna use pure functions. And as you use those, you start to see other areas and easier ways to use more of the Functional Programming stuff. So that's great, you've decided we're gonna do Stateless Components and we're gonna use Functional Programming everywhere. And then you realize, oh, well I actually need to like keep track of state because users wanna click on a thing and I wanna know when that thing happens. So what do I do? In comes the higher order components and higher order functions. These are really just a function that returns another component or function. And it's confusing at first, but this is the composition over inheritance where you say I have this bit of reusable thing and I want to apply it to these other functions. So in this example, I have a loading higher order component. So if a component needs to load data, then I want to hide that while the loading is happening and then show it once the loading is there. So I have this with hide loading function, it accepts a base component and then it returns a new component, a new function that accepts props. And if those props has loading true, then it doesn't actually load the component. If it's false, then it loads. It's, but it works, right? You look at this and you don't understand, you copy paste a bunch of things and then it kinda clicks. This is your Google task for later. Especially nice thing about higher order components with React is a library called recompose and it basically handles all of the life cycle type stuff that you need state and React for. I'll show you an example in the next slide. And the comparison I'm making here with PHP and Drupal is higher order components solve the same use case as PHP traits do or object oriented decorators. So in a trait where you say, hey, I have this code that I want to share to like a whole bunch of objects, you can use a trait instead of inheritance there. That's kinda the same that you can think of higher order components. So here's an example that uses the recompose library. Recompose provides a with state and with handlers higher order components. So on the left, I'm defining a with disabled state and a with disabled on submit. And basically that would be the same thing as if you created a React class and you had this state disabled and it has a default of false. Essentially this recompose library is under the hood adding in these React life cycle methods so you can keep your functional component pure but add all the React stuff that you know and love on top of it. So on the right we have the same submit button that we had before but I'm composing our with disabled state and with disabled on submit state and that creates, you can pose those together with the pure submit button and it will give you a new button with disabled. So now anytime you click the submit button it will change the disabled state to true. But your submit button is still a pure function. You can still do the testable and all that kind of stuff with it. So why use higher order components? Why use functional programming? This is the way to keep your code dry. Use higher order components to copy and paste all your code across all the places but not in a bad way. Keeps your functional components pure. You don't have to convert your pure functions into React classes every time you wanna add a little bit of React state here and there and it's the same separation of concerns that we are always concerned about as programmers. I'm giving this two stars because it is a little difficult to figure out at first but once it clicks you start seeing this pattern everywhere else in your code and they're easy to write. I also mostly talked about higher order components this whole time but it also applies to higher order functions. Higher order functions are just functions that return functions and it's a way to reuse code in functional programming for stuff that's not related to React components. If you don't need to render something but you still need to share some code across functions you would use a higher order function instead of a higher order component. So maybe that sounded terrible to you. You don't like functional programming. You don't like higher order components. That stuff is too hard. That's fine. There's still ways that you can share code without copy pasting stuff and there's this design pattern called render props. It's also called function as children. The idea is instead of using a higher order component to decorate another component you just define a render prop and when that thing does what it wants it will render whatever you passed in the render prop. So this is the exact same behavior as our previous higher order component where it won't show something while some data is being loaded. So I have this hide loading component. It has a prop on it called render and if loading is true then it doesn't call the render function, the render prop. If loading is false then it does call the render prop. The advantage here is you can see exactly what's happening. There's really nothing hidden behind all your function composition. You can see that well if loading is false then what's gonna render is exactly the submit button. I gave this a one star because you can do this without having or knowing or caring about functional programming or higher order components or any of that other mumbo jumbo. And you can do this, this is easy to understand and a lot of the newer React stuff that's coming up like in React 16, the new context API they're going with this render props pattern. So we have all the ability to write good components and keep them dry and testable but how do we manage data? This is a long and tricky subject. There are a lot of right answers. Currently, I like the flux pattern. The flux pattern is more application level stuff. So React is really just kind of a rendering or view library. The flux pattern is more application that gives you more structure around your whole application. The idea is that all state changes flow in one direction. So anytime you need to make changes to your state, you change it in the global store and that will trickle down to all your components and state never goes the other way. So you can't change state on your component and then your component tells the store. It's always you change state in the store and then the store tells your component about the change. This little diagram here is from their documentation. You have a store and that's where all of your state actually lives. When you want to change something in the store, there's a dispatcher function. You dispatch this change. Say you want to add a new evaluation for my session saying it was really good and I appreciate all you've done. Then the dispatcher will call the store and say, hey, I have this new evaluation for you. And the store says, thank you very much. I've added that. It then notifies the view layer. In this case, we're talking about React. It tells the React like, hey, I have this new evaluation. What do you want to do? React will then, you know, however you've coded it, push that state changes down to React. The view also has access to the dispatchers. So whenever you click a button, you can dispatch a new action. State always flows from the store to the components. This is the reason that immutability is important. It's because if all of your data in the store is immutable, then all state changes will cause re-renders in React. And you won't ever accidentally change some state and not render the thing on your page. The flux is just a pattern or like a guide of how to do this thing. There are a lot of libraries that are written to actually handle this pattern. The most popular by far is called Redux. It has a lot of extras included for you to help you out with like async, data calling, and middleware, and some other stuff. So if you're interested, you don't have to use Redux. You can write your own flux architecture. The recomposed library even has a few helpers to do your own flux style pattern. But you can just go ahead and use Redux and it works great. I'm giving this a difficulty of two stars because you have to do a little bit of boilerplate with the flux pattern. You have to write some extra code that doesn't seem useful at the time. And then later it still doesn't seem useful, but it's still necessary. Cool. If you have any questions, go ahead and line up at the microphone and I'll go through the rest of the stuff. Texas Camp, we're holding it in Austin. The last week in May, first week in June. Our call for papers is open at 2018.texacamp.org. If you promise to submit a session, I have stickers for you. Please come. Also, I'll be at the Contribution Sprints on Friday. If you want to do some React stuff with Drupal, they're looking at changing the administrative UI to use React. I'm interested in that. We can hang out, talk about that kind of stuff. Any questions? Comments? Did I get anything wrong? That's a no. Okay, that's a good sign. Cool, I appreciate it. Thank you for coming, everybody. Mm-hmm, totally. Yeah, no worries. Very good presentation.