 Hey everybody. How's it going? That was rhetorical. All right, so welcome to six degrees of JavaScript on Rails. I'll introduce myself in a second, but while all people kind of keep piling in, I'm just going to tell a short little joke for you guys. So the other day I was going to a, I was going to a museum and I was really excited. I was really looking forward to it. It was an Etch-a-Sketch museum. Just going to see all this fabulous Etch-a-Sketch art, but there was an earthquake the day before. So by the time I got there, it was way too abstract for me to understand any of it. Anyway, that has nothing to do with any of this, but you can like try to read into it super hard if you want. Anyway, let's get started. Who am I? So my name is Michael Krizmali. I work at a company called DevMind Software. I started out there as an apprentice after finishing a codebook camp at the starter league out in Chicago. I'm currently a senior developer there. Lots of good times with lots of good people. You can find me on GitHub. It's just my last name, Krizmali. I would have put my Twitter up here, but I don't tweet or go on Twitter, so don't want to waste your time. Cool. So there are six degrees of JavaScript on Rails. Let's get into it. I went super hard on the page flip animation too, so get used to it. So why should you care about this? Well, there are a few reasons for that. The first one, JavaScript isn't escapable. JavaScript is coming for everything, can run it on native, it's everywhere. So learning to kind of like get along with it will make your life a lot easier. And especially for us as like Rails developers primarily working in web applications, there are just certain things only JavaScript can do for us, right? And a big problem that I've found kind of like in our industry and across different teams is that because everyone has to use JavaScript, but everyone has a preferred kind of like backend framework like Node or Rails or whatever, is that essentially JavaScript ends up being kind of like or browser-based JavaScript ends up kind of being like a sort of like a second-class citizen in your application. It's something you write just to get through it, like you need that little animation, you need that flash message to fade away, you get in, you get out. It doesn't look very pretty, but you don't have to like look at it ever again. But most of us are on teams with other people and we all have like different skill levels and we can have different levels of comfort with JavaScript. So for someone who's say like much more experienced might be trying to pull the team more towards a one of those like sleek new like single-page applications or a progressive web application or whatever the sweet acronym is today that everyone wants to build. But then you have, you know, other people who just use to jQuery or don't know anything about JavaScript and all these people have to work together and supposedly they are like all kind of like the same because they all have the similar backgrounds in Rails probably. But when it comes to JavaScript, like the amount of like disparity and like skill level can like vary wildly. That's a picture from the WWE, I think. So what ends up happening is we end up feeling like we have to make a choice between one of two screens. We either stay as like vanilla Rails as possible, just ERB, Hamill, like basically as like stay away from the asset pipeline as much as we can. Or we have to go all in basically build a Rails API and then set up and deploy a second like JavaScript only single page app and get us three set up and all that good stuff. And that's, I don't know, that's a difficult choice to make when you have people on your team that like may not all know the same thing. Like in true like a single page app has like some hot user interaction capabilities. But if you know only one person on the team knows it, things aren't going to go super great. So that's kind of a false choice. You don't have to choose between just like vanilla Rails and like a single page web application. You can kind of mix it up and we can go through kind of all of the various degrees of that. And a little side note too, there's actually, this is a spoiler, but there's maybe like a secret seventh degree, but my talk like six degrees makes a lot more sense than like seven circles. So just wanted to like stick with that. Also too, there will be no like Kevin Bacon reference in this talk. If you're waiting for that, it's not going to happen. So the first degree is unobtrusive JavaScript. This is JavaScript that kind of works out of the box and basically every Rails application. Once you pass some fun command line arguments to Rails new. So it's pretty slick. It's pretty nice. You can basically get away with not knowing any JavaScript, but creating some like pretty nice basic user interactions. And like a lot of times like you don't even realize you're using it. For me personally, the time I always forget about it is when I can't just set method on an A tag and get a delete out of it. But yeah, all of these are examples of it. Like getting a nice confirm box to make sure people like really want to do it. Disable with unsigned in. If you've ever had someone give you a bug where they created three of something because they just keep clicking the button. So yeah, so most people like this is fine. Anyone can kind of work with this if you're like proficient in Rails, you can get away with dealing with this. The next step, getting a little harder is you have like jQuery or some kind of widgets getting sprawled out all across your page. So this is classic. This is what I feel like JavaScript development in a Rails application is usually like for most people. You end up here basically probably a few script tags. You're not really organizing it. You just kind of like do what you have to do. If you're clever, you probably have a characteristic around naming or applying certain class names to certain elements. So things just kind of happen automatically and you don't have to think about it. Generally like type of head search or custom drop downs. Those are the most common places in my experience. And usually like eventually this kind of, well let's go through this example real quick. So this is a very small example. Just a quick script tag. We wait until the document's ready. We fade out our flash message. We set some custom select drop down menus because you know the browser default one is not good enough for us or whatever. So eventually as this kind of goes on you add more of these like script tags. Things kind of start to collide. You're living in like the global names base in your Java app or your JavaScript in your browser. So things start to conflict or maybe you have like a type on a class name. Things just aren't going super great. So what I've heard commonly referred to as jQuery soup. So to get out of that kind of like soupy mess, which you need to start adding some structure around it. You can incorporate jQuery into this as well. Rails has a new library that's come out recently called stimulus. That also kind of solves this problem. There are some other things that solve this problem too. I think redirect Rails has some data passing help or kind of thing. But yeah this is where you start to reach a point where before you probably weren't like testing any of your JavaScript maybe you had like a system test for it, something like that. At this point things get to be more organized. Maybe you're going to start adding some unit tests for it. And you're going to start like typically the way these things end up working is you end up like putting a lot more data attributes into the DOM. Basically every version of the solution I've seen to this usually involves like tons of data attributes for everything. And so as you start to organize things this can go pretty well. You don't need Webpacker to do this. You have to just be careful in a regular asset pipeline just to make sure you're not like clobbering global variables, that kind of thing. It's pretty risky. If you want to this is also a point where you'd start to add Webpacker and some of those things, enjoy some of those nice ES6 features, get classes, bound methods, that kind of thing. We're going to take a look at this is, I know this is kind of an overwhelming example, but we're going to go through a little bit. This is like a small stimulus controller, I believe is the term. So you can see up at the top here, we have a div and we've just added this data attribute to tell it, oh, the controller is called clipboard. And that kind of corresponds to the name of this file. Stimulus just kind of like works all of this out for us. Then basically we can tell it, oh, we want this input tag to be the source. So we're basically saying we want to save this element and have a reference to it as we're trying to work through. We specify that in our code by matching this name for targets so that way we'll have access to this element. We also have this connect method here. And that basically takes care of like, oh, and this controller kind of launches itself. I'm struggling to avoid using react terms for it. But yeah, when it launches itself, it will basically like, you can do some checking. Here I'm doing some checking to make sure I'm even allowed to do like a copy this into my clipboard kind of thing. If I can do that, we add a class to make sure the button is visible. So that way if we're on an older browser, it kind of fails gracefully. And the last little chunk of this is that we add an actual like function binding to this button. So basically this will execute our copy function just by virtue of that kind of like action magic string up there. And we can like select our target, copy it. And it's all pretty straightforward. Rails will like make all of this work with turbo links. You can just sprinkle these data attributes everywhere or like split them into partials. And things will go pretty well. One downside to this is that you end up with a pretty, I don't know, you end up basically having to like do a lot of work yourself in a lot of ways. You'll probably still want like jQuery in here at this point. Working with like the raw DOM can be pretty difficult in a lot of cases. Especially like differences in browsers and subtle naming conventions, all that kind of thing. So our next step as our team is kind of becoming more advanced with JavaScript is we can add a little bit of JavaScript. Just like a little sprinkle of the framework. So it's just a little taste. This would be for more complicated interactions or more probably more custom interactions. If you don't like say jQuery UI's custom select dropdown, you might write your own little custom dropdown and you can apply that to the page everywhere. And you can also sort of lean into and start kind of practicing with whatever the, I don't know, whatever framework is your particular favorite. For the rest of this talk, most of my examples involving frameworks will involve React because that's what I know and that follows all of my biases. So full disclosure. But typically this kind of sprinkling of the framework just controls part of the page. You're not driving all of your user interaction. Most of what's going on is still happening on the rail side or in ERB or Hamel. So here's another unwieldy example. So this is just like a little common bubble. And all we're doing here is it has a little state. We keep track of our text in here. We have like a function here to save all of our text or save our comment here and some markup to kind of like piece it all together. Down here at the bottom is probably one of the more important parts for a pattern like this is that when you load the page you can just grab everything that fits this class name and then tell React to render into all of these things. So basically you can just name things in your HTML templates and JavaScript magic just kind of starts to happen everywhere. But if you wanted to you could put it into a like a pack tag or something like that and then like just only load that JavaScript for just that one page. There we go. So now we're moving on to framework pages. So a framework page is kind of like the next step in this evolution, right? You end up with more JavaScript interaction gets more complicated. You just need to kind of take over everything. Typically I see this in more of like a, I don't know, this could also be like sort of like a little like widget wizard. Like if you're signing in and you need to fill out a bunch of information you don't want tons of routes cluttering up your Rails app and basically force people to kind of like start over if they fall out, that sort of thing. But you'll have tons of interaction. Your like Rails templates are going to get very sparse and possibly sparse sometimes. But that's okay. You'll be leaning into your framework and at this point like everyone on your team should be a bit more comfortable with that. And maybe you'll even get some client side routing in there if you want to like preserve some like shareable links. Some of those factors start making a bigger difference, especially depending if you're sharing a lot of like content or that kind of thing. So here we have a quick little example up top there. You can see there's a style sheet pack tag, JavaScript pack tag, and a div. This is it for our template. All we need at that point is basically our React component. And we take that and we just grab that wizard div and we just render right into it. And then JavaScript takes it from here. And here we're kind of like rendering like a slideshow and kind of like managing things with the routes inside of it. So it's all pretty, there's a lot of like nuance around like the particulars of like which JavaScript framework you choose. But past a certain point Rails doesn't really care what kind of like JavaScript you're like pushing out into this. You just have to structure it appropriately. And Rails won't get in the way or anything like that. So this is the sixth degree, maybe the last degree. So this is basically where you essentially just have a single page application running inside of your Rails app. All you're doing in here is basically like tons of client side rounding or routing. You get all of the benefits of kind of having like a single page app and some of the drawbacks. But at least you're not complicating your deploy process. So like setting up those extra S3 buckets like if you deploy to Heroku or wherever, all your normal kind of build process will just work out of the box. And this can save you a lot of trouble. And especially to if you end up in a situation which I find for a lot of apps I've worked on is usually be something that's more user facing and more like something more administrative like a CMS, that kind of thing. So here you can actually just kind of like host both of those. So if you do need to share components and that kind of thing between these two things, you don't have to like do a bunch of magic to like build up a monorepo and deploy all of that stuff. You can basically just tell Rails like, hey forward everything from slash admin onward over to this application and just take it from there. And things go pretty smoothly here. I guess her Rails app doesn't actually have any data manipulation going on it, but it has these sweet JavaScript apps. So this is the thrilling conclusion. I tried to like steady myself with all of these like sweet keynote fire animations, but I like couldn't do it. I got to the end and I was like, I need some fire in here. So here we go. So just a quick recap of the six degrees. We have unobtrusive JavaScript. You have jQuery and widgets. You can use structure and stimulus. You can add a little bit of a framework, a bit more of a framework or just go all in on the framework in the context of a Rails application. What is this? Let's see. So you don't have to choose just the six degrees. You can actually do a lot of mixing and matching as long as you're careful to do things right. Like just make one page run a framework, another page just uses the regular kind of unobtrusive JS. So that way you can have like different people with different skill sets kind of like working in their lane and working ideally pairing with people to kind of like spread that knowledge around and get it to other people. But they can also still work in the rest of the application very like self-sufficiently. And as far as like the risks go, I mean, it's really just have to be careful in your like route file. Like if you're forwarding requests, you can end up with a lot of things where like I didn't mean to go here, but for the most part you'll be fine. So I've put together a little list of resources here. First off DevMind.com, we have blog posts, all that kind of thing. So that's our plug. Aside from that, you can check out unobtrusive JavaScript, learn more about jQuery or Stimulus and Webpacker. And there, as always, there's tons of React and Angular docs, all that kind of good stuff. After we wrap up here, I'm gonna be available up here for questions and comments if you want to talk to me. Like I don't know what we're quite set up for that like microphone thing. So just come talk to me and yeah, just say hi if you want to. So that's the end. Where is it?