DEV Community: Cody Barker

Simplify Async State Management with Redux Toolkit

Cody Barker — Tue, 03 Oct 2023 20:00:19 +0000

If you have any experience with Redux, you might be familiar with Redux Toolkit. Redux Toolkit aims to simplify some of the setup for the store and reducers, and simplifies immutable update logic. Although Redux requires a significant amount of boilerplate code, Redux Toolkit makes it easier to get up and running. If you haven't used Redux Toolkit before, I'd recommend giving it a shot.

Installing Redux Toolkit

To begin, install Redux Toolkit in your project directory.

npm install @reduxjs/toolkit

Configuring the Store

The store is an essential part of Redux. The store is where your application's state will be stored and managed. Now that we've installed Redux Toolkit, let's initialize the store. Create a file called store.js in the client directory of your project.

Let's configure the store like so:

// store.js
import { configureStore } from '@reduxjs/toolkit';
import usersReducer from './usersSlice';

const store = configureStore({
  reducer: {
    users: usersReducer
  },
});

export default store;

We are going to be creating and importing some reducers, and adding them to the reducer object in our store. Using configureStore allows us to combine multiple reducers in a single store.

Creating the Users Slice

In Redux Toolkit, slices are small, self-contained pieces of your Redux store that include reducers, actions, and async thunks. Create a new file called usersSlice.js and define your usersSlice:

import { createAsyncThunk, createSlice } from "@reduxjs/toolkit"

