DEV Community: Dylan Raye-Leonard

Storing Multiple Image Files in Amazon S3 using Rails Active Storage and React.js

Dylan Raye-Leonard — Fri, 22 Jul 2022 20:57:00 +0000

In conversations with seasoned professionals in the software engineering field I have been told time and again that the cloud is the dominant computer technology of our time. From basic consumer-facing storage services such as Google Drive or OneDrive to lightning-fast, pay-by-the-minute computing services for large dataset analysis, cloud computing has become the central piece of infrastructure in the modern tech world. Its advantages are clear; as Microsoft's Azure website states, "cloud computing is the delivery of computing services—including servers, storage, databases, networking, software, analytics, and intelligence—over the Internet (“the cloud”) to offer faster innovation, flexible resources, and economies of scale. You typically pay only for cloud services you use, helping you lower your operating costs, run your infrastructure more efficiently, and scale as your business needs change."

For my final project with Flatiron School I wanted to engage with this massive aspect of modern software engineering in some way, and using Amazon's S3 (Simple Storage Service) was the perfect introduction. S3 is simple, has a functional free tier, and serves as an entryway into AWS, the current dominant cloud services provider. Below is a walkthrough of how I set up S3 image storage in my react/rails application. Importantly, this guide details storing multiple images associated with a single record, in contrast to storing a single image as is detailed in the majority of the guides that I found (examples here and here).

This guide assumes that you have already set up a web app with React frontend, Rails backend, and a Rails ActiveRecord model to which you would like to attach images (I will be attaching the images to a User model)

A word of warning: I found that the rails "debug" gem did not work well when checking whether ActiveStorage had successfully created a file or when generating a temporary url for a file, likely due to lazy loading or a similar feature. I would recommend using rails console in lieu of debugger wherever possible to avoid these issues.

Uploading images

First, image files need to be uploaded to the front end so that the client can package them to send to the server. To accomplish this, I used code from this Stack Overflow answer but modified it by adding the multiple attribute and saving the images in a stateful array.

# client/src/components/uploadAndDisplayImage.js
import React, { useState } from "react";

const UploadAndDisplayImage = () => {
  const [selectedImages, setSelectedImages] = useState([]);

  function displayUploadedImage() {
    if (selectedImages[0]) {
      return selectedImages.map((image, index) => {
        return (
          <div key={index}>
            <img
              alt="not found"
              width={"250px"}
              src={URL.createObjectURL(image)}
            />
            <br />
            <button
              onClick={() =>
                setSelectedImages((selectedImages) => {
                  return selectedImages.filter((_, i) => i !== index);
                })
              }
            >
              Remove
            </button>
          </div>
        );
      });
    } else {
      return null;
    }
  }

  function handlePhotoSubmit() {
    const formData = new FormData();

    selectedImages.forEach((image, index) =>
      formData.append(`images[]`, image)
    );

    for (const value of formData.values()) {
      console.log(value);
    }

    fetch("/user-image", {
      method: "POST",
      body: formData,
    })
      .then((response) => response.json())
      .then((data) => {
        console.log(data);
      })
      .catch((error) => console.log({ error: error }));
  }

  return (
    <div>
      <h1>Upload and Display Image</h1>
      {displayUploadedImage()}
      <br />
      <br />
      <input
        type="file"
        name="myImage"
        multiple
        onChange={(event) => {
          console.log(event.target.files);
          setSelectedImages(Array.from(event.target.files));
          console.log(Array.from(event.target.files));
        }}
      />
      <br />
      <br />
      <button onClick={handlePhotoSubmit}>Submit</button>
    </div>
  );
};

export default UploadAndDisplayImage;

This code allows for multiple image files to be uploaded, stored in a stateful array, and displayed on the page. When the Submit button is clicked, a formData object is created (see MDN for more info about formData), the images are appended to it, and the object is sent to the back end using a POST request.

Setting up S3

To set up the S3 bucket in which the images will be stored I largely followed this honeybadger.io article. Rather than replicate all of those steps here, I recommend following Jeff's guide, stopping at the "Scoping To a User" header. The second half of his guide involves using the devise gem to quickly create a "User" model in ActiveRecord for example purposes, but is not applicable when building that model from scratch.

