DEV Community: Joe Dietrich

Must/Should/Can - a Personal Organization System

Joe Dietrich — Sun, 20 Feb 2022 23:17:04 +0000

Inspiration

A little while ago, I found myself struggling to bring order to my tasks at work. I'd tried many different organizational systems. Some didn't suit my work style, others were way too complicated - adding to my daily tasks rather than making them easier. I decided to put together a system that worked for me.

The System

I divide my tasks for the day into three buckets: Tasks I must do today, Tasks I should do today, Tasks I can do today. Every day, I rewrite and carry over any incomplete tasks to the next day. It's simple, but it works for me!

Basic Features

I took the simple pen-and-paper tools and made them digital. The features of Must/Should/Can are straightforward, as is system itself:

Account Creation and Login
Task Creation, Editing, and Prioritization
Task Resets
Task Archiving and Deleting

What I Used

Backend

Ruby on Rails as the framework for the API
ActiveModelSerializers to build JSON views
PostgreSQL as the database
The bcrypt gem to improve password security in tandem with the ActiveRecord has_secure_password feature

Frontend

React / Create React App
React Router v6 - For client-side routing
Styled Components to style the application

Authorization, Passwords, and Salting

While building Must/Should/Can, it did not escape my attention that a user's tasks could be very private, so there was a need to protect them as much as possible. To ensure that privacy, I not only implemented user authorization and password authentication, I protected their passwords with the ActiveRecord has_secure_password feature.

`has_secure_password`

If you're storing passwords in any system, it is a very bad idea to store them in plaintext anywhere in your application. Doing so exposes you and your users to potential data losses, which is a Bad Thing. The has_secure_password feature adds methods to an ActiveRecord model that make setting and authenticating securely hashed and salted passwords on your user models easy.

Under the hood, has_secure_password uses the bcrypt gem to hash and salt your user's passwords. This process makes it very difficult for bad actors to access your users' password data, even if they manage to steal your database.

Hashing is the process of taking data and processing it to create a new value, usually of a fixed length (sometimes called a fingerprint). The process is unidirectional, meaning once a value has been hashed, it is incredibly impractical (with current technology) to reverse the process to derive the original value from the hash. For example, using bcrypt, the password Wolfgang the puppy might hash to the value $2a$12$j29LhAzasXWN7glfGjp9NuFXcOYBCffkE4RWcQJwBFzxsAsUsQ2nK. This unidirectionality is what makes hashed passwords more secure than plaintext passwords - a hacker will need to do extra work to break the encryption involved.

Or they might have a Rainbow Table, which is a precomputed set of values that will let an attacker look up the password based on a given hash. If the hashing function is known to the attacker, hashing alone won't be enough to protect a user's password, since the same input value will always produce the same output hash.

This is why bcrypt will also salt a password before storing the hash in your database. A salt is data added to the input of a hash function. In bcrypt's implementation, a unique salt is added to every password on generation. This means that an attacker would need to use a different pre-computed Rainbow Table for every single password, which is computationally prohibitive.

All of this means that, properly implemented, using has_secure_password and bcrypt in your application is one important step protect you and your users from bad actors.

Next Steps

I plan to introduce the ability to add notes to tasks so you can, for example, sketch out an agenda for a meeting, or divide tasks into subtasks. I also plan to enhance the archive with grouping and sorting. Later on, I'll enhance the user's account management experience, letting them reset their password and edit their user name.

End

Thanks for reading! For a walkthrough, take a look at the demo video. Access the application itself at https://must-should-can.herokuapp.com/.

Building an Event Landing Page Management System

Joe Dietrich — Mon, 20 Dec 2021 00:07:15 +0000

Frontend: joedietrich-dev/event-page-client
Backend: joedietrich-dev/event-pages-server

Inspiration

I was inspired to build this when I was tasked with repeatedly hand-coding landing pages in simple html. This was inefficient in terms of time spent and meant I was the only person around able to maintain the pages or make any changes. I set out to create a proof-of-concept / MVP event page builder. It has nearly all the entities I need to build those hand-coded pages.

Basic Features

This is the backend for a simple proof-of-concept event page creator. It is designed to let you build events with:

Hosts
Honorees
Panels & Panelists
Sponsors of different levels

What I Used

Frontend

React / Create React App
React Router v6 - For client-side routing
MUI - A UI component library
MUI Icons - For iconography

Backend

