!= Bleeding Edge React - Sessions by Pusher

Bleeding Edge React

Marcel Cutts speaking at JS Monthly London in October, 2016
271Views
 
Great talks, fired to your inbox 👌
No junk, no spam, just great talks. Unsubscribe any time.

About this talk

React and its ecosystem is an ever evolving beast, with new features and practices rolling out constantly. In this talk, we'll go through what React offers, set up a modern React project with all the trendiest toppings, and demonstrate how to go about writing React components in a way that’ll impress even the sternest hipster. A perfect intro for newcomers ready to step into up-to-date React, as well as experienced React users looking to update their projects to benefit from the latest bells and whistles.


Transcript


All right, hello everyone. My name is Marcel. I'm going to talk to you people about what I consider Bleeding Edge React. So we have lots of requests about, you know, what is the React like nowadays, what I should be using? And it's those people who aren't on the React train but would like to be. So from a quick show of hands, who here uses React day-to-day? Who doesn't and would like to? Who finds the whole React thing currently super terrifying? Okay, good. All right, that gives me a sort of an idea of where to pitch the talk. All right, so, a little bit about myself. I've made software for everything from...it's always opinionated software, this talk will be very opinionated. It doesn't mean that whatever I say is the absolute truth, but it's what I think at the moment, subject to change. So I've made software for anything from big machines to [inaudible] little things, to running games that have strong story lines, blah, blah, blah. So a very wide range of stuff. And I am now doing a lot of webtech for people called Red Badger, who are hiring, so, you know, if you're interested. Okay, so a bit of history about WebDev. Now, I'm sure we've all had a bit of history putting together monstrosities like this, but this was the the way it was done for quite a while. You know, we get a huge HTML page, you stick in some CSS, we kind of get it to work and then what we do? We stick it in this FTP bucket, we kick it up the Internet and go like, "Yeah, all right. Fine, here you go. Done, sorted." But the Web advanced and things got more complex, and people wanted better things, and we could do better things, which is fantastic. And I think the first big step in that direction was jQuery. So originally jQuery only existed to make selecting stuff on web pages easier which seems such a trivial thing nowadays. But there was so much difference between Netscape Navigator and IE and later Firefox. And it was actually quite hard and jQuery came in and later became this catch-all everything machine, this library that gave you everything you wanted. And it even gave you AJAX, which completely changed the game. So AJAX obviously comes with the JavaScript standard by itself, but it made it easy to use, and then you could do cool things like Gmail and have things pop in without refreshing whole page, wow. But then we got to the point where we thought, "Well, we've got an awful lot of piping, awful lot of logic, awfully large creaky app that we sort of monkey-patched together in jQuery, it's more like an application. How are we going to control all this complexity? So Angular, I think was the, like, most well-known attempt at a classic application with an MV-something approach to doing this. Angular was released in 2010 and there were lots of things in a similar sort of data binding sphere. So stuff like Ember, stuff like Knockout, but I think it's indisputable that Angular was the little king of its time. And now we've got React, hurray. It's fantastic, and I'll tell you why in a second. I will say I know these three aren't directly comparable. jQuery is a convenience library, Angular is a full-on framework that lives in your client-side browser, and React by itself is just a view layer. But I think these are the technologies that are kind of steering the trends in webtech or have steered the trends in webtech throughout the years. Okay, so what does React offer? Why should you bother? Why aren't we all just doing everything in VanillaJS? Because, you know, we love to hate ourselves. So React, at the core level, it offers components, and components are fantastic. The reason components are great is because it lets you put all of your templating and logic and everything into a small reusable piece that you can compose with other components, either as children or together in stacks to make full front-end interfaces. And that's great because these are self-contained and it's really, really difficult to step on another component's toes. This gives you reusability, it also gives you some certainty and predictability in how you build your interfaces. It's also very good for designers because they can break down exactly how things are working and put small pieces together that then have this common theme throughout the application. And it lets you do things in a more functional manner, which we'll get to more later. So components are great. Components don't tread on each other's toes. Data only goes from parent components to child components, which is great because this allows us to use the Virtual DOM. So back in jQuery times, often what we do is we would just have some Logic, user takes a thing, then we'll go and like rustle some divs together, poke a thing, change a color here, I don't know, let's hope for the best, and hope that you never mess up the state. Because the state exists purely inside the DOM, so your data layer is also your view, sort of, and that's very scary. The Virtual DOM is a little more clever. So whenever you want to make a change, it's done in the background, and then React with its Virtual DOM will figure out the least terrible way of making the front end behave in the way that you specified. And this is great because it offers a lot of performance gains, but also lets you do lots of very clever things. Like only rerendering very small portions of your application as you need to. And also it lets you have a very, very, very easy path to Universal Rendering. It used to be called Isomorphic Rendering, but that's kind of fallen out of fashion, I don't know why. Or, I do know why, but it's a very complicated political story, so let's not go into it. And Universal Rendering means that it's actually very easy for you to service-side render and client-side render your application. Something that like...one of the big criticisms of the original Angular 1.blah was that you needed to have JavaScript enabled, and this really cut out a lot of devices, especially from third-world countries and other sort of places that have very limited JavaScript support and capabilities. With Universal Rendering, you can render stuff in the server, and kick it out, and then if the client has the capability of running JavaScript, give him that as well, and it's fantastic. So I currently work at a project where we inspect all the user agent strings, and depending on exactly the capability of the device asking for it, we serve you more or less of the JavaScript that you're going to get. And this really burst through a lot of performance things. Often we spent a lot of time really, really, really hammering on performance going, "Oh, we know. Let's do some Angular, let's have a repeat going, and then we have lots of bindings. Oh, how do we cut this down, blah, blah, blah." But this way, we only really serve JavaScript to people who really want it and we don't sort of live on the edge of devices that can barely handle it, and I think that's really cool. And you can do some very clever stuff. Cool, so what's next? Yeah, the other great thing about React is that it has a fantastic ecosystem. It's very large, and it's very rapidly moving, but I think this is a pro rather than a con. So I'm sure everyone has read an article or 2 over the last 3, 4, 5, 6, 7, 10 years about a concept called JavaScript fatigue. Which is this notion that the JavaScript ecosystem should settle down, behave itself, act like real software, and get its game together, and decide exactly what library is the correct library? What framework is the correct framework, and exactly what styling solution is the correct styling solution? Blah, blah, blah, blah, blah. But I think that's very naive. React's very rapid pace of nurturing new libraries, new ways of dealing with data, new ways of handling problems reflects the fact that the Web is progressing very much. We want more from it, we can do more from it. For example, offline-first applications are now becoming more commonplace, or service workers are going to make things better and better. And we need systems to manage that complexity, put in these more full-figured applications into the wild, and that's going to require new software, new ways of doing things. And, you know, I think the React ecosystem really reflects that. There's also been a sort of gradual shift towards more functional programming, becoming more popular again, after OOPs, you know, had a long time in the limelight and a lot people have criticisms in how this is, you know, working for very large, hard-to-maintain applications. And the ecosystem here, because it's so rapidly moving, can't give you many options to explore a more functional way of doing things. But it's not just the ecosystem, React itself changes a lot. It's tried to settle down a bit, but it still gets new features all the time. It's getting a new engine soon to increase performance. It has new syntaxes coming out all the time, and it offers new features all the time. It doesn't mean you have to use them, the old ones work just fine, but it's there, and I'm going to talk a bit about how to make what I consider a very modern Reactor. So...and I promised it would be super hipster, and it will be. Okay, so let's get Adam up, right. So for those of you who have never seen...I will make this a bit bigger, blah, blah, blah, blah, blah, blah, blah. For those of you who've never seen React in Angular before, this is a little hipster project put together, using all the best technologies, all the hipster technologies I knew. I'm giving myself only 20 minutes, because there's a big stigma that, you know, you go to a hackathon for two days and you come back and say, "Well, I might have just hit a bubble." Yes, so, here we go. We've got the normal head stuff, this is just things that tell you, you know, "Okay, I'm going to be using UTFA blah, blah, blah, this is completely independent from React. The things we care about is the Root Div and the Script Tag, which is where we're going to put our bundle, which comes from webpack. Ooh, let's go back on this one a bit. So webpack isn't some beast, the problem I think is a lot of people look at React boilerplates, and the webpack is pages long or it has its own folder or something else equally insane. But it doesn't have to be like that. So this is a simple bundle, and for those who don't know, webpack takes all your JavaScript requirements from your node modules, blah, blah, blah, blah, blah, blah, and it sticks them all into like a single bundled-up JS. You can split the bundles as well, there's all kinds of things I can do, but originally this gives you like a single bundle. And this approach is a bit smarter than the previous approach of having those script tags inside your indexer HTML, where some gulp thing would read the comments and then insert all the script tags for your separate requirements in a row, hopefully in the right order, otherwise you're in trouble. So, cool, we have our entry points, which JavaScript files go into first, and also where we want to put the output bundle. Cool. And we have one loader. And the loader just does a bit of redress, goes like, "Okay, so if you're a JS file, and you're not in node modules, then I want you to run something called the babel-loader." And all this will do is it will convert your fancy future JavaScript code into something that will run on pretty much everything. Just as a show of hands, who here regularly codes in ES06, 07, or ES 2015, 2016? And who here has never done it? Cool, right. Well, so, if there's some syntax that no one recognizes, just scream and I'll quickly explain it. Yeah, so let's look at what an entry point of React actually looks like. So here we go. We've got our end point statements, we want some Reacts, we want to render something from React On, because the React Call is different from the actual rendering into the DOM section. It used to be combined, but now we use the React On, React Native and other platforms is actually being separated out and you can just use it independently for lots of different things. Ooh. Yeah, and we're going to make something called a container counter or count thing. I'll just give you a quick look of what it looks like, blah, blah, blah, blah, and then...and we're going to zoom in on that bad boy. Right, so it's very simple, and like I said it's all in 20 minutes, so you've got something...you can count up, you can count down, and you can reset it to zero. Hurray, and there's some styling going on as well. Yeah. Cool, so let's have a look at our count button for example. You can see what we've got in the constant count button there, it's called a functional component, in which the component is literally just a function. It doesn't have anything fancy like a class to extend, or create a class method on React itself. For those of you who are completely new to React and you're wondering, "Why on earth are there things that look like HTML inside my function?" That's called JSX, and it's a way of keeping your...well, your template stuff, essentially, inside your component, rather than your Angular approach, where everything is split into wide columns and then you'd have difficulty, like, putting them back into a singular component. Components should be self-reliant at all times, which makes them much easier to grok, and also work with day-to-day. Cool, so hopefully it should be fairly easy. We get something...An onClick function, so it tells us what we should do when a button's clicked, we get some text, which will define what's on the button. And that's basically it, and then we export it, so that's the three buttons you see. And they appear just here, so the container for this all is just, you know...We've got three buttons and we've got a counter. It's super easy, because we could just compose these components together to make larger UI objects, cool. Now, something that probably may look less familar is this props malarkey at the top. So I did promise this would be fairly hipster, this is called Flow. So Flow is a static-type applier from Facebook that lets you add types to your regular JavaScript code. There's a lot of interest in this field at the moment and TypeScript is the other big one and that's quite popular, but it gives you a lot more predictability, and a lot more certainty in the code you write day-to- day. With strong typing, you can have lots of type safety, and with that comes a lack of runtime exceptions, for example, if you do it all right, because you don't accidentally pass a null when it expects the string. You don't access properties on an object that'll be on the side blah, blah, blah, blah, blah, and it's very, very cool. And it gives you, especially on larger projects, a lot more certainty and confidence in the code you write, and I thoroughly recommend this, loads of fun. Cool, so that's what the props are about, and as you can see the onClick we expect that to take an object, E, and return void, because we don't expect it to return anything, and we expect the text to be a string. It also gives you some cool UI help if you install Nuclide or something similar. So in the counter...or if we don't give it a string, we give it a number instead here, where it expects a string, let me save that. You can see that it quickly pops up saying, "Oh no, no, no, no. This is an incompatible type, don't do that," and has lots of other helpful things like automatic parameter documentation yeah. All cool. Okay, let's figure out something a bit more complicated. Let's look at a display. So one of the really hard parts that we've been struggling with for the last two or three years with React is how do we style the damn things, because CSS isn't part of the component, it's always been separate, and there have been lots of attempts to tackle this problem, we're having things like BEM. We have a very, very disciplined naming style, to ensure that your style doesn't trickle on to other components, because the cascading nature of CSS makes it difficult to have a component-based approach applications, because, obviously if you have a...let's say you have a block here that says, "Oh my background's going to be blue." It's going to try and cascade it out to his children, and they might not want to be blue. You expect them to be repeatable and safe and confident and not just like, "Oh, why has suddenly everything gone weird?" That's also one of the reasons why it's really hard to refactor CSS, because if you cut something out in the middle, it's going to trickle all the way down to all these children, so hard times. CSS modules is also a very popular approach, trying to import your CSS files directly to the component, but I've recently been liking this thing called style components, where you literally write your CSS inside your components, and you wrap them around, like you're just wrapping a function, like you would with functional programming. You can have a pipe operation that still has a component on the way, and you know that they're going to be contained to exactly that component. So for example, here in this case, we are giving it a special kind of StyleDiv, we should probably name something with than just Div, StyleDiv for some clarity, but we can wrap this around custom components or core components just used here or whatever, and this is what gave the counter that red look that we saw earlier. So that's one way of approaching styles. There's also styles directly in JavaScript, which have been gaining a bit of ground. You can see this in stuff like React Native, and also see stuff like Radium and other libraries like that, and that's got its ups and downs as well, so you have all the power of JavaScript, but you're not entirely sure, like, some things that are harder...Media queries tend to be a bit tricky and that sort of thing. I'm fairly undecided, I think it's a very, very emerging area at the moment, because styles are hard and CSS is complicated and inconsistent, and there's so many browsers to consider, blah, blah, blah, blah, blah. Cool. And last, we're going to have a quick set back to this presentation. Blah, blah, blah, blah, blah, one somewhere. Is that okay? Yeah, cool. Cool, so yeah, I just was saying earlier, we had lots of different ways of making components before. We had this little Reactor createClass which auto bound everything, including handlers and states to one variable. Then we had to sort of extends React component, which is a bit more JavaScript-friendly. I will say that extends component is still very, very popular and you don't have to use the whiz-bang functional stateless approach I had showed here, but don't use createClass. It's been deprecated and also it runs 80% slower on load for reasons that are extremely complicated. Unfortunately. I wish they were elegant. Okay. Right, so, [inaudible] so many use these functional stateless states, but you're going, like, "Okay, functional and they're stateless, because we just pass everything into like a pure function from functional programming. It's a complete deterministic, there are no side effects, well if you put in the same thing into the parameters, the same thing will come out all the time no matter where they're run. How on earth do you have state, because state is important. Like our applications are very boring without states, your emails server would be very boring without states. It would just be blank all the time. So this is where Recompose comes in. Recompose is a fantastic little library that gives you tools, kind of like lodash/fp. For those of you who haven't used it before, it's a kind of convenience library that you can use together. So you can lift all these state four and complex things into your functional status components. But you do it in a pipe way, same way you would in many functional programming applications. So, for example here we can say we want a state of counter, we want that to be a function of Assess Counter which is how the buttons went up and down, with their counter, and we wanted to start at zero. And then we just map those onto props that we are going to pass in, and are destructured by that squiggly bracket stuff down here into these properties. So we've got increment, which obviously means like we're going to go up, we're going to go down, and we're going to reset, which is where the functionality comes from. But it means we retain this absolutely pure, pristine, small, presentation-only function component. Separating it out is a fantastic approach of keeping away those huge React components that inevitably appear. So...And trust me, they do, in every large multi-React project I've seen, there will always be some person who just makes the world's largest React component of all the logic and functionality in the world. And then it's a real, real hard time getting it back apart. Cool, yeah, and that's Recompose, and I would really suggest looking into it. It's not nearly as scary as it looks, and it can really, really help you simplify and keep your code in small pieces but still as a singular component, that's the important part. Cool, so one thing I didn't get to do with my 20 minutes is talk about testing, so let's talk about that for a while. So we talked about Flow, static type checking, very cool, because of confidence and certainty. Style components, we can add style using template strings to all of our stuff, it can be done [inaudible] as well, so it's a little more powerful than regular CSS, which is very nice. And, yeah, for testing nowadays I would recommend Jest. Jest used to be a bit [inaudible], we used to run on a stack of...Most popularly run on a stack of Mocha, Chai, and SignOn for test running, assertion library, and stubbing respectively. But now Jest kind of does all of it. It used to be kind of [inaudible], don't tell Facebook, but it's gotten a lot better, we've put a lot of work into it. Now it's really performing, it has multi-threading by default. It no longer auto-mocks, it has really powerful syntax. It lets you do lots of shallow rendering if combined with something like Enzyme. And you can have...You can test all of your components piece by piece to make sure they behave exactly how you expect them to. Which is, again, really easy when you do small presentation-only components and you put all this logic out to decide and test that separately. Cool, so, Jest. What else is on the menu? Yeah, so I think that's how I would approach creating a modern React app, and the way I have been doing it for the last month or two, and I've been having very good results in trying to move a very large React legacy application to a more modern way of thinking. Server-side rendering is definitely a plus. I know lots of people find it very, very scary because it's different from just bunging something on the client. That's what we've been used to for quite a while. But with React it's very, very easy. It's simply like very, very, very similar to the...Where's the container, the index file, there we go. So rather than having like, you know, render, you just have a render do string somewhere on your node. And look, we've got some types because it's been flowed up. Yeah, so I would definitely recommend doing it and it'll definitely make a much better experience for your users. And if all of that hasn't been hipster enough for you, why don't you check out Elm, which Is the block or blast of color on the right, and Elixir for your back-end needs, which they are both fantastic, up- and-coming programming languages. Elm has many of the traits of React except it is its own language, made by a guy called Evan, Chris Evan? No, Evan Chris something, something, something. A really nice guy, and it's really, really hot at the moment, and it's going to be quite large. And Elixir as a back-end language is very powerful. It gives you lots and lots of great tools and it's based on the BEAM VM, Erlang users, so it has really good fault tolerance and really good concurrency and everything else that makes running things at scale a lot easier. Anyway, thank you very much, and if you have any questions, do shout.