Saving images to S3

Once the bucket is set up and Active Storage is configured, actually attaching photos is as simple as:

# app/models/user.rb
has_many_attached :images

# app/controllers/users_controller.rb
def add_images
  user = User.find_by(id: session[:user_id])
  user.images.attach(params[:images])
end

# config/routes.rb
post "/user-image", to: "users#add_images"

Retrieving images from S3

Finally, retrieving images from S3 consists of generating an array of image urls in the image_urls method, then including that array in the data returned from a GET request:

# app/models/user.rb
def image_urls
  images.map do |image|
    Rails.application.routes.url_helpers.rails_blob_path(image, only_path: true)
  end
end

# app/serializers/user_serializer.rb
attributes :id, :first_name, :last_name, :username, :image_urls

The image urls generated in this fashion allow for temporary access to the image files stored in the S3 bucket, and they expire after a short time.

Configuring ActiveStorage/troubleshooting

Most of the configuration for ActiveStorage should be complete after walking through Jeff's guide. However, I added the following code while debugging errors. This may or may not be necessary depending on your system settings, but if in doubt, adding it shouldn't cause any trouble.

adding req.path.exclude?('rails/active_storage') in the following:

# config/routes.rb

# direct all non-backend routes to index.html
get "*path",
  to: "fallback#index",
  constraints: ->(req) { !req.xhr? && req.format.html? && 
  req.path.exclude?('rails/active_storage')}

Make sure that you specify the bucket by name only:

# config/storage.yml
bucket: capstone-2-drayeleo # be sure to delete <%= Rails.env %> from this line

Conclusion

There you have it! Image files should now be able to be saved to your S3 bucket, with ActiveStorage doing most of the heavy lifting for you.

Additional Resources

Rails Edge Guides Active Storage Overview

Note: cover image sourced from BlueBash Blog

Nested Routes with React Router 6

Dylan Raye-Leonard — Mon, 27 Jun 2022 23:33:13 +0000

Whenever you click on an interactive element on a webpage - a navbar button, login/signup button, a link to another page on the website, etc - it's likely that you'll be sent to a new URL. At the new URL, a new page will be rendered on the screen as dictated by data that was sent to your computer from a remote server. This is called routing, and although it may not always be apparent to the user, it can be carried out in two very different ways.

The traditional way to route a user after they've activated a navigational element on the page is called "server-side routing". In server-side routing, the site is designed such that only the data (ie, HTML) for the currently active page is sent to the client (your web browser). The bulk of the website (any pages that are not currently being displayed) remain stored on the server and are only accessed if and when a request for that specific page is made by the client. The client would then clear the prior page in order to display the new page that is being sent from the server.

While there are advantages to server-side routing, such as faster initial load times and simpler front-end design, it has its drawbacks. Although the initial load will be fast, any elements that are consistent across all pages (ie, a header/footer) will have to be re-delivered to the client and re-rendered. Perhaps most importantly, this re-rendering of the entire page breaks the smooth "single page web app" interface that has become the new standard for modern websites. Blank "loading" pages and long wait times between re-renders can be common with server-side routing. In order to build a seamless single-page web app in which routes are handled smoothly and only relevant page elements are re-rendered, client-side routing is required. Although technically more complex than the discrete pages provided by server-side routing, many tools have been created that make client-side routing nearly as simple as the alternative. For React apps, React Router is the go-to package for client-side routing.

Nested Routes with React Router

While React Router's core functionality is very useful for streamlining simple routing, it does a job that could be fairly easily accomplished by manually building a navbar, even by an early-career coder such as myself. The feature that really impresses me, however, is its use of nested routing. React Router leans into one of the key advantages of client-side routing - avoiding re-renders of reusable elements - and cleverly provides a simple interface that allows us to easily identify which elements should be displayed when. In the creator's words:

We've learned that most UI is a series of nested layouts that almost always map to segments of the URL so this idea is baked right in to React Router.