Sinatra - a domain-specific language used to build the API framework for the app
ActiveRecord - Rails' ORM, here used with Sinatra to map the Ruby classes to the database
SQLite - the database engine used in this project
Rake - to run commands on the command line
Faker - used to build out seed data

Entities and their relationships

Before I built out the migrations for the database, I sat down and planned the data structure. Below is a diagram of the different tables in the application's database and their relationships to one another.

Faker

Before I started building out the front end of the application, I knew I needed data to work with. Having real-looking data helps in the design process, and using Faker means you don't need to build out your database by hand.

Faker has a large number of different generators you can use to make your data more realistic or even if you just want to get a little more creative. I used and would recommend the:

Company generator - for company names
Lorem generator - for lorem ipsum placeholder text
Number generator - for years
Nation and Hobby generators - for somewhat sensical sounding event names (e.g. 2022 Malaysian Drumming Awards)
Hipster and GreekPhilosopher generators - for English (or English-adjacent) text placeholders
Name and Job generators - for people's names and job titles

All of these together helped me create reasonable placeholder data, which you can see in the demo video.

Eliminating Orphan Records

When I started building the interface for the app, I realized that deleting certain entities, like events or panels, could leave orphaned records. These were records that could not logically exist independently of their parent entities - especially the linking records between the panels and panelists and events and sponsors. I didn't want this, since orphaned records are just taking up space, at best, and could cause unexpected behavior at worst.

I solved this problem by setting the dependent: :destroy option on some of my models' associations.

class Panel < ActiveRecord::Base
  belongs_to :event
  has_many :panel_panelists, dependent: :destroy
  has_many :panelists, through: :panel_panelists
  has_many :panel_sponsors, dependent: :destroy
  has_many :sponsors, through: :panel_sponsors
end

Take the Panel class as an example. A panel belongs to an event, and has many panelists and sponsors through linking models. When a panel is deleted, the panelists and sponsors should remain, since they can be associated with many panels. The linking records, panel_panelists and panel_sponsors are unique to the panel being deleted. With dependent: :destroy, those records are deleted along with the panel.

End

Thanks for reading! For a walkthrough, take a look at the demo video.

Build a fixed-aspect-ratio photo gallery with hover effects (using only HTML & CSS!)

Joe Dietrich — Fri, 22 Oct 2021 02:56:09 +0000

In this article, I'll explain how to create a gallery of photos with text overlays using modern CSS and HTML, as seen in the Code Sandbox below.

Background

As I was building out a test photo gallery, app I realized that I wanted my main page to be a grid of square images. The pictures were supposed to be the star of the show, but I wanted the viewer to be able to see a description of each image when they hovered over it. To spice it up a little, I decided to add a "zoom in" effect on hover.

My goal was to use modern CSS and HTML only, if I could. I decided to start with CSS Grid as a base.

Step One - The Grid

The first step was building out the grid itself. To start with, I created a container div and a few tiles:

<div class="grid-container">
  <div class="grid-tile"></div>
  <div class="grid-tile"></div>
  <div class="grid-tile"></div>
  <div class="grid-tile"></div>
  <div class="grid-tile"></div>
  <div class="grid-tile"></div>
  <div class="grid-tile"></div>
  <div class="grid-tile"></div>
</div>

The grid-container will hold all our grid-tiles. The grid-tiles will then hold the images and the overlays.

.grid-container {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(150px, 1fr));
  gap: 20px;
}

.grid-tile {
  background-color: rgba(0, 0, 0, 0.1);
  aspect-ratio: 1;
}

Here, we set the grid-container to display as a grid with a 20px gap between its rows and columns. We also define the width of the columns of the grid in grid-template-columns. With repeat(auto-fit, minmax(150px, 1fr)), we declare that we want to create columns that are at least 150px and will otherwise evenly grow to fill the available width of the container (minmax(150px, 1fr)). The auto-fit keyword will only create as many columns as we need - if we only have two child elements, only two columns will be created.

