Gain insights into building applications using Rails Webpacker, Webpack, and TypeScript. Explore Stimulus, React, state management, and communication with servers for richer interactions.

railspostgresssl.tar.gz

introduction/01

introduction/02

introduction/03

introduction/04

introduction/05

introduction/06

stimulus/01

stimulus/02

stimulus/03

stimulus/04

stimulus/05

stimulus/06

react/01

react/02

react/03

react/04

css/01

css/02

css/03

server/01

server/02

server/03

server/04

server/05

server/06

state/01

state/02

state/03

state/04

state/05

state/06

adv_types/01

adv_types/02

adv_types/03

testing/01

testing/03

all_stimulus/01

all_react/01

introduction/01_testing

testJob

introduction/01-copy

introduction/02-copy

introduction/03-copy

introduction/04-copy

introduction/05-copy

introduction/06-copy

stimulus/01-copy

stimulus/02-copy

stimulus/03-copy

stimulus/04-copy

stimulus/05-copy

stimulus/06-copy

react/01-copy

react/02-copy

react/03-copy

react/04-copy

css/01-copy

css/02-copy

css/03-copy

server/01-copy

server/02-copy

server/03-copy

server/04-copy

server/05-copy

server/06-copy

state/01-copy

state/02-copy

state/03-copy

state/04-copy

state/05-copy

state/06-copy

adv_types/01-copy

adv_types/02-copy

adv_types/03-copy

all_stimulus/01-copy

introduction/01-copy-r0guf3

react/02-copy-copy

In this course, you will learn to build a fully-functional application with Rails Webpacker, Webpack, and TypeScript.

To kick things off, you’ll walk through the basics of getting Rails set up to use Webpacker which will serve JavaScript and CSS to the browser. You’ll then get acquainted with Stimulus and React which will help with creating richer interactions.

In the latter half, you’ll work with TypeScript and set up communication between a server. Beyond that, you’ll work through managing state in your Stimulus code, as well as how to test and troubleshoot your application.

By the end of this course, you will be well equipped to create larger, more complex applications that make use of modern tools.

Modern Front-end Development for Rails

If you’ve looked at the schedule page in your browser, you'll see a button next to each day in the schedule labeled “Hide.” Clicking on it does nothing---yet. 
# Toggling the state with TypeScript

If you've looked at the markup for that page in `app/views/schedule/show.html.erb`, you'll see an `each` loop for each day in the schedule. A few lines into that loop, you’ll see a button with the "Hide" text. I've marked up the appropriate DOM elements with some CSS classes that we'll use in the TypeScript code:



The code sample is in the `/usercode` directory (run the executable at the bottom of the page to find it), and if you compare it with the previous set of code in the last few lessons, you'll see some changes that I'm not going to cover here in-depth. Specifically, I've added the [ESLint](https://eslint.org/) code cleanup tool and the [Prettier](https://prettier.io/) code formatter to help keep the code clean as I write it.

I’ve changed the name of the file `app/javascripts/packs/application.js`, to `app/javascripts/packs/application.ts` changing the file extension so that Webpacker will treat it as a TypeScript file. 

The existing code in that file needs to be slightly modified for TypeScript. Specifically, the existing code uses `require` to load modules, and I've configured TypeScript not to allow that, so I've changed them all to use `import`. I'll go into more detail on module importing in the [TypeScript Chapter](https://www.educative.io/courses/modern-front-end-rails/introduction-to-typesscript).

I've also written all the code we need for this show/hide toggle inside the `application.ts` file, which is not great practice as the code gets bigger, but is fine for now because it means we don't need to deal with further module importing.

Here's the code I've written to do this toggle, using no framework, just TypeScript and the standard Document Object Model (DOM) library:



import * as ActiveStorage from "@rails/activestorage" 
import Rails from "@rails/ujs"
import * as Channels from "channels"
import Turbolinks from "turbolinks" 

Rails.start()
Turbolinks.start()
ActiveStorage.start()