This is accomplished with nested routes. The setup couldn't be simpler:

Nest "child" routes (Expenses, Invoices) within a "parent" route (App):

//main.jsx

root.render(
  <BrowserRouter>
    <Routes>
      <Route path="/" element={<App />}>
        <Route path="expenses" element={<Expenses />} />
        <Route path="invoices" element={<Invoices />} />
      </Route>
    </Routes>
  </BrowserRouter>
);

2. Add an "outlet" in the parent component to identify where the child components should be rendered:

//App.jsx

import { Outlet, Link } from "react-router-dom";

export default function App() {
  return (
    <div>
      <h1>Bookkeeper</h1>
      <nav
        style={{
          borderBottom: "solid 1px",
          paddingBottom: "1rem",
        }}
      >
        <Link to="/invoices">Invoices</Link> |{" "}
        <Link to="/expenses">Expenses</Link>
      </nav>
      <Outlet />
    </div>
  );
}

With the above code (copied from React Router's v6 tutorial), the App component (containing nav bar and header) is always on display, while the Invoices and Expenses components are displayed conditionally, depending on what parameters are present in the URL. This simple solution avoids a mountain of headaches, and allows for a smoother, faster interface. What's not to love?

Installing the Ruby Plugin for Prettier in VS Code

Dylan Raye-Leonard — Fri, 20 May 2022 21:55:47 +0000

Prettier is the premier code formatter extension for front-end languages in VS Code, at least if you go by the number of downloads in the extension marketplace. I found it to be extremely helpful while learning JavaScript and React, both to improve my formatting and typing efficiency as well as to teach me what well-formatted code actually looks like.

When I started to learn Ruby, I was sorely missing the ease of use of prettier and finally decided to install the Ruby plugin for Prettier to try to get the same functionality. However, the installation proved trickier than I expected and I had to recruit some additional help from TA Wills Blake. Together, we figured it out. The instructions are below.

The plugin should be installed globally so that it is automatically available to any new projects opened in VS Code. However, the instructions provided by Prettier for installing the plugin are vague and seem to imply that the plugin must be installed as a dependency with each new project. This requires creating a gemfile, adding in the dependency, etc.....nah, we want to do what they're describing on the Prettier Plugins page. As it says on that page: "plugins are automatically loaded if you have them installed in the same node_modules directory where prettier is located"; so let's find that directory.

Steps to follow:

Make sure that you have already installed the Prettier extension in VS Code
Navigate to your home directory by entering cd into the command line, or opening a new CLI window
Enter ls -a to show all directories, including hidden ones
If you are on Windows using WSL, you should see a .vscode-server directory. If you're on macOS, it should be simply .vscode. Use cd to navigate into whichever of the two applies to your system
cd into extensions
There should be a directory titled esbenp.prettier-vscode-<version> (ie, mine was esbenp.prettier-vscode-9.5.0). cd into it
Enter npm install --save-dev prettier @prettier/plugin-ruby in the CLI
Wait for it to finish installing, then restart VS Code

You should now be able to right-click in any ruby document in VS Code and select "format document". You may also be able to format on save by default. If not, you can navigate to the VS Code Settings file using the following steps:

Hold down ctrl (or cmd for macOS) + shift + P
Type settings.json and select "Preferences: Open Settings (JSON)"
Scroll down the json file. You should already have an object specifying prettier as the default formatter for javascript code:

"[javascript]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
},

Add the following below it:

"[ruby]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode",
    "editor.formatOnSave": true
},

Your final result should include both settings:

"[javascript]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
},
"[ruby]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode",
    "editor.formatOnSave": true
},

Single Responsibility with React Components

Dylan Raye-Leonard — Mon, 16 May 2022 07:39:39 +0000

Three weeks ago I began learning the JavaScript React framework.