For a great auto-fit / auto-fill breakdown, check out (Auto-Sizing Columns in CSS Grid)[https://css-tricks.com/auto-sizing-columns-css-grid-auto-fill-vs-auto-fit/]

The critical part of the grid-tile style is aspect-ratio: 1. This tells the browser that we want square tiles. aspect-ratio accepts whole numbers or fractions - without units - in the format <width> / <height>.

Note aspect-ratio is supported in the most recent version of all major browsers as of this writing, but support does not include Internet Explorer or Safari before version 15. You can replicate some of this without aspect-ratio by setting grid-template-columns: repeat(auto-fit, 150px); and grid-auto-rows: 150px; in the grid-container class. You lose flexibility, but maintain the fixed aspect ratio.

With these rules in place we should see something like this:

Step Two - The Overlay

Now that we have the grid itself, we can add a text overlay.

We'll add the following code inside each of our grid-tile divs:

  <div class="tile-overlay tile-overlay-bottom">
    <p class="tile-overlay-text">Hello, World!</p>
  </div>

The a tile-overlay div will contain an elements that we want to appear on hover over the tile. The tile-overlay-bottom styles will ensure the element appears on the bottom of the tile. We'll style tile-overlay-text for readability on a darker background.

We need the tile to have position: relative so we can place its children absolutely, otherwise, the children will be positioned relative to the window itself, which isn't what we want.

.grid-tile {
  background-color: rgba(0, 0, 0, 0.1);
  aspect-ratio: 1;
  position: relative;
}

.tile-overlay {
  position: absolute;
  background-color: rgba(0, 0, 0, 0.75);
}

.tile-overlay-bottom {
  bottom: 0;
  width: 100%;
}

.tile-overlay-text {
  margin: 0;
  color: white;
  padding: 10px;
}

As a challenge to yourself, try to implement an overlay element that will appear in the top-right of each tile.

At the end of Step Two, you'll have something like this:

Step Three - Overlay Hover Effect

So far, we have a grid of tiles and we have an overlay. That's great, but the overlay is there all the time and I promised you hover effects.

To get us there, we'll need to add a couple lines to our CSS:

.tile-overlay {
  position: absolute;
  background-color: rgba(0, 0, 0, 0.75);
  opacity: 0%;
}

.grid-tile:hover .tile-overlay {
  opacity: 100%;
}

With these few lines of code, we're giving everything with the tile-overlay class an opacity of 0%, which means the element will still take up its usual space, but will not be visible.

The next rule says, "Every time a viewer hovers over a grid-tile, I want the opacity of the tile-overlays to go to 100% (be completely visible)."

And with that, we have one of our hover effects!

For a smoother transition between opacity 0% and opacity 100%, you can insert a transition property into the .tile-overlay rule:

transition: opacity 0.33s;

This will extend the length of the transition from 0% to 100% opacity from instant to a third of a second.

The end of Step Three should look like this:

Step Four - Adding Images

So far, we've built the cards and an overlay, but our photo gallery isn't any good if there aren't any photos! Start off by adding img tags to your grid-tile divs. When you're done, the grid-tile html should look something like this:

  <div class="grid-tile">
    <img
      class="tile-image"
      src="https://source.unsplash.com/random/200x250"
    />
    <div class="tile-overlay tile-overlay-bottom">
      <p class="tile-overlay-text">Hello, World!</p>
    </div>
  </div>

If you check out your page now, you'll see that the images are overflowing the tiles, so we're going to need to turn to CSS for help.

.tile-image {
  width: 100%;
  height: 100%;
  object-fit: cover;
}

This new CSS rule will constrain our images to the height and width of their parent - in this case, the grid-tile. A value of cover for the object-fit property means that the image will maintain its aspect ratio, but anything outside of the parent element will be clipped. This keeps our images from being distorted, but means we lose some of the image content.

One last thing to note for this phase. You may have noticed that our tiles are no longer perfect squares, depending on your browser. There may be a small strip of gray background below the image in each tile. I believe this has something to do with the image distorting the grid, but I haven't been able to figure it out yet. If you know why this happens, please leave a comment!

We can fix that strip pretty easily by adding overflow: hidden to the grid-tile rule. This will also be important for the next step, so let's go ahead and do it now:

.grid-tile {
  background-color: rgba(0, 0, 0, 0.1);
  aspect-ratio: 1;
  position: relative;
  overflow: hidden;
}

By the end of Step Four, you'll have something like this:

Step Five - The Image Zoom Hover Effect

What we have is great so far, but let's jazz it up a little. We want it to look like the image is coming slightly closer to you when you hover over it.

First, we'll add some styles to the image to provide a baseline for what we'll do on hover:

.tile-image {
  position: relative;
  top: 0;
  left: 0;
  width: 100%;
  height: 100%;
  object-fit: cover;
  transition: 0.33s;
}

These styles give us a baseline for our transition on hover. They tell the browser that we're consciously placing our image exactly where it normally goes in the flow of the document. Note also the height and width. Those will change when we hover over the grid-tile.

.grid-tile:hover .tile-image {
  top: -5px;
  left: -5px;
  width: calc(100% + 10px);
  height: calc(100% + 10px);
}

With this, when a visitor hovers over the grid-tile, the image will grow 10px in width and height (the calc statement makes sure of that!), at the same time, we're shifting the image 5 pixels up and to the left. This makes sure that the effect we're going for is centered in our tile. Without the position change, it would look like the image is just growing from the upper left.

You might ask, "But if the image is growing, why isn't the tile growing too, and changing the layout!?" This is where the overflow: hidden; rule from the last step comes in. Since the overflow is set to hidden, any change in the image size will be clipped!

This leads us back to where we started out:

If you liked this, or have questions, let me know!

Building a basic photo album in React

Joe Dietrich — Wed, 20 Oct 2021 01:54:09 +0000

Purpose

I've loved taking pictures since I was little, but I don't really have a place to show off the best pictures I've taken. I decided to build myself a little photo gallery using React for the frontend, and a very simple JSON Server based backend.

Basic Features

For my photo gallery, I broke the required features down to the basics:

Display images in a gallery format
Display an individual image
Add an image to the gallery
Edit the image's description
Delete the image if needed

To those, I added a couple additional features:

Mark images a "favorites"
Display favorite images in a second gallery

What I Used

To get to my basic feature set, I decided to use:

Create React App to scaffold out the basic React boilerplate
React Router for routing within the app
Styled Components to style the application
JSON Server as a backend for this minimum version of my app.

Building the App

The photo gallery has four major components, which each have their own Routes:

Gallery, which displays image thumbnails in a grid and links to individual ImageDetails: "/images" or "/favorites"
ImageDetails, which displays a larger version of a selected image, along with the image description: nested under the gallery paths - "/images/" or "/favorites/"
ImageDetailsEdit, which provides a way to edit the description of an image: nested under the image detail paths - "/images//edit" or "/favorites//edit"
NewImage, which contains a form and the functions needed to add new images to the gallery: "/new"

Within and surrounding these components, I created a number of additional components to style the contents of each page and provide additional functionality. The majority of the components I created this way were Styled Components.

Challenges

This was the first time I'd used Styled Components in a meaningful way. In the past, I've used a single stylesheet and classes to apply styles, but I wanted to challenge myself to something new.

My first thought when reading the documentation was to wonder about the use of sting literals I hadn't encountered much before. If you haven't seen a styled component component before, it looks something like this:

import styled from "styled-components";

const DetailCard = styled.div`
  display: grid;
  grid: "p i n" auto ". d ." auto / min-content 1fr min-content;
  max-width: 800px;
  margin: 0 auto;
`;

Breaking this down:

styled is the default export from the styled-components module.

div is a function property of the styled object.

A function? But where are the parentheses?

Notice that the CSS styles themselves are contained within the backticks (\) of an ES6 template literal. In this case, it is a tagged template literal. The tag of a tagged template literal is a function (here, div) that takes an array of strings as its first argument, and the values of any substitutions (indicated by the ${} syntax in a template literal) as additional arguments.

This means the example above could be rewritten as the below, with no change in functionality:

const DetailCard = styled.div([
  `
  display: grid;
  grid: "p i n" auto ". d ." auto / min-content 1fr min-content;
  max-width: 800px;
  margin: 0 auto;
`,
]);

Things get a bit more complicated when you introduce those substitutions. For example, with styled components, you can use props to change a component's styles:

const NavButton = styled.button`
  grid-area: ${(props) => props.area};
  padding: 0 1rem;
`;

This allows us to pass in an area prop to define where the component will display:

<NavButton area="n">Next</NavButton>

And translates to CSS like this:

  grid-area: n;
  padding: 0 1rem;

This would be equivalent to, but much less convenient than, calling the button function property of styled directly:

const NavButton = styled.button(
  ['grid-area: ','; padding: 0 1rem;'],
  (props) => props.area);

Once I was able to wrap my head around what this syntax meant, it was much easier to use styled components.

Styled Component Tips:

Don't be afraid of making a lot of styled components, as long as they each serve a purpose!
Keep single-use components near where you use them. I kept mine in the same file as the component I used them in.
If you find yourself using the same (or similar) styles or components in multiple places, you can pull the styled component into its own file and reuse it! Don't repeat yourself if you don't have to!
Read the documentation
Read this (Josh W Comeau Article on Styled Components in React)[https://www.joshwcomeau.com/css/styled-components/]. I found it very helpful, especially the section on making sure you have a single source of styles for each component.

Plans for the future

As I have time, I'm planning to implement:

Basic login and user validation
Real photo upload instead of url submissions
Additional albums
Server-side photo resizing

Visit the most recent version of the site

You can see a working version of the site at: https://photo-album.joedietrich.dev

Building Dinerd using js, HTML, and CSS

Joe Dietrich — Sun, 22 Aug 2021 20:10:33 +0000

Dinerd

You can see Dinerd in action or watch me walk through the app.

Turn to Dinerd to help you answer the age-old question:

"Where do you want to eat tonight?"

Purpose

I developed Dinerd to help me break out of one of the routines I found myself falling into during the past year - always going to or ordering from the same restaurants over and over again.

Comfort food is great! But every so often it's good to branch out and try new things - and this is where Dinerd comes in. Dinerd leverages the Yelp Fusion API to serve the prospective diner random restaurants near them, and lets them skip ones they've already been to!

Basic Features

When a diner first lands on Dinerd, they will see a form that asks them for a location, the distance from that location they'd like results from, and a price-level preference. After they have submitted their selections, Dinerd presents the diner with a randomized list of up to 20 restaurants, pulling details from Yelp Fusion.

If a diner has already visited a particular restaurant, they can mark it as visited and it will no longer show up in their search results. They can see the restaurants they have already visited in a pop-out sidebar menu and remove them from the visited list.

Development Strategy and Process

Before I built Dinerd, I researched restaurant-locator APIs. Yelp was the best I found by far, with a generous daily API limit and high-quality data. After doing research on the data I could expect to fetch from the Yelp Fusion API, I signed up for an API key, and then started creating simple wireframes using Figma - one for the landing form, one for the visited restaurant sidebar, and one for the restaurant card.

Then I started to code.

I started by trying to play with the API. I quickly realized that building a purely front-end application with the Yelp Fusion API wouldn't work (and would also expose my API key to the world, which made me uncomfortable).

Back-end Code

View the full back-end source.

Setup

I had previously researched creating a server using Node.js, so my mind immediately went in that direction to solve my problems. I would build a very small Node.js server to:

Pass my front-end queries on to the Yelp Fusion API
Return the results of the query back to the front-end application
Allow me keep my API key secret
Provide the opportunity for future expansion (logins, database integrations, result processing and caching)

While it would have been possible to meet my requirements using vanilla Node.js, I deceided to use Express to create the server and Axios to retrieve the API data from Yelp Fusion in an asyncronous, promise-friendly way.

To start, I initialized a Node.js project using npm init, and followed the prompts in my console. Then I created a few files I knew I would need, aside from the package.json file created by npm init:

index.js - The gateway for the application, and where I put all the code for the server.
.env - The file where I stored my environment variables (in this case, primarily the API key). It has two lines:

  YELP_KEY=<yelp secret key>
  PORT=3000

.gitignore - The file that tells git to ignore other files and folders. This is important to ensure the .env file doesn't get synced to a cloud repository like GitHub, potentially exposing the secrets it contains. Configured correctly, it will also prevent the node_modules folder from being synced as well. For these purposes, it should contain at least these two lines:

  node_modules/
  .env

Once those files were properly configured, I ran the command npm i express axios dotenv, which installed the Express, Axios, and dotenv dependencies in my Node.js project.

index.js

At the top of the index.js file, I put the require statements, which make the dependences I previously installed available in the code. I also defined the port the application listens on and initialized the Express server:

require('dotenv').config();
const axios = require('axios');
const express = require('express');
const port = process.env.PORT || 80;
const app = express();

The next few lines set up the route we'll use to query the Yelp Fusion API:

app.get('/restaurants', (req, res) => {
  if (req.query.location && req.query.price && req.query.distance) {
    axios({
      method: 'get',
      url: `https://api.yelp.com/v3/businesses/search?term=food&limit=50&location=${req.query.location}&radius=${req.query.distance}&price=${req.query.price}`,
      headers: {
        Authorization: `Bearer ${process.env.YELP_KEY}`
      }
    }).then(yelpResponse => res.send(yelpResponse.data))
      .catch(err => res.status(400).send(err.message));
  } else {
    res.status(404).send('No match for requested URL found.');
  }
})

app is the server object. .get is a method that takes a route and a callback. When someone tries to access the route provided using the GET http method, Express will call the callback method provided as the second parameter to .get, passing in information about the request as the first parameter, and information about the response to the request as the second parameter.

For Dinerd, I expect my client-side application to make a request that contains three parameters - the three fields on the initial form:

location
price options
distance from location chosen

If the req (request) contains the query parameters location, price, and distance, then I use Axios to send the request through to the Yelp Fusion API. For my purposes, I passed in an object containing the http method to use with Axios (get), the url to send the request to (the Yelp Fusion API search endpoint, with my query parameters interpolated), and the required Authorization header. The header contains a reference to the API key stored in my .env file.

If Yelp Fusion responds to my request with valid data, I pass it back to the requester in the res object, using the response's send method. If there were no results for the search parameters passed in, I respond to the client with a 400 error indicating a bad request, and the error message from Yelp.

If the req is not well-formed - that is, if it does not contain a location, price, and distance - then I respond to the client with a 404 error, since the url is not valid and doesn't match the required pattern.

All of the above sets up the Express server, but it's no good if it doesn't start listening for requests:

app.listen(port, () => console.log('Listening on port ' + port));

This code tells the server to listen on the port provided. And with that, the Dinerd back end is ready - or almost.

CORS

If you run the command node index.js now, the server will start up and start listening for connections.

But: Try to issue a fetch request from the browser:

fetch('http://localhost:3000/restaurants?price=1,2,3,4&location=10001&distanc=2000').then(res=>res.json())

And you'll see an error like the following:

Access to fetch at 'http://localhost:3000/restaurants?price=1,2,3,4&location=10001&distance=2000' from origin 'http://localhost:5500' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

This is a CORS, or Cross-Origin Resource Sharing, error. For security reasons, most browsers will prevent HTTP requests made from within a script or a browser's console from being successfully completed if the requested resource is on a different origin, or domain. For example, a site at https://example-a.com/ can make a successful request to https://example-a.com/api, but not necessarily to https://example-b.com/api.

One way around this is to specify which origins a specific resource accepts requests from. In Dinerd, I did this using an Express middleware function to set the headers on every response from my server. I placed the below in index.js above the app.get line.

app.use((req, res, next) => {
  res.header('Access-Control-Allow-Origin', '*');
  next();
})

Express middleware has access to the request and response objects. With the above code, I intercept the responses the server sends out and add a line to the header. As written, this will signal to the requester that any origin (*) is allowed to access the resources on my server.

With the above in place, the backend is ready to go!

Front-end Code

(View the full front-end source)[https://github.com/joedietrich-dev/dinerd].

Dinerd's front end is written in vanilla javascript, HTML, and CSS. The form you see when you land on the home view is fully in the static HTML, with event listeners added when the javascript loads.

I use fetch to make calls to the back-end server created above, and render the restaurant cards using a renderRestaurant function that I created to translate the JSON data into visible and interactive components. The map on each card is created using the Leaflet library and Open Streetmap data, combined with each restaurant's location data returned from the API.

For this version of the app, I use the browser's local storage to persist a diner's previously visited restaurants. This means their choices will only be visible when they're using the same browser on the same device, and will be removed if they clear their local caches, but it does remove the need for a back-end database.

All animations including the sidebar slidein, error state appearance and disappearance, and card transitions are executed using CSS transistions.

Future Plans

In future iterations of this app, I would like to add:

Login and restaurant selection persistence using a back-end database instead of local storage.
More filtering options when selecting a restaurant, including the ability to select only restaurants that are open when the search is performed.
Autofilling the location from the device's gps
Improved styles on very wide screens
Swipe to navigate cards

Tools / Libraries / APIs Used

Front-end

Figma - Design and wireframing tool.
Leaflet - Library for mapping location data. Uses Open Streetmap data.
Stamen Toner - Map tile theme.
localStorage - The Web Storage API method for storing and retrieving data within a user's browser.
Pattern Monster - SVG Pattern generator, as seen in the site's background.
Favicon Generator - Multi-platform favicon generator.
Icon Finder - Source of MIT licensed SVG icons.
Normalize CSS - Provide a better cross-browser baseline for CSS styles.

Back-end

Yelp Fusion API - Source of data on restaurants by location.
Node.js - JavaScript runtime that powers the back-end of Dinerd.
Express - Web application framework used to create API route to pass queries to Yelp and return results to client application.
Axios - HTTP client for Node.js (like fetch, but for Node).
dotenv - NPM package that loads environment variables from a .env file into a location accessible by a Node.js application.