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

## Current issues

While there's a lot to like about the previous solution, it has a couple of issues that, while not necessarily a problem at this size, might become a problem if the code gets more complex. For example:

* Each individual action needs to know to call `calendarFilterChanged` to trigger a refresh.
* The actual state is global and mutable, which means if some piece of code grabs the data and starts writing it, that change is made to everybody else, whether we want it to or not.

## Refactoring 
In order to prevent these problems, we're going to refactor this central data using a common JavaScript pattern called a *reducer* and a related structure called a *store*. 

A reducer is a JavaScript function that takes two arguments. The first argument is an object representing a state. The second argument represents an action to take. The return value is a new state object representing the state of the data after the action is performed. The action is meant to describe the state change in terms of application logic, while the reducer converts that to changes in data.

Let's look at a simple example, in which we  will count American coins. The state of the world is the number of coins and the total value of the coins. A reducer to partially handle this task might look like this (we'll talk about TypeScript annotations to this in a moment):

~~~typescript
const initialState = {count: 0, value: 0}

const reducer = (state, action) {
  switch (action.type) {
	  case "AddPenny": {
	    return { count: state.count + 1, value: state.value + 1 }
    }
    case "AddNickel": {
	    return { count: state.count + 1, value: state.value + 5 }
    } 
    // and so on...
  }
}   
~~~

Then, you'd call this method with something like:

~~~typescript
const withAPenny = reducer(initialState, {type: "AddPenny"}) 
const pennyAndNickel = reducer(withAPenny, {type: "AddNickel"})
~~~

The idea is that you only change the state via the reducer function. Each call to the reducer function returns a new instance of the state object that is separate from all of the other instances. 

This is somewhat more verbose than, you know, not doing this kind of change as a reducer, which obviously raises the question of why use this structure at all? To be perfectly honest, this is a case where my own taste in software structures clashes a little bit. I find this pattern, as typically implemented in JavaScript, to be a little verbose.

That said, the basic idea of making the central state immutable and only accessible via specific methods is still a good one, and we'll stick with talking about the pattern, as you are most likely to see it in other JavaScript code. 




# Current issues

While there's a lot to like about the previous solution, it has a couple of issues that, while not necessarily a problem at this size, might become a problem if the code gets more complex. For example:

* Each individual action needs to know to call `calendarFilterChanged` to trigger a refresh.
* The actual state is global and mutable, which means if some piece of code grabs the data and starts writing it, that change is made to everybody else, whether we want it to or not.

# Refactoring 
In order to prevent these problems, we're going to refactor this central data using a common JavaScript pattern called a *reducer* and a related structure called a *store*. 

A reducer is a JavaScript function that takes two arguments. The first argument is an object representing a state. The second argument represents an action to take. The return value is a new state object representing the state of the data after the action is performed. The action is meant to describe the state change in terms of application logic, while the reducer converts that to changes in data.

Let's look at a simple example, in which we  will count American coins. The state of the world is the number of coins and the total value of the coins. A reducer to partially handle this task might look like this (we'll talk about TypeScript annotations to this in a moment):

~~~typescript
const initialState = {count: 0, value: 0}

const reducer = (state, action) {
  switch (action.type) {
	  case "AddPenny": {
	    return { count: state.count + 1, value: state.value + 1 }
    }
    case "AddNickel": {
	    return { count: state.count + 1, value: state.value + 5 }
    } 
    // and so on...
  }
}   
~~~

Then, you'd call this method with something like:

~~~typescript
const withAPenny = reducer(initialState, {type: "AddPenny"}) 
const pennyAndNickel = reducer(withAPenny, {type: "AddNickel"})
~~~

The idea is that you only change the state via the reducer function. Each call to the reducer function returns a new instance of the state object that is separate from all of the other instances. 

This is somewhat more verbose than, you know, not doing this kind of change as a reducer, which obviously raises the question of why use this structure at all? To be perfectly honest, this is a case where my own taste in software structures clashes a little bit. I find this pattern, as typically implemented in JavaScript, to be a little verbose.

That said, the basic idea of making the central state immutable and only accessible via specific methods is still a good one, and we'll stick with talking about the pattern, as you are most likely to see it in other JavaScript code. 




Let's start refactoring to the reducer pattern in this lesson.

Refactoring to the Reducer Pattern

Getting Started

Client-side Rails

Stimulus

React

Book Review System Using ReactJS and Ruby on Rails

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

Refactoring to the Reducer Pattern

Current issues

Refactoring