//Reducer
const usersSlice = createSlice({
    name: "users",
    initialState: {
        status: "idle",
        entities: [],
        errors: []
    },
    reducers: {},
    extraReducers: {},
)

export default usersSlice.reducer;

Let's break this down a little bit. First, we are importing createAsyncThunk and createSlice. createAsyncThunk will allow us to create functions that can dispatch actions (thunks) throughout our app in order to update state. createSlice will allow us to create our usersSlice, which is home to our initial state and reducers, thereby responsible for maintaining and updating our User state.

Creating Async Actions

Now that we have our usersSlice setup, let's create our first thunk. When the app loads or a user signs in, we might want to fetch all of the user objects from our database. To do that, we need to first define a thunk like so:

import { createAsyncThunk, createSlice } from "@reduxjs/toolkit"

export const fetchUsers = createAsyncThunk("users/fetchUsers", () => {
    return fetch("/users")
    .then((r) =>r.json())
})

//Reducer
const usersSlice = createSlice({
    name: "users",
    initialState: {
        status: "idle",
        entities: [],
        errors: []
    },
    reducers: {},
    extraReducers: {},
)

export default usersSlice.reducer;

Here, we created an action called fetchUsers, which is an async thunk. This thunk makes a fetch GET request to our proxy of "/users", and returns a response.

Creating Extra Reducers

To make updates to state with the response from our thunk, we need to create some cases for extraReducers.

These cases look for the action type ("users/fetchUsers"), and whether that action is currently pending, fulfilled, or rejected. Depending on the case, we can update state accordingly. Let's update our usersSlice to look like this:

import { createAsyncThunk, createSlice } from "@reduxjs/toolkit"

export const fetchUsers = createAsyncThunk("users/fetchUsers", () => {
    return fetch("/users")
    .then((r) =>r.json())
})

//Reducer
const usersSlice = createSlice({
    name: "users",
    initialState: {
        status: "idle",
        entities: [],
        errors: []
    },
    reducers: {},
    extraReducers: (builder) => {
    builder
    //fetchUsers
        .addCase(fetchUsers.pending, (state) => {
            state.status = 'pending';
          })
          .addCase(fetchUsers.fulfilled, (state, action) => {
            state.status = 'fulfilled';
            state.entities = action.payload;
          })
          .addCase(fetchUsers.rejected, (state, action) => {
            state.status = 'rejected';
            state.errors = action.error.message;
          });
    },
)

export default usersSlice.reducer;

Here we've added 3 cases to the builder object which defines our reducers. State updates happen asynchronously when we make fetches to the database, so when the fetchUsers thunk is first dispatched, it enters a pending state, so we change our initial status to pending. If the request is successful, fetchUsers.fulfilled will run, thereby changing status to fulfilled and our entities array to the action.payload (an array of User objects returned from the database). If the request is unsuccessful, the rejected case will run, changing status to rejected and errors to action.error.message, which we can render to the page.

Connecting Redux to React

To connect the Redux store to a React app, use the Provider component from react-redux. Wrap the app with the provider in the index.js file, and pass it the store as a prop:

import ReactDOM from 'react-dom/client';
import App from './App';
import { Provider } from "react-redux";
import store from "./store"

const root = ReactDOM.createRoot(document.getElementById('root'));
root.render(
   <Provider store={store}>
       <App />
   </Provider>
);

Using Redux Toolkit in Components

Now that we have set up Redux Toolkit and the usersSlice, we can start using it in our React components.

Fetching Users

To fetch users in a component, import the fetchUsers async thunk and use the useDispatch hook to dispatch the action:

// UserList.js
import { useEffect } from 'react';
import { useDispatch, useSelector } from 'react-redux';
import { fetchUsers } from './usersSlice';

const UserList = () => {
  const dispatch = useDispatch();
  const users = useSelector((state) => state.users.entities);
  const status = useSelector((state) => state.users.status);
  const errors = useSelector((state) => state.users.errors);

  useEffect(() => {
    dispatch(fetchUsers());
  }, [dispatch]);

  if (status === 'pending') {
    return <div>Loading...</div>;
  }

  if (errors) {
    return <div>Error: {error}</div>;
  }

  return (
    <div>
      <h2>User List</h2>
      <ul>
        {users.map((user) => (
          <li key={user.id}>{user.name}</li>
        ))}
      </ul>
    </div>
  );
};

export default UserList;

Here we are importing useEffect in order to dispatch our fetchUsers thunk/action when the app loads. We add dispatch to the dependencies array to prevent some error warnings.

We are also importing useDispath and useSelector. useDispatch allows us to dispatch thunks from our slices. useSelector allows us access to our slices' state, and it subscribes the component to that piece of state, so whenever it changes, the component will rerender with the state update.

As you can see, we are conditionally rendering on whether the fetch has completed or returned an error. Upon successful fulfillment, we fetch the user objects and map over them to render a list of user names to the page.

Conclusion

Redux Toolkit, with its createAsyncThunk utility, simplifies handling asynchronous updates in your Redux application. By following the steps outlined in this article, you can create a "users" slice that efficiently fetches user data from an API and updates the state based on the fetch status.

With Redux Toolkit, you can focus on building features and user interfaces without getting bogged down by repetitive async action handling code. It's a valuable tool for streamlining your Redux development and ensuring smooth user experiences when dealing with async data.

In this article, we've explored how to use Redux Toolkit to manage asynchronous updates in a Redux store, specifically focusing on a "users" slice that fetches user data from an API. By following these steps, you can simplify the process of handling async actions and keep your Redux codebase clean and efficient.

How to Render Custom JSON Responses with Active Model Serializer

Cody Barker — Wed, 26 Jul 2023 19:00:43 +0000

ActiveModel::Serializer is a ruby gem that gives us the ability to customize the JSON responses we get from our controllers. This gem simplifies passing data from custom methods in our models, allows us to use our belongs_to and has_many macros to pass associated data, and even allows us to send different responses depending on the controller action triggered.

Installing AMS

To get started, we first need to add the gem to our Gemfile

# Gemfile
gem 'active_model_serializers'

Then run bundle i to install the gem.

Using AMS

AMS comes with a generator which is great! In order to create a serializer for an example User model, run:

rails g serializer user

AMS relies on 'convention over configuration', so when creating serializers, make sure their names are singular to match their model names.

We can find our new UserSerializer in the app/serializers directory.

Our new serializer might look something like this:

class UserSerializer < ActiveModel::Serializer
    attributes :id

end

In order to customize the JSON response for a user, we can add or subtract any user attributes we like. For example:

class UserSerializer < ActiveModel::Serializer
    attributes: :id, :username, :city, :state

end

AMS also makes it simple to pass data from custom methods in our models. Say we want to pass the total number of users. We could go to our User model and create a custom instance method to do that like so:

class User < ApplicationRecord

    def num_of_trails
        self.trails.count
    end

end

Then we simply go back to our UserSerializer and add our custom method to the list of attributes.

class UserSerializer < ActiveModel::Serializer
    attributes: :id, :username, :city, :state, :num_of_trails

end

That's it! Now our JSON response will include a user object with a property called num_of_trails.

Rendering Associated Data

So long as we have set up the correct Active Record associations in our models using belongs_to, has_many and has_many through macros, we can also include associated data in our user response by using those macros as well. For example, if a user has_many :reviews and also has_many :trails, through: :reviews, we can simply say a user has_many :trails and AMS will know what to do because of the has_many through macro in our model. The following would return a JSON object for the user with the attributes listed, as well as properties of reviews and trails, each of which would include an array of their corresponding associated objects.

class UserSerializer < ActiveModel::Serializer
    attributes: :id, :username, :city, :state
    has_many :reviews
    has_many :trails

end

All of this avoids having to call .to_json in our controller actions, and the complicated nesting that comes with defining what to include in that response.

When we want to return different JSON responses depending on the controller action that is triggered, we can create custom serializers that don't follow the typical Rails naming convention.

To do this, we need to create a new file in app/serializers. In this case, let's create one called user_trail_serializer.rb, and then move our custom num_of_trails method from our User model into this serializer. It's important to note that when calling self in the serializer, the serializer will return an object, so from that object, we want to call trails.count as follows:

class UserTrailSerializer < ActiveModel::Serializer
  attributes :num_of_trails

  def num_of_trails
    self.object.trails.count
  end

end

To use our num_of_trails method, we need a new route in routes.rb

get '/users/:id/num_of_trails', to: 'users#num_of_trails'

Then we need to add a num_of_trails action to our UsersController like so:

# app/controllers/users_controller.rb
def num_of_trails
    user = User.find(params[:id])
    render json: user, serializer: UserTrailSerializer
end

Now if you were to navigate to localhost:3000/users/1/num_of_trails, you would see an object with a num_of_trails property and the corresponding value. For example:

{
    "num_of_trails": 4
}

If instead of returning the num_of_trails for a single user, we wanted to return an array of the counts for all users, we would need to create another route and action to do so.

# config/routes.rb
get '/user_trail_counts', to: 'users#user_trail_counts'

# app/controllers/users_controller.rb
def user_trail_counts
    users = User.all
    render json: users, each_serializer: UserTrailSerializer
end

By using each_serializer: UserTrailSerializer, we're telling the action to use our UserTrailSerializer to render each of the users instead of our default UserSerializer.

By adding the :username attribute to our user__trail_serializer.rb file, we'll get an array of objects like this when visitng localhost:3000/user_trail_counts:

[
  {
    "username": "codybarker",
    "num_of_trails": 3
  },
  {
    "username": "kelliradwanski",
    "num_of_trails": 3
  },
  {
    "username": "benbuckingham",
    "num_of_trails": 3
  },
  {
    "username": "marvin",
    "num_of_trails": 0
  }
]

We can also customize the JSON rendered from our associations, by creating and specifying custom serializers for our association macros. In our custom CustomTrailSerializer below, we could include whatever custom methods or attributes we'd like to render.

class UserSerializer < ActiveModel::Serializer
    attributes: :id, :username, :city, :state

    has_many :reviews
    has_many :trails, serializer: CustomTrailSerializer

end

AMS is a wonderful gem that allows us to maintain separation of concerns, simplify the process of rendering data, and keep our code clean and readable for others, while you focus on what matters.

File Structure Basics for a Ruby API

Cody Barker — Mon, 01 May 2023 22:01:40 +0000

Are you excited to create your own back-end using Ruby, but overwhelmed with the myriad files and folders required to get it up and running? You're not alone, as many new developers feel the same when trying to setup their own API for the first time. The typical file structure contains many files and folders, and it can be a challenge to remember what exactly each of them is responsible for. With so many gems available, it can be difficult to know just which ones to choose for your project. In this guide, I'll walk you through the basic file structure and boilerplate code necessary to get your server working, so you can connect to a front-end for a full-stack application.

To begin, let's first take a look at the general file structure of a Ruby server. While most servers will have some additional files and complexity, we're going to build ours using the Active Record, Sinatra, SQLite3 and Rake gems to keep things simple and efficient. We'll also be using Ruby 2.7.4 for this guide as it works with the gem versions defined in the Gemfile.

Basic File Structure

▾server
   ▾app
     ▸controllers
     ▸models
  ▾config
    database.yml
    environment.rb
  ▾db
    ▾migrate
       migration files
       schema.rb
       seeds.rb
  Config.ru
  Gemfile
  Rakefile

Server

We'll start with a root "server" folder so we can keep the front-end and back-end separate in our app. You can name this whatever you like.

Gemfile

Before we dive into the rest of the file structure, let's take a look at what we're going to include in our Gemfile. The Gemfile will contain all of the gems we intend to use, which will give us some context as we continue building out our back-end. Perhaps the two most important gems we'll be using are Active Record and Sinatra. Active Record contains a number of built-in methods for creating and managing our databases. It also helps us make the correct associations between our classes and our databases by following "convention over configuration." So long as we follow the proper conventions in Active Record, we can dramatically reduce the amount of code needed to hook everything up. Sinatra simplifies the dynamic routing of our controllers so that it becomes easy to handle CRUD operations from client requests, and partners with Active Record to update our databases.

To create the Gemfile, enter "bundle init" in the terminal in your project directory. For the sake of this guide, we'll be using the following gems:

You may also need to install SQLite3 via WSL on Windows or Homebrew on OSX.

For WSL Users: in the terminal, enter "sudo apt install sqlite3".

For OSX Users: If you have Homebrew installed, you can simply enter "brew install sqlite".

source "https://rubygems.org"

# Facilitates the dynamic routing and CRUD of our controllers
# https://github.com/sinatra/sinatra
gem "sinatra", "~> 2.1"

# A fast and simple web server
# https://github.com/macournoyer/thin
gem "thin", "~> 1.8"

# Parses the body of requests into params for use in controllers
# https://github.com/rack/rack-contrib
gem "rack-contrib", "~> 2.3"

# Allows us to load resources from foreign servers     
# https://github.com/cyu/rack-cors
gem "rack-cors", "~> 1.1"

# An object-relational mapper which streamlines database mgmt. 
# Utilized primarily in our database and models folders.
# https://guides.rubyonrails.org/active_record_basics.html
gem "activerecord", "~> 6.1"

# Configures common Rake tasks for working with Active Record
# https://github.com/sinatra-activerecord/sinatra-activerecord
gem "sinatra-activerecord", "~> 2.0"

# Helps us run common tasks from the command line
# https://github.com/ruby/rake
gem "rake", "~> 13.0"

# Allows us to interact with our SQLite3 databases
gem "sqlite3", "~> 1.4"

# Require all files in a folder
gem "require_all", "~> 3.0"

# These gems will only be used locally
# "pry" will allow us to enter the console
# "rerun" will automatically reload the server whenever it changes 
group :development do
  gem "pry", "~> 0.14.1"

  # https://github.com/alexch/rerun
  gem "rerun"

# These gems will only be used when if/when running tests
group :test do
  gem "database_cleaner", "~> 2.0"
  gem "rack-test", "~> 1.1"
  gem "rspec", "~> 3.10"
  gem "rspec-json_expectations", "~> 2.2"
end

App

Our first child folder will be called "app", which will house our "controllers" and "models" folders. We'll follow the Model, View, Controller concept and separate our controllers and models. To learn more about MVC, checkout this resource.

Models

Our "models" folder will house our "model" files. These are ruby files that house the classes we intend to use to represent our real life data. These model names must follow a few important conventions to work properly with Active Record.

The model name must ALWAYS be singular, so that it can associate correctly to pluralized tables in the database. For example, if we create a "messages" table in our database, we must name our corresponding model file "message.rb" with a class of "Message" that inherits "ActiveRecord::Base".
Keep the file name lower-cased and snake_cased.
Keep the model class name PascalCased.

At it's most basic, an example message.rb model file would look like this.

class Message < ActiveRecord::Base
end

Controllers

Within our controllers folder, we might have one or more controller files. If using just one for a simple app, it's fine to name it something like "application_controller.rb". This file will handle the dynamic routing for server requests and should be defined as a class which inherits "Sinatra::Base". Since we'll be handling JSON data with the controller, we'll set the default content type to 'application/json'. The controller will have CRUD methods for handling client requests to a resource in our database (a plural table name associated with its singular model name) and might look a little something like this.

class ApplicationController < Sinatra::Base
  set :default_content_type, 'application/json'

  get '/messages' do
    messages = Message.all
    messages.to_json
  end

  post '/messages' do
    message = Message.create(
      body: params[:body],
      username: params[:username]
    )
    message.to_json
  end

  patch '/messages/:id' do
    message = Message.find(params[:id])
    message.update(
      body: params[:body]
    )
    message.to_json
  end

  delete '/messages/:id' do
    message = Message.find(params[:id])
    message.destroy
    message.to_json
  end

end

Config

Note this is the folder, not the config.ru file, which we'll get to. This config folder contains two files, "database.yml" and "environment.rb".

database.yml

The database.yml file is where we set up our connection between Active Record and the database. In our case, it relies on the sqlite3 gem to act as our default adapter. We'll use just a little bit of code to set this up. Pool handles the number of connections to be made with the database and the timeout sets how long too wait before attempting to reconnect to the database. The important thing here is that our adapter is set to sqlite3 and the database paths are matched to the correct environments.

default: &default
  adapter: sqlite3
  pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %>
  timeout: 5000

development:
  <<: *default
  database: db/development.sqlite3

test:
  <<: *default
  database: db/test.sqlite3

production:
  <<: *default
  database: db/production.sqlite3

environment.rb

This file is responsible for requiring in our gems and all of the files in our app directory. It's also responsible for creating the environment variable used by our rake tasks to determine whether we're in our development, test, or production environment. It looks like this.

#creates the environment variable for "rake"
ENV['RACK_ENV'] ||= "development"

#requires our gems
require 'bundler/setup'
Bundler.require(:default, ENV['RACK_ENV'])

#requires all the files in our 'app' directory
require_all 'app'

config.ru

Note that this file is NOT in our config folder. It lives in the top directory, as a child of our "server" folder. This file is responsible for requiring the environment file we just created, as well as configuring our Rack commands when our application runs, hence the .ru file extension for "rackup". I know these config files might be a bit confusing, but if you set it up this way, you'll be just fine.

require_relative "./config/environment"

# allow CORS requests
use Rack::Cors do
  allow do
    origins '*' #change origin to your own when deploying!
    resource '*', headers: :any, methods: 
      [:get, :post, :delete, :put, :patch, :options, :head]
  end
end

# parses JSON data from the body of requests into the params hash
use Rack::JSONBodyParser

# our application
run ApplicationController

Rakefile

Rake is a gem that will help us run common tasks from the command line. The Rakefile is where we will define those tasks so we can easily start our server, set which port we want it to run on, and access the console whenever needed. It will also require the environment file we just created, and rake from /sinatra/activerecord/rake to work.

require_relative "./config/environment"
require "sinatra/activerecord/rake"

desc "Start the server"
task :server do  
  if ActiveRecord::Base.connection.migration_context.needs_migration?
    puts "Migrations pending. Run `rake db:migrate` first."
    return
  end

  # rackup -p PORT will run on the port specified (9292 by default)
  ENV["PORT"] ||= "9292"
  rackup = "rackup -p #{ENV['PORT']}"

  # rerun auto-reloads the server when files are updated
  # -b runs in the background (include this or binding.pry won't work)
  exec "bundle exec rerun -b '#{rackup}'"
end

desc "Start the console"
task :console do
  ActiveRecord::Base.logger = Logger.new(STDOUT)
  Pry.start
end

db

At long last, our database folder. This folder is home to our migrations, schema file, and seed file.

migrate

We're using SQLite3 and Active Record to create and interact with our database. All of our migrations will be housed in this folder. Whenever we create a new migration, say to add a new table, to change a column title, or to drop a table, it will be created within this directory. Migrations allow us to easily keep track of our database changes, rollback any changes, recover data that was previously deleted, and work with the same database structure across teams of engineers. Migrations are great!

Our migration files should always be created from the command line, using rake, so they are correctly timestamped and tracked. It's also a good idea to call them with "bundle exec rake" to avoid any errors.

To create our "messages" table, we would run the following in our CLI:

bundle exec rake db:create_migration NAME=create_messages

It's important to leave the migration file name and class name alone. If you start messing with either of them, it can cause problems. In order to create our "messages" table, we might have a migration file that looks something like this:

class CreateMessages < ActiveRecord::Migration[6.1]
  def change
    create_table :messages do |t|
      t.string :body
      t.string :username
      t.timestamps
    end
  end
end

Here we're creating a table called "messages" (note the pluralization), with column names of "body" and "username" which will both accept strings of data, and timestamps (for when the data was created and when it was last updated). If we followed the conventions as outlined in the section on models, this table will correctly associate with our "message" model.

schema.rb

Our schema file will be automatically generated with our first migration, and it will show us the current "schema" or structure of our database. To make our first migration, in the CLI we'll run:

bundle exec rake db:migrate

Our schema file should now look a little something like this:

ActiveRecord::Schema.define(version: 2023_04_28_193159) do

  create_table "messages", force: :cascade do |t|
    t.string "body"
    t.string "username"
    t.datetime "created_at", precision: 6, null: false
    t.datetime "updated_at", precision: 6, null: false
  end

end

Any time we rollback migrations, or create new migrations and migrate from the CLI, this file will update. This is how developers keep track of the database structure to ensure they're all in sync.

seeds.rb

Our seeds.rb file is where we can create dummy data to fill our database for testing. It's helpful for teams to use the seeds file because it provides the template for generating new testing data, quickly and efficiently. I'd recommend looking into using the Faker gem and loops for creating all sorts of useful, seed data in larger volumes, but for simplicity's sake we'll hard code a few messages here.

puts "🌱 Seeding messages..."

Message.create([
  {
    body: "Hi there!",
    username: "Cody"
  },
  {
    body: "Hello!",
    username: "Kelli"
  },
  {
    body: "Do you want to have dinner at Gino's tonight?",
    username: "Cody"
  },
  {
    body: "I love Gino's!",
    username: "Kelli"
  },
  {
    body: "Ok great!",
    username: "Cody"
  }
])

puts "✅ Done seeding!"

When we run bundle exec rake db:seed, we'll seed our messages table with this data. How cool! Notice we called Message.create() here, even though we didn't define any methods in our Message class. That's all thanks to Active Record. There are a multitude of built-in methods already defined for us so we don't have to worry about initialization or basic method creation for our classes. Hooray!

Connecting a Front-End

In order to connect your front-end for testing, ensure whatever fetch requests you might be using in say a Javascript or React application, have paths set to http://localhost:9292/messages, or whatever your resource is titled, since that's the port we defined as the server default in our Rakefile. You can change that port number there if needed.

Conclusion

I know that was a lot, but hopefully now you can see how all of these pieces fit together to create a functioning Ruby back-end. There are a lot of moving parts with single responsibility, but that ultimately keeps things organized and functioning appropriately. Give it a shot setting up your own server! You've got this! If you get stuck, Stack Overflow is always there to help.

How To: Controlled Forms with React

Cody Barker — Thu, 09 Mar 2023 19:48:08 +0000

Unlike JavaScript, React makes use of state in order to keep track of component changes over time. While using state does incur some added complexity, it has its benefits, particularly when it comes to creating controlled forms. We use state to keep track of the dynamic input values in our forms. So what is state exactly?

State

While props remain static, state is dynamic data. It changes over time. Setting state allows us to rerender our components without having to refresh the page or change/add props. That's why state plays an important role in how we handle forms in React. When the input, text area, or select values of a form are set with state, we have a controlled form.

In order to use state in our app, we need to import the {useState} hook from React like so.

import React, { useState } from 'react'

Next, we need to invoke our useState hook. The useState hook returns an array of 2 variables, the first being a reference to the value of our state variable, and the second a function that allows us to update that state, which begins with "set". Whatever is within the parentheses of the useState hook becomes the default value of our state. In many cases, it might simply be an empty string. An example of the useState hook might look a little something like this:

const [name, setName] = useState("")

Above, "name" is our state, and "setName" is our setter function. Because we have an empty string inside the parentheses of useState, the default value of "name" is an empty string. An important note about state: whenever we want to update state, we must pass a new object or value to our setter function. By default, we don't have access to the updated state value until the component has rerendered. If we want to update state using the current value of state, we must pass it within a callback function like so.

setName((name) => `${name} Barker`)

Finally, whenever we call set to update our state, our component and all of it's children components will rerender.

Controlled Forms

Setting up a controlled form is relatively easy. First things first, set up your form. Here's a simple example.

import React from 'react'

function Form() {
    return(
        <form>
            <input 
                type="text"
                name="name"
                placeholder="name"> 
            </input>
            <input 
                type="number"
                name="age"
                placeholder="age">
           </input>
            <button type="submit">Submit</button>
        </form>
    )
}

export default Form

Next, import the useState hook from React.

import React, { useState } from 'react'

function Form() {
    return(
        <form>
            <input 
                type="text"
                name="name"
                placeholder="name"> 
            </input>
            <input 
                type="number"
                name="age"
                placeholder="age">
           </input>
            <button type="submit">Submit</button>
        </form>
    )
}

export default Form

Then, call your useState hook within your component to set up state for both of your form inputs.

import React, { useState } from 'react'

function Form() {
    const [name, setName] = useState("")
    const [age, setAge] = useState("")
    return(
        <form>
            <input 
                type="text"
                name="name"
                placeholder="name"> 
            </input>
            <input 
                type="number"
                name="age"
                placeholder="age">
           </input>
            <button type="submit">Submit</button>
        </form>
    )
}

export default Form

Next, set the input values equal to the corresponding state values. This will allow us to clear our input fields after submitting our form.

import React, { useState } from 'react'

function Form() {
    const [name, setName] = useState("")
    const [age, setAge] = useState("")
    return(
        <form>
            <input 
                type="text"
                name="name"
                placeholder="name"
                value={name}> 
            </input>
            <input 
                type="number"
                name="age"
                placeholder="age"
                value={age}>
           </input>
            <button type="submit">Submit</button>
        </form>
    )
}

export default Form

Now we need to set up event listeners to update state and rerender our component whenever the user enters something into our input fields.

import React, { useState } from 'react'

function Form() {
    const [name, setName] = useState("")
    const [age, setAge] = useState("")
    function handleName(e) {
        setName(e.target.value)
    }
    function handleAge(e) {
        setAge(e.target.value)
    }
    return(
        <form>
            <input 
                onChange={handleName}
                type="text"
                name="name"
                placeholder="name"
                value={name}>
            </input>
            <input 
                onChange={handleAge}
                type="number" 
                name="age"
                placeholder="age"
                value={age}>
            </input>
            <button type="submit">Submit</button>
        </form>
    )
}

export default Form

At this point, we've controlled our inputs, so from here it all depends on what we want to do when we submit. If we just wanted to add these values to an API, we could add a submit event listener to the form and make a fetch post request to the database. That might look something like this.

import React, { useState } from 'react'

function Form() {
    const [name, setName] = useState("")
    const [age, setAge] = useState("")
    function handleName(e) {
        setName(e.target.value)
    }
    function handleAge(e) {
        setAge(e.target.value)
    }
    function handleSubmit(e) {
        e.preventDefault()
        const newUser = {
            username: name,
            userAge: age
        }
        fetch('http://localhost:3001/users', {
            method: "POST",
            headers: {
                "Content-Type": "application/json"
            },
            body: JSON.stringify(newUser)
        })
        .then(r => r.json())
        .then(user => console.log(user))
        .then(
            setName(""),
            setAge("")
        )
    }

    return(
        <form onSubmit={handleSubmit}>
            <input 
                onChange={handleName}
                type="text"
                name="name"
                placeholder="name"
                value={name}>
            </input>
            <input 
                onChange={handleAge}
                type="number" 
                name="age"
                placeholder="age"
                value={age}>
            </input>
            <button type="submit">Submit</button>
        </form>
    )
}

export default Form

To recap, whenever a user changes the text within our form input fields, the setter function is called in the event listener, updating our states by setting them equal to the input values. Every state change rerenders the component without a page refresh, updating everything immediately. How nice!

When we submit our form, we create a new object called newUser, setting the key value pairs using state.

We then make a fetch request to our example API, console.log the response which is our newUser, and then clear the input fields by setting state back to empty strings. If done correctly, our newUser will be added to the database.

Remember, we aren't just limited to controlling forms with inputs. We can also control form elements like and with state in very much the same way!

A Brief Overview of Functions

Cody Barker — Tue, 31 Jan 2023 17:58:55 +0000

If you’ve spent any time at all with Javascript, you’ll probably know that functions are a very important part of the language. Functions use code statements, like instructions in a recipe, to do work, or to calculate a value. One function can do the same work for multiple sources of data, removing the need to repeat our code over and over again. Doesn’t that sound great? The following is a brief overview of the parts of a function, how to use functions, and how to choose the most appropriate type of function for your code.

Parts of a Function

Take a look at this example function declaration.

function add(a, b) {
    return a + b
}

Function Keyword

This function declaration starts with the function keyword.

Function Name

Some functions have names, which allows us to “call” those functions into action. In the example above, the function name is "add". Functions without names are known as “anonymous functions”. We’ll cover those later.

Parameters

In the example above, the parameters are "a" and "b". Functions may or may not expect parameters, or rather named variables or data to be provided to them. If parameters are included, the function will expect them to appear somewhere within the function body at least once. Parameters are essentially placeholders for arguments when calling the function.

Function Body

The function body follows the parameters, and is home to the statements. In most cases, it is represented by curly braces.

Statements

Statements are the lines within the function body which detail specific tasks for the function to perform. A function body can contain many statements. In the example above, the sole statement is

return a + b

Return value

Functions may or may not have a return value. After completing the work outlined by the statements, a function may “return” a value based on that work. Another way to frame this, is the function resolves to a specific value like a variable does. That value could be any data type, like a string, number, array, object, or even another function!

Arguments

Arguments are used when calling a function. The arguments passed to a function take the place of the parameters, and act as inputs for the function so it can do something with them.

How to Use a Function

Invoking a Function

This involves typing out the function or variable name, followed by ( ), with any arguments passed inside the parentheses.

add(2, 5)

Types of Functions

Function Declaration

Perhaps the most common way to create a function is with a function declaration. Our add function from above is an example of a function declaration. Function declarations are hoisted, which means they can be invoked before they are defined. This is especially helpful, so function declarations are a great way to go when deciding which type of function to create. Function expressions on the other hand, are not hoisted.

Function Expression

const subtract = function (a, b) {
   return a - b
}

A function expression differs from a function declaration in that the function is assigned to a variable.
A traditional function expression starts with either the const or let keyword, followed by the variable name. It is then set equal to the “function” keyword, followed by parentheses for the parameters and curly braces for the function body.
Immediately Invoked Function Expressions can be either named or anonymous, and invoked immediately by adding an extra set of parentheses to the end of the function.
This avoids needing to call the function elsewhere in the code.

const subtract = function (a, b) {
   return a - b
}()

Callback Functions

Callback functions are functions passed as arguments to other functions.

function cb(num) {
   return num * 2
}

function add(a, cb) {
   return a + cb
}

add(3, cb(2))
//=>returns 7

In this example, cb is our callback function, and it takes a number as it's argument. When add is called, it returns 3 + ((2 * 2)) which equals 7.

Arrow functions

Arrow functions are a special type of function expression. Their syntax can be simplified and comes with some added benefits. Arrow functions take parameters in the usual way, but the parameters are followed by => before the curly braces of the function body.

const multiply = (a, b) => {a + b}

Special Cases for Arrow Functions

If the arrow function has only one parameter, the parameter does not need to be surrounded by parentheses.
If the arrow function has only one statement, it doesn’t need the curly braces for the function body. The function body can instead be written as one line of code after the arrow.

const log = a => console.log(a)

Arrow functions allow us to keep simple functions short, tidy and easy to interpret.
Arrow functions with a single statement (known as a “concise body”), have an “implicit return value”, which means they return a value without requiring the “return” keyword. Arrow functions with more than one statement (known as a “block body”), will require the “return” keyword if they should return a value.
Arrow functions don’t create their own context, so when using the “this” keyword, and nesting functions, arrow functions allow us to avoid using .bind or similar methods to set our context. This can be extremely helpful, as keeping track of a nested function's context can be challenging.

Anonymous functions

setTimeout(() => console.log('Wait 1 second'), 1000);

Anonymous functions are function expressions, typically passed as callback functions. Only function expressions can be anonymous. Arrow functions can be anonymous functions. In our example above, our anonymous arrow function is

() => console.log('Wait 1 second')

Asynchronous functions

Async functions allow our functions to do work without holding up the rest of our code. They do work outside the normal execution context. This helps web pages load quickly while information is gathered and processed behind the scenes. Our setTimeout function is an example of an async function. It accepts, as arguments, a callback function (in this case an anonymous arrow function), and a number of milliseconds to wait before executing the callback function.

setTimeout(() => console.log('Wait 1 second'), 1000);

Recursive functions

Recursive functions are functions which call themselves until they meet a condition which tells them to stop.

As you can see, there are a whole bunch of different functions, all with their distinct perks and limitations. Many of these function types perform similarly, but you’ll find specific situations for each in your work. Choosing the right type for a given scenario can pay dividends, making your code more succinct, effective, and communicative.