class DayToggle {
  day: HTMLElement
  dayButton: HTMLElement
  dayText: HTMLElement
  buttonText: HTMLElement

  constructor(day: HTMLElement) {
    this.day = day
    this.dayButton = this.day.querySelector(".js--day-button")
    this.dayText = this.day.querySelector(".js--day-text")
    this.buttonText = this.day.querySelector(".js--button-text")
  }

  initHandlers(): void {
    this.onFilterButtonClick()
  }

  isHidden(): boolean {
    return this.dayText.classList.contains("is-hidden")
  }

  onFilterButtonClick(): void {
    this.dayButton.addEventListener("click", () => {
      this.dayText.classList.toggle("is-hidden")
      this.setText()
    })
  }

  setText(): void {
    this.buttonText.innerText = this.isHidden() ? "Show" : "Hide"
  }
  // 
}

document.addEventListener("turbolinks:load", () => {
  document.querySelectorAll(".js--day").forEach((element) => {
    new DayToggle(element as HTMLElement).initHandlers()
  })
})




Let's go through this in some detail.

At the beginning of the file, we handle the libraries that are part of Rails itself that help Rails do its standard client-side things. 


We've got four libraries here:

- `@rails/activestorage`---ActiveStorage is the new-ish Rails library that handles file uploads. This library provides client-side support for upload-related activities. We're not going to be dealing with it in this course after this sentence ends.

- `@rails/ujs`---UJS stands for Unobtrusive JavaScript, which was a big buzzword phrase about JavaScript development in about 2007. Somewhat oversimplified, "unobtrusive" relates to the practice of putting event handlers in separate JavaScript files rather than putting them directly in the HTML markup. At one time, this practice was uncommon; now it's ubiquitous. The Rails UJS library dates back to when Rails started to structure its normal client-side activities using unobtrusive principles. This library provides what you'd think of as normal Rails behavior, like Ajax calls when `data-remote` is true, or alert boxes when `data-confirm` has a value. This library has one or two utilities we will use, but otherwise, we won't be talking about it much.

- `channels`---Channels is the client-side portion of the ActionCable web sockets framework. You'll see this in action later in the [Talking to the Server](https://www.educative.io/courses/modern-front-end-rails/introduction-to-talking-to-the-server) section when I show you how to use web sockets and ActionCable to send information from the server to the live browser.

- `turbolinks`---Ah, Turbolinks. Turbolinks is a default part of Rails that is designed to improve the perceived responsiveness of the app from the user's perspective. The basic idea is that Turbolinks automatically intercepts new page links, taking only the part inside the `body` tag and replacing the existing `body` tag rather than triggering an entire page refresh. This prevents the user from seeing a page flicker. Turbolinks is somewhat controversial---many JavaScript developers don't like it, in part because it can change the expected behavior of page loading that other libraries might depend on. We'll keep it for now.

Once those libraries are loaded and started as needed, I've put the toggle logic in a class called `DayToggle`.  For the record, there are most definitely other ways to structure this code. For example, you could do it as just one nested function. I happen to like using classes.

If you are familiar with JavaScript but not TypeScript, this will look about 95% correct. There are only two sets of additions that are there for TypeScript. At the top of the class, you see three declarations that look like `day: HTMLElement`. Here they are:

```
class DayToggle {
  day: HTMLElement
  dayButton: HTMLElement
  dayText: HTMLElement
  buttonText: HTMLElement
```

These lines declare what the properties of the class are and what type they are. If I attempt to invoke a property of a class that's either not defined in this list or is a method in the class body, such as `this.banana`, TypeScript will flag that nonexistent property and won't compile. Further, if I attempt to use one of the properties I have declared but call a nonexistent property on them, such as `this.filterButton.flavor`, TypeScript will also flag that as an error.

The other TypeScript specific addition is the `: TYPE` after every function argument or as part of every function definition. These annotations, such as `constructor(day: HTMLElement)` or `isHidden(): boolean`,  similarly specify the expected type of the argument or the return value of the function. TypeScript also takes this information into consideration when compiling the code, and checks that the declared type of the value matches the usage. 