I had a fair amount of knowledge about basic coding principles (functions, objects, looping, etc.) before beginning the Flatiron coding bootcamp. I had taken a C++ programming class in engineering school, had used code to manipulate data for several engineering courses, and had had several internships/undergraduate research projects which were heavily focused on developing code for sensors for environmental monitoring. However, in each of these applications of my coding knowledge, the work was single-track; I was either provided access to an existing library of code to make surgical modifications to it, or was given an assignment of relatively limited scope such as solving an algorithmic problem on a school project. In both cases, I coded independently and without much need to concern myself with the larger context into which my work would fit. The well-bounded scope of these tasks kept things simple for me.

I coded independently and without much need to concern myself with the larger context into which my work would fit...this is not what coding in the real world is like

This is not what coding in the real world is like. Everything I've learned about real-world programming - from instructors, software engineer friends, and personal research - has consistently indicated that it is a far more complex, context-specific, and team-oriented task than my academic pursuits would indicate. The algorithmic problem solving skills that I developed, while important for demonstrating aptitude, are not the be-all-end-all measure of a programmer's ability. Much more important is the programmer's skill in leaving a clear and logical breadcrumb trail through all of their work so that it can be understood as it is revisited over the following years and potentially even decades.

While software engineers can and certainly should develop skills at writing logical, clear, and well-documented code independently from scratch, with the complexity of modern software even the most communicative and well-intentioned programmers may find themselves struggling to synchronize their work with that of their team. The beauty of software - its incredible flexibility - makes it the most significant technology of our era while simultaneously making it a many-headed hydra that, if not kept in check under strict organizational principles, can get out of control of even the most capable teams. Ten Javascript engineers, each left to write a moderately complex program from scratch, will come up with ten very unique codebases. Over time software engineers have built tools, techniques, and principles such as Single Responsibility and Separation of Concerns for ensuring comprehension and interoperability regardless of the original author. However, at a certain point, the flexibility inherent to any programming language becomes its Achilles' heel.

At a certain point, the flexibility inherent to any programming language becomes its Achilles' heel

This is where frameworks, such as React.js, become relevant. While many companies building their codebases with vanilla JavaScript have undoubtedly created their own design and organization paradigms to structure their teams' approach to software development, React takes this a step further: it bakes its design paradigm into the very structure of its code by using JSX to render Components. While a stubborn and uninformed engineer could still manage to create an entire web app in one component, the structure of React lends itself to the reduction of a webpage's elements into a collection of simpler components which adhere to Single Responsibility/Separation of Concerns in their own unique way. Thus, React deftly sidesteps the single greatest issue with building scalable code, by providing a framework that at every step gently nudges programmers towards a set of standard procedures, all while maintaining the flexibility that makes software engineering such a uniquely powerful technology.

Although I did not immediately see the usefulness of React when I started learning the syntax three weeks ago, I've since come to understand why it has become the most popular javascript framework to date. This was cemented during the Phase 2 project, in which our group was able to follow the principles of Thinking in React by sketching out a component hierarchy, dividing up the components, and assigning each person to develop a different component. Even with relatively little experience in software architecture and programming workflows we were able to work in parallel on a somewhat complex assignment, each completing a functional piece of the website with minimal discussion of our organizational strategy or principles of design. We operated as a team based on design principles that, if we're being honest, we likely aren't even fully aware of, because these principles are inherent to the way that React functions. And that's pretty remarkable, if you ask me!

Cover image sourced from Tech Diagonal

Persisting Business Ratings

Dylan Raye-Leonard — Fri, 22 Apr 2022 00:45:59 +0000

When first learning to code, every day of practice brings one to what feels like a significant new milestone. Each new skill attained comes with a sense of accomplishment that is difficult to match elsewhere. However, the feelings of power and capability quickly fade as one realizes the neverending depth of skill that is still waiting to be achieved. And so it becomes a cycle of high highs and low lows.

So it goes at Flatiron school, although the day-in-day-out nature of a coding bootcamp helps to keep me in the highs of discovery. Most recently, that discovery is the full functionality of building a front end with vanilla Javascript, complete with dynamic rendering of HTML elements, event listeners, and API sourcing. This was best demonstrated by our Phase I project, in which myself and two classmates developed a brewery search and rating app.

App Functionality