We'll discuss TypeScript in earnest in the [ TypeScript chapter](https://www.educative.io/courses/modern-front-end-rails/introduction-to-typesscript). In general, TypeScript annotates variable declarations, function parameters, and function return values with type information. 

If you have an IDE that is TypeScript aware, such as Visual Studio Code, the IDE will immediately make you aware of the type errors as you write. 

If you are looking at the current code, it's probably also warning you that we don't have type definitions for the Rails libraries that we are invoking. These descriptions allow us to use TypeScript types for the classes and structures in those libraries. We don't need these descriptions right now, because we aren't using the libraries, and TypeScript is lenient about types that aren't defined to allow it to interoperate with existing JavaScript libraries.  We'll also deal with that later.



Moving on to the rest of the code, the class definition has a `constructor`: 

```
  constructor(day: HTMLElement) {
    this.day = day
    this.dayButton = this.day.querySelector(".js--day-button")
    this.dayText = this.day.querySelector(".js--day-text")
    this.buttonText = this.day.querySelector(".js--button-text")
  }
```

The constructor is automatically called when a new instance of the class is created. The constructor takes one argument: an HTML element representing the entire day's text. Inside the constructor, we set the properties of the class to DOM elements based on known DOM classes in the code: we have one for the button, one for the section of the page we want to show and hide, and one for the element containing the button text.

The `onFilterButtonClick` method is repeated here.

```
  onFilterButtonClick(): void {
    this.dayButton.addEventListener("click", () => {
      this.dayText.classList.toggle("is-hidden")
      this.setText()
    })
  }
```

This method uses `addEventListener` to listen for `click` events on the button. When it receives one, it uses existing DOM methods to toggle the `is-hidden` state of the filters, and then adjusts the text of the button based on the whether the item has been shown or hidden.

# Loading page with Turbolinks

At the end of the class definition, we use the `document.addEventListener` method to catch the `turbolinks:load` event: 

```
document.addEventListener("turbolinks:load", () => {
  document.querySelectorAll(".js--day").forEach((element) => {
    new DayToggle(element as HTMLElement).initHandlers()
  })
})
```

That event signifies that the page has loaded and code that depends on specific DOM elements can run. 

Inside that event handler, we look for all of our day blocks in the DOM and instantiate a toggle instance for each one.

In a non-Turbolinks application, we'd listen for the `DOMContentLoaded` event, but Turbolinks handles page loads such that if we navigate away from this page and then come back, it does not re-trigger `DOMContentLoaded`, so our listener would not be re-run.

Here's the full sequence of events:

- Webpacker compiles our TypeScript code into JavaScript. In development, this happens when we load the page, but in production, the compilation would typically be handled when the code is deployed.
- The resulting JavaScript is sent into the browser on page load, creating the class, and the event handler for the `turbolinks:load` event.
- When the page finishes loading, the `turbolinks:load` event handler is fired, and we instantiate the instances of our class. As part of that creation, we attach a click event handler to our button.
- When the button is clicked, the handler is invoked, which changes the visibility state of our filters and the icon.

That's okay for a few lines of code, but the general behavior here---click something have something else show up or hide---is not exactly uncommon. 


For example, we might want the ability for the concerts to show/hide by clicking their dates in the calendar at the top of the page. As we load the page, all the dates are visible, but if a user clicks on one of the dates, let's hide that date. The actual desired user behavior is a little more complex, but we'll get there.

Try out the application below!


Adding Real Features

Getting Started

Client-side Rails

Stimulus

React

Cascading Style Sheets

TypeScript

Webpack

Webpacker

Talking to the Server

Managing State in Stimulus Code

Managing State in React

Using Redux to Manage State

Validating Code with Advanced TypeScript

Testing with Cypress

More Testing and Troubleshooting Basics

Appendix

Adding Real Features

Toggling the state with TypeScript