The app utilizes the Open Brewery DB dataset and API, which is a record of breweries across the United States. Breweries are searched by city, with up to 20 results displaying for each city search. Most importantly, the app allows the user to assign a rating to each brewery and, using npm's JSON Server package, persist those assigned ratings by saving them to a db.json file. The db.json file is used to update the ratings upon page refresh or upon a new city search being performed.

The app accomplishes this using Javascript's native fetch function in conjunction with three http request methods - GET, PATCH, and POST.

If you would like to reference the code for this project to get a better sense of the scope and operation of the final deliverable, it can be accessed on github here.

`GET`

First things first - the app must be able to respond to the user's input of a city by populating a list of breweries in that city! This utilizes the most common of the http request methods - GET - in conjunction with fetch. In fact, this combination is so common that it's not even necessary to specify that GET is the operation being performed - fetch defaults to this method.

fetch(`https://api.openbrewerydb.org/breweries?by_city=${city}`)
.then(response => response.json())
.then(breweries => {
    console.log(`breweries data for ${city}: `, breweries);
    document.querySelector('#brewery-cards').innerHTML = "";
    breweries.forEach(brewery => renderCard(brewery));
});

The above code passes the user's input (city) into the fetch function to send a request to the API for a list of breweries in that city. It then converts the API's response to JSON format, console logs the converted response, and calls another function to render each of the brewery's information on the page.

The GET functionality is used one more time in the initialization of the page - to retrieve the ratings information that was previously saved in the db.json file.

fetch(`http://localhost:3000/breweryRatings`)
.then(response => response.json())
.then(data => {
    ratingsJson = data;
    console.log("ratingsJson: ", ratingsJson);
});

From there, rendering the pre-existing ratings on the webpage is simply a matter of assigning formatting changes based on the data that is now saved locally in ratingsJson.

`PATCH`

With the user's request completed, the list of breweries rendered on the page, and the previously assigned ratings displayed for the respective breweries, the only thing remaining to do to ensure that the ratings continue to persist correctly is to update db.json whenever a user assigns a new rating. To do this, first the script must assess whether a record for that particular brewery already exists in db.json. If it does, the http request method PATCH is used:

const breweryCardElement = event.target.parentElement.parentElement
const matchIndex = ratingsJson.findIndex(element => element.apiId === breweryCardElement.id);

const obj = {
    rating : event.target.className.slice(-1),
} 

fetch(`http://localhost:3000/breweryRatings/${ratingsJson[matchIndex].id}`, {
    method: 'PATCH',
    headers: {
        'Content-Type': 'application/json',
    },
    body: JSON.stringify(obj),
})
.then(response => response.json())
.then(data => {
    console.log('Success:', data);
    ratingsJson[matchIndex] = data; //update ratingsJson
})
.catch((error) => {
    console.error('Error:', error);
});

Because a record already exists for the target brewery, a fully-formed JSON object is not needed. Rather, the url provided to fetch directly references the server-appointed ID of the target brewery, and the only additional information that needs to be provided is what to update. Thus, obj contains only a single key: "rating".

`POST`

If a record for the target brewery does not already exist in db.json, then a POST request must be made. Rather than updating a specific record in db.json, POST adds an entirely new record to the JSON.

const breweryCardElement = event.target.parentElement.parentElement;

const obj = {
    apiId : breweryCardElement.id,
    rating : event.target.className.slice(-1),
} 

fetch('http://localhost:3000/breweryRatings', {
    method: 'POST',
    headers: {
        'Content-Type': 'application/json',
    },
    body: JSON.stringify(obj),
})
.then(response => response.json())
.then(data => {
    console.log('Success:', data);
    ratingsJson.push(data); //update ratingsJson
})
.catch((error) => {
    console.error('Error:', error);
});

Because the record does not already exist, the URL provided for POST is the same as the URL provided for GET. A fully-populated object must be provided to the server so that it can create a complete record of the new brewery rating.

Conclusion

Using GET, PATCH, and POST, developers can persist ratings assigned to businesses in remote databases. Further development of this project might include the addition of a "Clear Rating" button, which would require the use of the DELETE HTTP request method to clear the target record from db.json.