Forem: Sam Markham

Project planning for a React/Rails Writing Challenge app

Sam Markham — Thu, 25 Feb 2021 21:17:29 +0000

Last April I built an app for a novel contest run by an online writers group. It was set up so users could sign up for the app, make an entry for their novel, and then use the app to track their writing progress, as well as see the writing progress of other users.

The concept was basically to make something similar to the Nanowrimo website (National Novel Writing Month for those of you who don’t hang out in writing spaces as often as I do!), but smaller and focused on the specific functionality the organizers of the contest wanted.

I launched it, the group used it, and it was great!

And then a few months later, I got a request for another version of the site for a different group to use. I spun up and hosted a new version—changing a few things like the yearly rollover of novel projects—but doing that got me thinking. Creating this site for another group required another whole instance of the site, and if I ever wanted to do this again for another group, this really wasn't efficient. If I took some time to rewrite the app's code, I could instead give users the ability to run and manage multiple contests within the same app.

With that in mind, I set out to make a version of the app that would support users creating and running their own contests, multiple if they wanted.

And that starts with project planning, which is what I’ve been doing this week!

The Notes

To start off with, I walked through some user stories—what I wanted users to be able to do with the app:

- One user story:
  - A user signs up for the app
  - They make their own contest
  - As the contest admin, they can set a date for when the contest ends, if they want it to end
  - They have/generate a link to let other people join the contest, and send that out
  - They can make other users in their contest admins too, if they want 
  - They make a novel, associate it with their own contest
  - They view their novel, and also edit it
  - With the same account, they can create, view, and/or sign up for other contests if they like as well

- Another user story:
  - A user receives a link for a friend to sign up for this app
  - They sign up for the app first
  - They enter the token to sign up for that specific contest
  - This prompts them to create a novel, and they have the option to add the novel to that contest, since they have joined the contest
 - The user creates another novel that they just want to have for themselves
    - This novel is not associated with any contest and won't show up on any contest pages

The Models

From the user stories I had come up with, I knew that I needed some complex relationships with my database models here. Users needed to be able to have many contests, and contests should also have many users. I also wanted users to be able to have different relationships to their contests—one user may be an admin of two contests, but just a member of a third, for example.

At this point, this started to sound familiar, and I realized I had come up with some very similar models for a previous project of mine, a collaborative novel writing app built in Rails. In that app, meant for online collaboration on novel projects, users had many novels through memberships, which also included a role attribute that would designate the user an admin or a regular member of the novel project.

Adjusting this a little, from novels to contests, I was in business! I also decided to change “contests” to “challenges.” Despite the original use for it being to run a novel contest, “writing challenges” is a lot more generalizable and represents more use cases for the app, so it made sense to start from here on the model level. Contests became “challenges”, and novels became “projects.”

I also wanted projects to be able to be a part of multiple challenges, but that was a simpler join table.

I used drawSQL to diagram this because it was free, visually appealing and easy to use, allowing me to drag tables around to organize things in a way that made it easier to interpret visually.

The Sketches

I did these sketches at the same time as I was diagramming my models. The sketches helped me make sure I had everything I wanted in my models, and vice versa.

The main difference I knew that I wanted on the frontend from my original app was I wanted users to be able to easily view the splash pages for multiple challenges, and also create new challenges. In addition to that, I wanted them to be able to easily view all of their projects. The layout will probably change when I get to the React part of this project, but for now, dropdown menus made sense. The project cards are taken directly from how they’re laid out in my novel contest app.

With multiple challenges, it didn’t make sense to have the challenge guidelines in the main nav bar anymore, so here I have the projects and guidelines views as two tabs on the main challenge page.

Another thing I wanted to add to this app, now that I have figured out it’s possible to update a user model without having to update the password was user pages with a bio and the user’s projects. Ideally, the user should be able to set them to private vs public so all of a user’s projects would show up for them but only “public” projects would show up for other users.

Finally, a very draft-y admin panel for challenges. I wanted users to be able to change a variety of settings, such as being able to set challenges as open/closed, public/private, and also to determine if they should have set start and end dates. This is one of the sections that is likely to change as I go along, just because there's so much functionality I could add here. Keeping minimum viable product in mind though, this is what I'm going with for now.

What comes next?

Now, with a better idea of my user stories and my models planned out, I’m ready to start building the Rails API backend for this project! More on that soon.

This project is in progress, so if you have any questions, suggestions, or feedback you’d like to leave on the project, please feel free!

Getting started in Preact (by rebuilding a React app)

Sam Markham — Mon, 30 Nov 2020 20:46:32 +0000

A few weeks ago, after reading through the Preact docs, I decided to make a version of my React writing prompt generator in Preact to get more familiar with the library.

For those who haven’t heard of it (like I hadn’t!), Preact is a small, lightweight library with a lot of similar functionality to React, other than a few key differences. Preact more closely follows DOM specifications (e.g. it allows the use of class instead of className, though both are supported), and it uses the browser’s native event system instead of a synthetic one like React does, to name a couple.

The Preact documentation states that it’s possible to move React apps over to Preact via aliasing react and react-dom to preact/compat (short for compatibility), and it has some information on how this is configured in various bundlers, but because I wanted to get more familiar with using Preact directly, I decided to start with Preact from the get-go and just move some of my code over manually instead.

This is what I did!

1. Start with the Preact CLI

Following along with the docs, I started by installing the Preact CLI on my computer, and then using it to create a new project:

npm install -g preact-cli

preact create default preact-writing-prompt-generator

The default flag here refers to the default template for the Preact CLI, available on GitHub here. I ended up having some minor issues with this set up later, but it was a good place to start because it gave me some code right out of the box that I could tinker with instead of building from scratch.

Following along with the tutorial, I spun up a development server, and then started poking around the files.

cd preact-writing-prompt-generator

npm run dev

From here, it was time to rebuild my components.

2. JSX in Preact, and alternatives

There are differences between React and Preact components, but not as many as I thought there would be going into this endeavour. Part of this is, of course, because while it doesn’t include every React feature (by design!), Preact was designed to achieve 100% compatibility with React with the preact/compat layer.

Without using preact/compat though, I still had a few options for how to set up my Preact components.

By default, React works with JSX, a syntactic extension to JavaScript that allows you to code what basically looks like HTML directly in JavaScript. Using JSX requires using a build step: the JSX code needs to be converted into JavaScript functions, which then make up the virtual DOM (used to update the real DOM).

Preact can be set up without using JSX, beneficial if you’d like to avoid a build step.

This is an example of setting up Preact to work directly in the browser, without JSX, from the Preact docs:

<script type="module">
  import { h, Component, render } from 'https://unpkg.com/preact?module';

  // Create your app
  const app = h('h1', null, 'Hello World!');

  render(app, document.body);
</script>

Preact components can also be built with Hyperscript/HTM, which is a syntax that looks similar to JSX but doesn’t require a build step (see another example from the Preact docs):

<script type="module">
  import { h, Component, render } from 'https://unpkg.com/preact?module';
  import htm from 'https://unpkg.com/htm?module';

  // Initialize htm with Preact
  const html = htm.bind(h);

  function App (props) {
    return html`<h1>Hello ${props.name}!</h1>`;
  }

  render(html`<${App} name="World" />`, document.body);
</script>

However, as I was already comfortable working in JSX from my experience with React, and as I wasn’t bothered by having a build step in this project, I decided to go with that.

Without using preact/compat though, JSX still looks a little different in Preact.

Basically, to use some more example code from the Preact docs, JSX that looks like this:

<a href="/">
  <span>Home</span>
</a>

would look like this in React when converted to function calls to build the virtual DOM:

React.createElement(
  'a',
  { href:'/' },
  React.createElement('span', null, 'Home')
);

and like this in Preact (without using preact/compat):

h(
  'a',
  { href:'/' },
  h('span', null, 'Home')
);

As far as I can tell, Preact uses a custom pragma (a “directive” that tells a compiler how to handle the input), named h by the creator of Preact because the original idea for a JSX-like builder function was called hyperscript, to do pretty much the same thing React’s React.createElement() is doing. Because this function isn’t namespaced to Preact though, it has to be imported separately.

What both of these ways of writing JSX have in common, is that they tell the transpiler (in this case it's Babel, which both React and this implementation of Preact use) that this h function should be called at runtime for each node.

3. Components

With the way I was going to write my components figured out, I could start moving them over from my React project and editing them into Preact syntax!

import { h } from 'preact';
import { Router } from 'preact-router';

import Header from './header';
import Home from '../routes/home';
import Nautical from '../routes/nautical'
import About from '../routes/about'

const App = () => (
  <div id="app">
    <Header />
    <Router>
      <Home path="/" />
      <Nautical path="/nautical"/>
      <About path="/about"/>
    </Router>
  </div>
)

export default App;

This component imports h from Preact instead of React from React, but there aren’t any differences as to how that affects this component.

It also uses preact-router instead of react-router-dom, which does feature some different syntax. For example, in React, the routes in the code snippet above would be written like this:

// note that in React, Router is called Browser Router, but it is convention to import BrowserRouter as Router
<Router>
  <Route path=“/“><Home/></Route>
  <Route path=“/“><Nautical/></Route>
  <Route path=“/“><About/></Route>
</Router>

Other than that, Preact components can pretty much look like React components!

Conclusion

Overall I really enjoyed the experience of translating the app I’d built into the Preact library! The main difficulty I ran into was figuring out how JSX worked in Preact, and that was mostly just to write this post—the Preact templates were intuitive to use even without that information. (Though on that note, thank you to Nick Taylor for sending me this article, which helped a lot!)

The other stumbling block for me was that the file structure in the Preact CLI was quite different from what I’m used to setting up for React projects. As far as I can tell that was specific to that template though, not related to the library itself, and I was still able to figure it out quite quickly even if it isn’t how I would usually set up my own project.

I hope this post is useful to anyone else thinking of trying out Preact, and if you have questions, comments, or suggested corrections, please let me know in the comments!

Building a writing prompt generator with functional React

Sam Markham — Wed, 09 Sep 2020 02:13:42 +0000

As well as a dev, I’m a fiction writer, and sometimes I run out of ideas for what to write. A couple of weeks ago this gave me an idea for what to code—a writing prompt generator!

There are a lot of these out there, of course, but making one myself was fun, and as my previous React app was made with mostly class components, for this project I took the opportunity to get more familiar with function components in React along the way.

This post will walk through how I set this up! It assumes some familiarity with React as a library.

1. Multiple generator pages

The first thing I wanted to accomplish with this generator was allowing the user to generate prompts from multiple sets of words, with different pages for each set of prompts. To this aim, I created two prompt page components and one generator component that could be rendered with a different set of props in each of them.

import React from 'react';
import Generator from './Generator';
import {words} from '../assets/words';

const WordsPromptPage = () => {
  return (
    <div>
      <p>Write 250 words about:</p>
      <Generator dataset={words}/>
    </div>
  );
}

export default WordsPromptPage;

Here the WordsPromptPage component is rendering a Generator component with a dataset of words, which is an array in a separate file. I could have made a database for different types of prompts, but I decided to keep them in asset files on the frontend instead to be able to host the generator more simply as a frontend on Netlify instead of hosting a backend and frontend separately.

2. Navigation

To switch between different generator pages (and my about page) in the app, I used react-router-dom in the main App component so that when the URL changes, the component shown changes too.

import React from 'react';
import './App.css';
import WordsPromptPage from './components/WordsPromptPage';
import NauticalWordsPromptPage from './components/NauticalWordsPromptPage';
import {
  Switch,
  Route
} from 'react-router-dom';
import NavBar from './components/NavBar';
import AboutPage from './components/AboutPage';

function App() {
  return (
    <div className="App">
      <NavBar/>
      <h1>Prompt Generator</h1>
      <Switch>
        <Route exact path="/nauticalwords"><NauticalWordsPromptPage/></Route>
        <Route exact path="/about"><AboutPage/></Route>
        <Route path="/"><WordsPromptPage/></Route>
      </Switch>
    </div>
  );
}

export default App;

I used Switch here because I want only one matched Route to render and Switch renders a route exclusively—I don’t want users to be able to type in /nauticalwords and have WordsPromptPage and NauticalWordsPromptPage both render on the same page because /nauticalwords matches both /nauticalwords and /.

Switch is below the heading and the NavBar component so that while part of the page will change according to the URL, the heading and navigation will always render.

In the NavBar component, I put the links to these different routes:

import React from 'react';
import { Link } from 'react-router-dom';

const NavBar = () => {

  return (
    <nav role="navigation">
        <Link className="nav-link" to="/">Words</Link>
        <Link className="nav-link" to="/nauticalwords">Nautical Words</Link>
        <Link className="nav-link" to="/about">About</Link>
    </nav>
  );
}

export default NavBar;

3. Function components

The last app I built with React I used mostly class components—the function components I did use were simple presentational components: components mostly concerned with how things look, often (and in my case) written as stateless function components. When I needed to deal with state, I stuck with class components.

For this project, I wanted to start getting more familiar with function components, specifically using hooks to be able to deal with state in function components.

According to the React documentation, hooks are “functions that let you 'hook into' React state and lifecycle features from function components… they let you use React without classes.”

For my generator component, I used useState to return a prompt variable and also a setPrompt function to let me update the prompt.

import React, { useState } from 'react';

const Generator = (props) => {

  const [prompt, setPrompt] = useState(“Click to generate a prompt!”)

  const generate = () => {
    return props.dataset[Math.floor(Math.random() * props.dataset.length)];
  }


  return (
    <div>
      <p id="prompt">{prompt}</p>
      <button onClick={() => setPrompt(generate())}>Generate</button>
    </div>
  );
}

export default Generator;

The initial state here was set to the string, “Click to generate a prompt!”, and on button click, prompt is set to the return value of the generate() function.

After getting this set up though, I realized it would be a better idea to have the site load with a random prompt generated as well, and I could probably use useState to do this too.

import React, { useState } from 'react';

const Generator = (props) => {

  const generate = () => {
    return props.dataset[Math.floor(Math.random() * props.dataset.length)];
  }

  const [prompt, setPrompt] = useState(() => generate())


  return (
    <div>
      <p id="prompt">{prompt}</p>
      <button onClick={() => setPrompt(generate())}>Generate</button>
    </div>
  );
}

export default Generator;

As long as the generate() method was declared before useState was set up (because JavaScript doesn’t hoist function expressions), I could set the initial state for prompt to the return value of generate() as well, so that the app would have a newly generate prompt on loading and on refresh.

Conclusion

I had a lot of fun building this app, and it was a good way to spend a few days familiarizing myself with function components, as well as spending more time with React after a break away from it! I look forward to diving deeper into functional React in the future—and expanding the types of writing prompts in the generator!

6 things I learned from building my first app for a client

Sam Markham — Mon, 17 Aug 2020 22:52:50 +0000

Recently I built my first app for a client.

A friend of mine who runs a novel-writing contest had mentioned earlier this year that she really liked my last app, and that she wanted to do something similar for the contest at some point, so when I was looking at building a React app in April, I offered to build one for her.

It was a wonderful opportunity to code something fun and writing-related (I am a novelist in my other life), and the fact that it was in use right after I finished was a bonus!

This is what I learned in the process.

1. Set expectations

The first thing I did, even before offering to build the app, was had a conversation with my potential client about what she was looking for and whether that aligned with what I felt I would be able to make with my current skill level—and in a reasonable amount of time. I wanted to make sure I wasn’t committing to do something that either I wouldn’t be able to do, or that wouldn’t meet her requirements.

After this initial conversation, I also wrote out a list of specific website features in plain terms that corresponded to how I would have to set up the code, and then asked my client to confirm, correct, or add to this list. This helped give her an idea of what types of details I needed to know, and when she added to the list, gave me an idea of what exactly I needed to build!

The initial list:

- Secure user sign-up/login 
- User has many novels (to make reusable for future years if necessary!) 
- Novels include info like: title, summary, word count 
- Badges that can be dragged over (or turned on or something)  
- Word count tracker 
- Should there be a section for users to see some things about each other, like number of folks participating, etc? 
- Some sort of calendar function for days past/days left? (Not sure about setting this one up) 
- About page/drop down with a bit of info on what this is/how this works  
- Admin access for you to change some things

Making sure my client and I were on the same page about what I would and wouldn’t be doing with this app was essential to keeping things moving smoothly and efficiently down the road.

2. MVP

Speaking of expectations, a minimum viable product is also a useful thing to keep in mind, especially for building something for someone else.

Before I began work on the app we also discussed what features were necessary to launch the app and what features could be added on later, or if I had time. This meant I had a clear checklist of features to work from while keeping in mind other things that could be useful for this project in the future.

3. Cultivate the ability to explain your code to a non-coding audience

Early in the process of building my novel progress tracking app, one of the features my client asked for was a word count tracker that let users edit their word count for a specific day and involved a graph to display writing progress over time—something like what the Nanowrimo (National Novel Writing Month) website, which inspired some of my functionality, used.

(Screenshots from my Nanowrimo progress in 2017)

This was something that seemed simple from a non-coding perspective but actually would have significantly increased the complexity of this part of the project.

In the database, I had initially set the novel model to have one wordcount attribute, which users can update on the frontend. Nanowrimo, a 30-day contest, has 30 different wordcount-type attributes, one for each day, and because the contest I was designing the app for ran all year, this would involve creating 365 different wordcount attributes for each novel.

In addition to increasing the amount of data each novel would have to hold, a year’s worth of wordcount attributes would mean finding a visually appealing way for the user to edit each of them—a simple list of that many days wouldn’t cut it.

Though this was completely doable, it would take more time, and the client was eager to have the website up and running.

When altering the word count tracker came up as a requested feature, my ability to explain how much coding work this would be in plain terms—that it would be more like adding an extra feature than making a slight change to an existing feature—meant that my client understood why this was something that couldn’t be added to the first version of the app while keeping the short turnaround time. As a result, she was happy to include this feature on the list of stretch goals instead.

4. Mock-ups help

Even though I only did a quick sketch of what I was thinking the web app would look like, I found this was a great way to get on the same page with my client about what I was building for her. It was also a handy thing to work from when I was building functionality!

5. Working to a deadline is challenging and rewarding

This is one I already knew on some level—my coding projects previous to this one had all been completed in two weeks, these deadlines set by my bootcamp, but while these projects had to pass a certain amount of requirements in that time, they didn’t have to be completely finished and deployed by then.

For this app, I agreed with my client on a deadline of four weeks to have the app deployed and ready for users.
 
Also, I decided that in addition to building a finished React app with the functionality we had agreed on, I needed to add forgot/reset password functionality by this deadline to prepare for real users. This was something I had never done or even researched before—and so was deploying the app, both frontend and backend, for that matter. But I do love a challenge. I buckled down, did a lot of reading, watching videos, and fixing errors in my code, and on the evening of the deadline, my app was deployed and ready for users.

Overall I found the experience very rewarding: having a reasonable deadline meant something to push myself toward, and the final result of being able to reach the goal set for me was a wonderful feeling.

And speaking of:

6. Seeing your work in use is really satisfying!

Deploying an app for immediate use by multiple users was a great opportunity to think about what was actually needed for user functionality in an app, and also to work with a specific use case that already existed. And the end result of seeing other folks using something I’ve built has reaffirmed why I’m a software engineer in the first place: to solve problems, and to build useful things.

(The version of this app in use by the contest is private; this is a screenshot of my demo deployed with the same code!)

Going forward armed with this experience, I look forward to building many more apps for clients in the future!

Vertical project planning for a Vanilla JavaScript/Rails app

Sam Markham — Sun, 12 Jul 2020 04:59:53 +0000

When I was building my PokéTeamBuilder JavaScript/Rails API app, one suggestion I heard from my bootcamp was that to make things easier on myself, I should build my project out vertically instead of horizontally. It took me a while to really grasp what this meant, but when I did, it was very helpful to me for planning this project, and also as a project to-do list as I continued to add new features!

The Concept

If you plan your projects horizontally, which in this case means: planning all of your database models, then doing all of your database migrations, then all of your controller actions, then all of your data fetching on the front-end, etc, you're likely to have to go back and redo things, because you're probably not going to be able to guess everything all of your features need to do up front!

Vertical planning, in this case, means starting with one feature and taking it all the way from model to styling, and then moving on to the next thing. Working on my project, I wasn't able to apply this perfectly in practice, but that didn't matter--it still made a wonderful frame to work from, and made the work of setting up something with this many features a lot more manageable!

The Example

The goal for my PokéTeam builder app was to have an app that would let a user select 6 Pokémon and a Trainer Sprite, move them around on the screen after they appeared, and then then take a picture of the team for posterity.

There were a lot of moving parts here, but the first feature I started with was the Pokédex--I needed a drop-down menu with all of the available Pokémon that would be in the app for the user to select from them to make instances of individual Pokémon to drag around.

After making a new Rails API with rails new poketeam-builder-api --api, I:

Set up the model
Wrote the seeds file to get the data I wanted from the existing PokéAPI
Set up the controller actions
Wrote a fetch request on the front end to get this data into the view
Dealt with the view logic--in this case, getting all possible Pokémon from the Pokédex to show up in six dropdown menus.
(I did not deal with the styling until after the project, but, using this method, I really could have dealt with it here if I had been feeling less pressed for time!)
Moved on to the next feature: allowing users to create an individual Pokémon to move around the screen.

This is what (part of) my to-do list looked like for this project--I highlighted boxes yellow once I had finished something.

Not everything is included here because I had more columns than would fit in this screenshot (the user model was next!), but this was the gist of it. Using this way of thinking through my project, I was able to save myself a lot of time and headache figuring out what to do next, and I'm really happy with how the final (for now!) app turned out.

I hope this is helpful as an illustration of the method for anyone interested in trying it out!

(The current version of the app!)

A social media strategy for folks afraid of social media

Sam Markham — Fri, 26 Jun 2020 19:33:35 +0000

I'm not sure why, but I really don't like posting things on social media. I find the idea of it stressful, and sometimes sort of scary! Usually the advice I hear at this point is to just avoid it, or to pick one you like and do it well, but, since I've gotten serious at looking for my first developer job, I have realized I really can't avoid social media completely. And, even though it's not exactly necessary*, it would probably be helpful for me to be on more than one platform.

So, last week I started to troubleshoot this. If I couldn't avoid social media completely, I needed to find some way to engage with it that I was comfortable with.

So what did make me uncomfortable with social media? I still haven't quite figured this one out, but thinking more deeply about it made me realize I wasn't uncomfortable with all social media, or with all kinds of posts either. This seemed like a good place to start. What kinds of things made me really uncomfortable, versus what kinds of things did I feel better about, and how could I work within this?

I started by thinking about what sorts of things I usually post on the social media I do use (mostly cat pictures), and then, working from there, made a chart to nail this down further:

This was a start! It skewed more heavily towards detail in things I'm (mostly) fine posting about, but that's because that's what I really wanted there: ideas for (coding-related!) things to post about on social media. The other important part of this process for me was to take certain things off the table. For example, if posting about things that are too personal makes me uncomfortable? Fine, I could put it in the "nope" column and then stop worrying about it.

From here, I made a list of relevant things I could post about, and on what platforms, to give myself a more specific idea of what to do going forward. Another thing that makes me reluctant to post is uncertainty about what I'm going to post, so the goal was to take that off the table.

My list:

technical blog posts (Dev.to, with cross-post to Twitter and LinkedIn)
posts highlighting coding projects (Dev.to, Twitter, LinkedIn)
challenges like #100daysofCode (Twitter, possibly blog about experience and cross-post)
answering code questions (Twitter, Dev.to)
engaging on coding-related posts (Dev.to, LinkedIn, Twitter)

And that's it! So far. The next step, of course, is to increase the frequency of all of these things, and to test my theory that I'll be able to do this without spending too much time worrying about what I'm posting--my usual stumbling block. And then, of course, analyze, reiterate, and test again.

The steps again, for anyone else interested in trying this:

Think about what makes you uncomfortable about engaging with social media
Make a chart of types of engagement that make you more/less comfortable
Make a list of comfortable/mostly comfortable things to have on hand for when you're telling yourself 'I need to post something' but are stuck on the pressure of doing it
Probably have some sort of schedule for creating content (that one is a work in progress for me!)

I hope this is helpful to anyone else trying to push themselves in this direction! (And, just for fun, here is another picture of my cat!)

*Seriously, I have heard from many folks who know a lot more than I do that if you're not going to do the social media thing you might as well just not have it, as long as your online presence is consistent and professional and doesn't have abandoned handles, but, I am trying this anyway!

6 things I learned from my first mock technical interview

Sam Markham — Thu, 18 Jun 2020 21:24:25 +0000

Since finishing my software engineering bootcamp at Flatiron School last month, I've spent the bulk of my coding time getting ready for the job search, and last week that involved doing a mock technical interview through Skilled.

Despite reading all I could find about technical interviews, and going through whatever concepts the program and the articles I could find said to study, I wasn't quite sure what to expect.

Post-mock interview, these were my biggest takeaways:

1. Talk/write your way through it
One of the things my interviewer mentioned I did well in the interview process was that I understood what was being asked of me. I was able to convey this understanding by talking through the problem out loud and also writing down the steps of what I wanted my code to do. All I have read about technical interviews says that interviewers want to know about your ability to problem solve, and your process, and this was definitely my experience!

2. Knowledge of algorithms and data structures is helpful even when you're not asked about it
In preparation for my technical interview, I spent a lot of time studying things like different data structures, Big O Notation, and algorithms I hadn't encountered much of during my course but were recommended knowledge for interviews.

I didn't get asked about any of this directly during my technical interview--I had the whole hour to solve one (complicated!) JavaScript problem--but it was relevant anyway.

At one point, I came across part of the problem where I could have dealt with things by split()-ing a string into an array, altering each element separately, and then join()-ing them together as a string again. I decided not to, because that would further increase the algorithm complexity, and found a way to alter the string while keeping it a string instead.

When I explained this reasoning to my interviewer, they said it was a point in my favour: that I coded that part of the solution in a way that didn't increase algorithm complexity further, but also that I did it deliberately and knew why that choice was a good idea.

3. Find out in advance what the interviewer's policy is on asking for help/using the documentation)
Where I started to get tripped up in my interview was when I reached the point of the coding problem where I would usually think, "ehhhhhh drat I know there is a function that does this, I am going to google and find out what it is." I asked my interviewer if it was alright if I looked up the documentation, and they let me know that was fine, or I could just ask them. This was a big help in progressing through the interview, so I'm very glad I asked! With that said:

4. Stick to what you know (and brush up on your functions!)
I spent a lot of time during my interview trying to remember the right function to solve the problem, because I knew there was one, and it just wasn't coming to mind. While this was true, there were better functions than the ones I was using, trying to remember these functions wasted valuable time, and, as my interviewer later pointed out to me in feedback, it would have been fine to say "I know there are better functions to use in this situation but I'm just going to do this for now." So, there are two other key things here:

5. Prioritize
The interviewer wants you to solve the problem in front of you, or at least as much of it as you can. Another way I stumbled in my interview was spending too much time trying to figure out the specific right way to solve one part and not leaving enough time for the rest of the problem. Pausing to think more about what was important in the problem, and maybe a, "let's assume I have a helper function that does this" would have saved me a lot of time in my interview. And, finally:

6. Be confident (/you are a job seeker, not a student)
The main thing I forgot during my technical interview was: I'm not a student anymore. As a student it's alright to say, "I know there's a better function for this, can you remind me of what it is?", but as a job seeker, you need to project confidence. Focus on the parts of the question in front of you that you can solve, use methods you're confident with--overall, employers want to see your problem solving skills but they also want to know you can handle yourself without handholding. It's okay to admit to not knowing something if asked directly, or if it comes up, but overall, you'll look like a much stronger interview candidate if you can solve the problem in front of you showing off what skills you do have (and what things you do remember) instead.

During my mock technical interview I learned a lot of valuable information about what to do and what not to do during the real thing, and I have spent the past few days putting my skills to the test finishing my solution to the problem I was given during the interview--and then solving it again in a better and more efficient manner. (It was a tough one!)

The one thing I wish I did more of before the interview itself?

Practice, practice, practice!
As well as studying up on algorithms, data structures and functions/methods of whatever language you're interviewing in, a good way to prepare for a technical interview is to practice solving problems in that language. CodeWars has been helpful to me so far, I have heard good things about HackerRank and CodeSignal, and there are many others out there.

I hope this is helpful to anyone else looking at starting interviews, and good luck!

Follow-up: deploying Forgot/Reset Password (React/Rails app)

Sam Markham — Mon, 15 Jun 2020 19:28:40 +0000

(originally posted May 22, 2020)

In my recent post on forgot/reset password functionality, I explored setting up a forgot/reset password function with a Rails backend and React frontend, and in my post on deploying this project with Netlify and Heroku, I focused on what it took to get the app up and running in production, but there wasn't really room for getting into what that meant for my forgot password functionality. This is what I'll explore here.

Assuming everything is set up so your forgot/reset password function works in development, and assuming everything else works in deployment, there are only a few changes to make to your app to get the forgot/reset password function working in production. Testing this was the last phase of making sure my Novel Tracker app worked in production--I needed to make sure future users would be able to reset any forgotten passwords successfully before I let the novel contest know the app was ready for use!

*On the backend *

First, in the Rails API, there are some settings to be added to config/environments/production.rb:

  config.action_mailer.perform_caching = false

  config.action_mailer.perform_deliveries = true
  config.action_mailer.raise_delivery_errors = true


  config.action_mailer.delivery_method = :smtp
  host = ENV["PRODUCTION_URL"]
  config.action_mailer.default_url_options = { host: host }

  # SMTP settings for gmail
  config.action_mailer.smtp_settings = {
    :address              => "smtp.gmail.com",
    :port                 => 587,
    :user_name            => ENV["GMAIL_ACCOUNT"],
    :password             => ENV["GMAIL_PASSWORD"],
    :authentication       => "plain",
    :enable_starttls_auto => true
  }

These are all of my settings in this file that have to do with config.action_mailer. Most of these should be the same as what you have in config/environments/development.rb except for these two:

  host = ENV["PRODUCTION_URL"] 
  config.action_mailer.default_url_options = { host: host }

The host is no longer localhost:3000, it is whatever your production URL is.

(For more information on set up with Action Mailer and Gmail, see this article.)

On Heroku

Once production.rb is set up, the only other thing that needs to be configured is the environment variables in Heroku, referred to there as config vars. Navigate to your app on Heroku, go to the settings tab, and add these variables in the config vars section:

PRODUCTION_URL: https://your-app-api.herokuapp.com
GMAIL_ACCOUNT: your.app.gmail.account@gmail.com
GMAIL_PASSWORD: yourgmailapppassword

The PRODUCTION_URL, your app's URL on Heroku, is the host for Action Mailer, and your GMAIL_ACCOUNT and password are whatever email address you want your app to send the reset password emails from. The GMAIL_ACCOUNT and GMAIL_PASSWORD can be the same variables in development and production, but, as Heroku can't access your environment variables in the .env file listed in your .gitignore, you need to provide them to Heroku directly as config vars for them to work in production.

Along these lines, we need to add one more config var to Heroku to get everything working:

RESET_PASSWORD: https://your-app-frontend.netlify.app/reset_password

This is a link to the reset_password page/component in your Netlify app, and Heroku needs to know about it because it's what will be sent out to users in reset password emails. But, there's one final thing that needs to be fixed to get this link working.

On the frontend

React uses client-side routing, which means, basically, it makes one request to the server to grab everything when you first navigate to the app, and after that, when clicking a link made with react-router-dom, the URL changes locally, and so does the component being displayed, if you've set things up that way--no other request to the server is fired.

There are multiple workarounds to this, many of them detailed here, but if you're using create-react-app and Netlify, there's an easy one that works for at least some components.

Create a public/_redirects file in the main directory of your front end app, and include this code in it:

/*  /index.html  200

(Source)

This will enable users to navigate directly to your /reset_password link, and any other links (at least in my project) that don't use conditional rendering to only allow logged-in users to see them.

That's it!

This is everything I did to get this part of the app working! There are other tutorials on all of this out there that I've found very useful, but this concludes my series of blog posts on this particular use case, to help myself remember what I did and in case anyone else finds these specific steps useful! (And this is the demo version of the app in question, for any readers who wants to see some of it working on the frontend!)

Deploying a React (with Redux)/Rails app with Netlify/Heroku

Sam Markham — Mon, 15 Jun 2020 19:18:09 +0000

(originally posted May 15, 2020)

My final Flatiron School project was made for use by an online novel contest, and after the project deadline, I set my own deadline of when I told the contest's organizer I would have the live website up by. This led to a lot of quick research and troubleshooting how to get a React/Rails app hosted, and another two weeks after submitting my final project, I had it up! The experience of seeing something I made in use has been very gratifying, and this blog post is an overview of what worked for me, in case it helps someone else!

Initial set-up

To start off, my app is built with React.js, Redux, and Rails 6. I built the front-end in a project-name-frontend folder with create-react-app and the backend in a project-name-backend with rails new project-name-api --api --database=postgresql. The frontend and backend are both hooked up to separate github repos. I'm also working off a Mac. This blog post will assume you have a similar setup in order for it to work as a tutorial!

To hook up your Rails backend to Heroku, it is important it use Postgres instead of SQLite3 (the default) as a database. Adding the --database=postgresql takes care of a lot of the set up within your Rails project if you include this when you're building it, but I found this article helpful too for getting Postgres installed on my machine. You can skip a few of the steps if you start your Rails project setting the database to Postgres, but the rest of it still applies.

Deploying the backend

Alright, so you've built your React/Rails project, you have a Postgres database in Rails, everything is working in development, you're ready to deploy!

The first step is getting your backend up on Heroku. Start by making an account on Heroku, and then navigate to this tutorial. It will prompt you to install the Heroku CLI, log in on the command line with heroku login, and then configure your config/database.yml file.

What is on the tutorial works for this, but there is a lot of text there, so for simplicity's sake, this is what worked for me:

default: &default
  adapter: postgresql
  encoding: unicode
  username: <%= ENV['POSTGRES_USER'] %>
  password: <%= ENV['POSTGRES_PASSWORD'] %>
  pool: 5
  timeout: 5000
  host: <%= ENV['POSTGRES_HOST'] %>
development:
  <<: *default
  database: <%= ENV['POSTGRES_DEVELOPMENT_DB'] %>
test:
  <<: *default
  database: <%= ENV['POSTGRES_TEST_DB'] %>
production:
  <<: *default
  database: <%= ENV['POSTGRES_DB'] %>

Now, this relies on some environmental variables. You should have these in an .env file and that .env file added to your .gitignore so it won't show up when you push to github.

For example:

POSTGRES_USER='username'
POSTGRES_PASSWORD='password'
POSTGRES_HOST='localhost'
POSTGRES_DEVELOPMENT_DB='app_name_development_db'
POSTGRES_TEST_DB='app_name_test_db'
POSTGRES_DB='app_name_db'

Next, to deploy your app on Heroku, make sure you're in your project-name-backend directory and type heroku create. It should say something like:

Creating app... done, radiant-sierra-11874
https://radiant-sierra-11874.herokuapp.com/ | https://git.heroku.com/radiant-sierra-11874.git

(source)

Following along with the Heroku tutorial, you can check that the remote was added to your project correctly by typing git config --list | grep heroku. If you see fatal: not in a git directory you're not in the right directory.

Otherwise, type git push heroku master to deploy your code. This will give you a long block of text, including some warnings at the end you might want to debug.

If everything goes well there, you can migrate your database, and seed it if applicable:

heroku run rake db:migrate
heroku run rake db:seed

This is an abbreviated run through that pulls out the specific steps from Heroku's "Getting Started with Rails 6" article that worked for me, but I highly recommend the full article for more detail here.

If all of this is working, you can visit your Heroku dashboard to see your app.

In the settings tab, you can change the app's name:

And in the deploy tab, you can connect your app to your Github repo so pushing changes there will push changes to the live Heroku app as well:

Deploying the frontend

We'll get back to the backend later, but the next step to getting this app hooked up is deploying your React app through Netlify. It's possible to do the frontend through Heroku too of course, but I like Netlify for the frontend because it loads right away when you navigate to it. In the free version of Heroku, your server sleeps when it hasn't been pinged for a while, so hosting your frontend on Netlify will show your user the front page of your site right away while Heroku gets the backend up and running in the background. (With that said, I recommend using a fetch in componentDidMount on your React app's App.js component, or whatever else loads first, so that the Heroku server gets booted starting from when a user first gets to your site.)

To get started with Netlify, create an account then click to "New Site from Git". Clicking on "Github" from the list of options will let you search your Github repos for project-name-frontend. The settings on the next page are fine, you can go ahead and "Deploy site" from there. Netlify has a blog post with an overview of this process, featuring more screenshots, that I found helpful as well!

Once your Netlify app is up and running, you can change its name in the "General" section of settings, and then navigate to the "Build and Deploy" tab. Make sure the site is set up for continuous deployment, the first section there, and then scroll down to environment.

Set an environment variable with a key of something like this: REACT_APP_BASE_API_URL, and set the value to the URL of your new Heroku app.

The thing that I found when deploying my app is: running it on my local server in development, it uses environment variables from my .env file. Running it in production from Heroku and Netlify, the frontend and backend apps don't have access to any of these variables, so they have to be set through the Heroku and Netlify dashboards. This is actually great, because it's an easy way of making sure your frontend fetches from localhost:3000 (or whatever port your backend is on in) in development and from project-name-backend.heroku.app in production, but it takes some configuring.

In project-name-frontend, go into all of your files that make fetch requests. Change your base URL for these fetch requests to this:

const baseURL = process.env.REACT_APP_BASE_API_URL

In React apps, environment variables are accessed through process.env, and if you've made your app with create-react-app, all environment variables need to be prefaced by REACT_APP_ to work properly. (More information here!)

From here, make an .env.development file in your project-name-frontend directory, add it to your .gitignore file, and add this environment variable there:

REACT_APP_BASE_API_URL='http://localhost:3000/'

This should enable your frontend to properly fetch from your backend, from the local server in development and your heroku app in production!

But, there's a problem here--the backend doesn't know to accept requests from your Netlify frontend yet! We have to go back and do more configuration there.

A note about Netlify:

Before I go any further, I want to briefly mention that while Netlify loads faster than Heroku when first navigating to the live site, Netlify is definitely slower than Heroku to update after you've run git push and pushed changes through to it. I ran into a lot of issues debugging in deployment just because Netlify hadn't loaded the (working!) update I'd made to my code yet.

So if you are refreshing your Netlify frontend to see if something has worked, you might need to wait a few minutes for the update to take!

More backend configuration

Assuming your app was working in development before this, you should have your /config/initializers/cors.rb file configured. The cors file is where we tell the backend what requests to accept, so this is what needs to be reconfigured to get the Heroku app to accept fetch requests from the Netlify app.

Rails.application.config.middleware.insert_before 0, Rack::Cors do
  allow do
    origins ENV['FRONT_END_URL']

    resource '*',
      headers: :any,
      methods: [:get, :post, :put, :patch, :delete, :options, :head],
      credentials: true
  end
end

Setting the cors file to allow origins ENV['FRONT_END_URL'] means it will allow requests from whatever that environment variable is set to in .env in development, and whatever that environment variable is set to on Heroku in production.

Add this line to your .env file (assuming you've set your port to 3001 on the frontend like I did):

FRONT_END_URL='http://localhost:3001'

On the Heroku dashboard, go into settings, down to Config Vars, and create a new FRONT_END_URL config variable and set it to your Netlify app URL.

Remember, modifications to the cors.rb file mean you need to restart your Rails server on the backend, and also, the change may take a minute or two to take effect in your Heroku app file too.

But, this is it! Both apps have been deployed, and should be working properly!

The Redux issue

Or, so I thought until I proudly sent the link to my website to the novel contest's organizer only to hear my beautiful app was only showing a blank page. Some poking around on my end trying to pull up the app in different browsers revealed I had the same problem too: the app was only displaying properly in Chrome.

Eventually I figured it out: Redux Devtools, which were amazingly helpful while putting together my app, somehow meant that the app wasn't visible for any browser that did not have the devtools installed. I'm sure there's a way of configuring this so the devtools are included in development and not in production, but facing a deadline, I just removed them and everything worked fine.

My code for creating my Redux store went from this:

const store = createStore(rootReducer, compose(applyMiddleware(thunk), window.__REDUX_DEVTOOLS_EXTENSION__ && window.__REDUX_DEVTOOLS_EXTENSION__()))

to this:

const store = createStore(rootReducer, applyMiddleware(thunk))

And everything worked!

I hope this is helpful to anyone else looking to deploy React/Rails apps!

Forgot/Reset Password functionality with Rails and React (and Redux)

Sam Markham — Mon, 15 Jun 2020 19:11:31 +0000

(originally published May 6, 2020)

For my final project with Flatiron School, I have been building an app that tracks novel writing progress for novel contests. I have actually built it for a specific novel contest, so throughout coding it, I knew my goal once I had finished the basic functionality was to deploy it for use.

The biggest thing that stuck out to me as necessary for this was forgot/reset password functionality. I could do an admin controller later, fix my styling later, et cetera, but if I had live users and they were forgetting their passwords, this would be a problem.

Many hours later, I had done enough research and trial and error to build a solution.

Before I get into it, a bit of a disclaimer--if you're logging in users through a Rails API backend, this is really a Rails issue. There are a few good tutorials on how to do this functionality with only Rails already. I drew heavily from them for my solution (and will link them later!), but what I wasn't able to find was something incorporating React to do this. Honestly, there are good reasons for this, which I will get into later! But, if you are looking to use Rails only for the backend of password resets and React with Redux for the front end, read on!

In the Rails API:

First, some routes:

  post 'api/v1/forgot_password' => "api/v1/passwords#forgot"
  post 'api/v1/reset_password' => "api/v1/passwords#reset"

There are two routes here because first you want the user to be able to submit their email through a forgot password action that will send a code to their email to start the process, and then once they have the code, you want them to be able to use it to submit their new password.

Next, the user model needs a couple new columns. Whether you set this up through adding them after the fact or putting them directly in the original migration, they should look like this in your schema:

    t.string "password_reset_token"
    t.datetime "password_reset_sent_at"

Then you need a new controller:

class Api::V1::PasswordsController < ApplicationController
  def forgot
    user = User.find_by(email: params[:_json])
    if user
      render json: {
        alert: "If this user exists, we have sent you a password reset email."
      }
      user.send_password_reset
    else
      #this sends regardless of whether there's an email in database for security reasons
      render json: {
        alert: "If this user exists, we have sent you a password reset email."
      }
    end
  end

  def reset
    user = User.find_by(password_reset_token: params[:token], email: params[:email])
    if user.present? && user.password_token_valid?
      if user.reset_password(params[:password])
        render json: {
          alert: "Your password has been successfuly reset!"
        }
        session[:user_id] = user.id
      else
        render json: { error: user.errors.full_messages }, status: :unprocessable_entity
      end
    else
      render json: {error:  ['Link not valid or expired. Try generating a new link.']}, status: :not_found
    end
  end

end

For my app, I have the passwords controller namespaced under Api::V1, but this is just preference. As long as the namespace is the same in the route and the controller (and the controller is under the proper Api and then V1 folders, if applicable), it'll work.

A lot of this code is drawn from these tutorials (one, two), so I won't get too deep into specifics, but I recommend reading them if you're deploying this to get a better understanding of exactly what's going on!

Briefly, the important thing about the forgot action is that you're finding the user by the email param that the user has submitted through a form (we'll get there), and then sending an email regardless of whether the email is in the database for security reasons, but letting the user know about this so they don't spend forever waiting for an email only to realize later, oh no that was the wrong email I put in. When testing this, I recommend having different alerts for each case so you know which is which, but for deployment, this is what worked for me.

The reset method is searching for a user by their email and the password_reset_token that firing the forgot action sets on their account. This is a deviation from the tutorials I used for this part, and I'll get into why later. If the user exists and their token is valid, then the password reset fires, and if that works, they're also logged in by setting the session[:user_id] to their id. If the token is expired, or doesn't exist, or there's no user by that email, an error is rendered.

Of course, to make this work we need some methods on the user model!

class User < ApplicationRecord
  ...
  has_secure_password
  validates :password, length: { minimum: 5, wrong_length: "Password must be at least 5 characters." }, if: :password

...

  def send_password_reset
    self.password_reset_token = generate_base64_token
    self.password_reset_sent_at = Time.zone.now
    save!
    UserMailer.password_reset(self).deliver_now
  end

  def password_token_valid?
    (self.password_reset_sent_at + 1.hour) > Time.zone.now
  end

  def reset_password(password)
    self.password_reset_token = nil
    self.password = password
    save!
  end

  private

  def generate_base64_token
    test = SecureRandom.urlsafe_base64
  end

end

send_password_reset sets the user's password_reset_token attribute to a randomly generated token, sets the password_reset_sent_at to the current time, and then after saving these to the user, sends an email to the user that will include this token and further instructions. More on that soon! The password_token_valid method checks if the token has been sent within the hour--if it's been longer than an hour, the application won't accept it. This sort of thing is personal preference, I've seen it set to longer than an hour, but I went with a shorter time window for extra security because some of the React implementation is a bit lower security compared to some other ways of doing this. The reset_password method sets the token to nil so that once it's used once to reset the password it can't be reset again, and it changes the user's password to whatever they entered in the form.

The password validation line is important--without this you won't be able to set the password_reset_token and password_reset_sent_at. For more information on why, I have a separate blog post on that here.

The next thing to get set up is the Mailer functionality. First we need to generate a mailer:

rails g mailer user_mailer password_reset

This will create a user_mailer.rb file under mailers, and two views for the password_reset email. This code goes in UserMailer--it's the method you're calling in send_password_reset:

class UserMailer < ApplicationMailer

  def password_reset(user)
    @user = user
    mail to: user.email, subject: "Password Reset"
  end

end

The two views generated with the terminal command are really just html and plain text versions of the same email, and your code for both of them should be the same other than that one can use html tags.

Hi <%= @user.name %>,

You are receiving this email because you have requested a password reset for your Novel Tracker account.

Please use this code to reset your password: <%= @user.password_reset_token %>

This code will expire one hour from password reset request.

To reset your password please enter your code in the form here: http://localhost:3001/reset_password

If you did not request your password to be reset please ignore this email and your password will stay as it is.

You can use ERB tags to put in the user's name (or username, if your app uses that instead), and, importantly, the token.

This is where my code diverges a little. This tutorial shows how to create a reset password view, and, even though the example there is done in a Rails-only project, many single page applications are not completely single page, and do something similar to this too--a reset password view through the API, and the rest of the app through the front end.

Because I'm stubborn, and because I didn't want to figure out how to style a page rendered through Rails the same way I'd styled my React frontend, I decided to try to figure out how to do this through React instead. This led to a few specific choices here:

One: exposing the password token in the email instead of including it as part of a dynamically generated link for the user to follow. Some apps do have both options, but mine only has one, because I wanted it to happen through a static link in React. This is because React is a bit strange about links. Well, not strange, but because it uses Client-side routing instead of Server-side routing, basically all of the app's content loads on the initial GET request to the server, and all of the routing from then is moving around within pages that are already downloaded from the beginning.

There are ways around this--this stack overflow thread gets into some. The specifics of figuring that out is beyond the scope of this blog post, but for my app, I have configured things so that any links a user doesn't need to be logged in to access can be navigated to by typing in the URL manually, and everything else (that requires a check for a logged in user) can't be. If you're going to use the way of doing things I'm outlining in this blog post for your project, make sure this is possible in your app!

Two: including a link to the reset password page. As previously described, if you can get it to work for your React app, it will be cleaner to do it this way and a bit more secure to have it not linked to from your front end.

Having a static link to a reset password page does, however, make things a little less secure. This is why I have configured mine to require both the correct token and the matching user email in order to reset a user's password.

Alright! The next step is configuring your settings so the mailing itself will work. REMEMBER: WHEN YOU CHANGE THESE SETTINGS, RESTART YOUR SERVER AFTERWARDS! I am embarrassed to admit this took me a lot of time in testing to figure out, so there is a reminder here!

In config/environments/development.rb:

  #added settings
  config.action_mailer.perform_deliveries = true
  config.action_mailer.raise_delivery_errors = true

  config.action_mailer.delivery_method = :smtp
  host = 'localhost:3000'
  config.action_mailer.default_url_options = { :host => 'localhost:3000', protocol: 'http' }

  # SMTP settings for gmail
  config.action_mailer.smtp_settings = {
    :address              => "smtp.gmail.com",
    :port                 => 587,
    :user_name            => ENV["GMAIL_ACCOUNT"],
    :password             => ENV["GMAIL_PASSWORD"],
    :authentication       => "plain",
    :enable_starttls_auto => true
  }

Most of these settings are from this article, and I would recommend reading it as well for more information on how they work and for troubleshooting! Some of the trickier things here: your app needs somewhere to send mail from. This article recommends setting up a dedicated gmail account for this, which has worked for me. I have kept the information about it in my .env file, which I have added to my .gitignore file so it won't be uploaded to GitHub when I update my project there.

The other recommendation from the article that I appreciated was setting up two-factor authentication and then setting an app password for apps to use for the email account--the app password is what I'm calling here with my GMAIL_PASSWORD variable. When I have tested this, the gmail account I've sent to still puts these emails in the spam folder, but they do go through at least!

Also check out the previously linked article for advice on settings for your config/environments/production.rb file. As of writing this post I am still in the process of deploying my backend, so cannot yet speak to what changes work for me there.

In the React front-end

For reference, I didn't really code everything in Rails first and then everything in React after--it happened around the same time and involved a lot of testing throughout. But, for the purposes of this post, I thought it would be easier to separate these concerns to show how it works.

So, with that said, forgot/reset password in React! First, you need a ForgotPassword component to display the form for users to request the code to their email:

import React, { Component } from 'react';
import { forgotPassword } from '../helpers/passwords';
import { Link, withRouter } from 'react-router-dom';

class ForgotPassword extends Component {

  state = {
    email: ""
  }

  handleChange = (event) => {
    const { name, value } = event.target
    this.setState({
      [name]: value
    })
  }

  handleSubmit = (event) => {
    event.preventDefault()
    forgotPassword(this.state.email)
    this.setState({
      email: ""
    })
    this.props.history.push('/')
  }

  render() {
    return (
        <p>Request password reset:</p>
        <form onSubmit={this.handleSubmit}>
          <input required id="forgotpasswordemail" onChange={this.handleChange} name="email" placeholder="email" type="email" value={this.state.email}/>
          <button >Submit</button>
        </form>
    );
  }
}

export default withRouter(ForgotPassword);

My ForgotPassword component! Please note this isn't exactly the code above--I removed styling with reactstrap to make the code in this post easier to read.

This is a basic class component with a controlled form, but on submit, two important things are happening:

The user's email is submitted to the forgotPassword method being called from the helpers/passwords.js file
The user is being redirected back to the home page with this.props.history.push(), and this method is possible to use here because of the last line: withRouter(ForgotPassword).

In that helpers file:

const baseURL = "http://localhost:3000/api/v1"

export const forgotPassword = (email) => {
  return fetch(`${baseURL}/forgot_password`, {
    credentials: "include",
    method: "POST",
    headers: {
      "Content-Type": "application/json"
    },
    body: JSON.stringify(email)
  })
  .then(res => res.json())
  .then(response => {
    alert(response.alert)
  })
  .catch(console.log)
}

This method sends a POST request with the user's email to our /forgot_password route, and when it receives a response, it displays an alert with that response. Going all the way back to our passwords_controller in the Rails section of this post, that alert is "If this user exists, we have sent you a password reset email."

The next step of getting this set up in React is the ResetPassword component to display the form for users to enter the code they have received by email and use it to reset their password:

import React, { Component } from 'react';
import { resetPassword } from '../helpers/passwords';
import { connect } from 'react-redux';


class ResetPassword extends Component {

  state = {
    token: "",
    email: "",
    password: "",
    password_confirmation: ""
  }

  handleChange = (event) => {
    const { name, value } = event.target
    this.setState({
      [name]: value
    })
  }

  handleSubmit = (event) => {
    event.preventDefault()
    const { password, password_confirmation } = this.state;
    if (password !== password_confirmation) {
      alert("Passwords don't match");
      this.setState({
        password: "",
        password_confirmation: ""
      })
    } else {
      this.props.resetPassword(this.state)
      this.setState({
        token: "",
        email: "",
        password: "",
        password_confirmation: ""
      })
    }
  }

  render() {
    return (
        <p>Reset Password:</p>
        <form onSubmit={this.handleSubmit}>
          <label for="token">Token:</label>
          <input required id="token" onChange={this.handleChange} name="token" placeholder="token" type="token" value={this.state.token}/>
          <p>The code that was emailed to you. This is case-sensitive.</p>
          <label for="email">Email:</label>
          <input required id="email" onChange={this.handleChange} name="email" placeholder="email" type="email" value={this.state.email}/>
          <label for="password">New password:</label>
          <input required id="password" onChange={this.handleChange} name="password" placeholder="password" type="password" value={this.state.password}/>
          <p>Set your new password here.</p>
          <label for="password_confirmation">Confirm new password:</label>
          <input required id="password_confirmation" onChange={this.handleChange} name="password_confirmation" placeholder="password confirmation" type="password" value={this.state.password_confirmation}/>
          <button type="secondary">Reset Password</button>
        </form>
    );
  }
}

const mapDispatchToProps = dispatch => {
  return {
    resetPassword: (credentials) => dispatch(resetPassword(credentials))
  }
}

export default connect(null, mapDispatchToProps)(ResetPassword);

My ResetPassword component! As with the previous screenshot, this also includes reactstrap styling not included in my code here for simplicity's sake.

A little more is going on here! First, in handleSubmit, an alert fires and the password and password_confirmation fields reset to blank values if they don't match, to make sure the user is really resetting their password to the right thing. Second, if everything is in order on the form, resetPassword fires.

A bit of a disclaimer on this one: resetPassword isn't quite what I would consider a Redux action, and I honestly haven't figured out yet whether it's a good idea to put it in an actions folder, as is Redux convention, or not. I am dispatching it instead of just calling it though, and mapping it to props through mapDispatchToProps and the connect function, and this is because after it fires, I want it to fire my getCurrentUser action and log the user in, and that is a Redux action.

Here's what that looks like!

import { getCurrentUser } from '../actions/currentUser'

const baseURL = "http://localhost:3000/api/v1"

export const forgotPassword = (email) => {
...
}

export const resetPassword = (credentials) => {
  return dispatch => {
    return fetch(`${baseURL}/reset_password`, {
      credentials: "include",
      method: "POST",
      headers: {
        "Content-Type": "application/json"
      },
      body: JSON.stringify(credentials)
    })
    .then(res => res.json())
    .then(response => {
      if (!!response.error) {
        alert(response.error)
      } else {
        alert(response.alert)
        dispatch(getCurrentUser())
      }
    })
    .catch(console.log)
  }
}

This method sends the credentials submitted in the ResetPassword component form to the /reset_password path as a POST request and returns a response. If there's an error in the action in passwords_controller, that will be an error, and this will show as an alert on the front end. If things go well on the back end, it show a "your password was reset!" alert and then checks the session for a current user.

Getting into that functionality is a little beyond the scope of this blog post too, but I will demonstrate this part of my sessions functionality briefly to put the previous code in context:

routes.rb:

  get '/api/v1/get_current_user' => "api/v1/sessions#get_current_user"

application_controller.rb:

...
  def current_user
    User.find_by(id: session[:user_id])
  end

  def logged_in?
    !!current_user
  end
    ...

sessions_controller.rb:

  def get_current_user
    if logged_in?
      render json: current_user
    end
  end

actions/currentUser.js:

... 
export const getCurrentUser = () => {
  return dispatch => {
    return fetch(`${baseURL}/get_current_user`, {
      credentials: "include",
      method: "GET",
      headers: {
        "Content-Type": "application/json"
      }
    })
    .then(res => res.json())
    .then(user => {
      if (user.error) {
        alert(user.error)
      } else {
        dispatch(setCurrentUser(user))
      }
    })
    .catch(console.log)
  }
}

So, the getCurrentUser action dispatches a GET request to the get_current_user action in the sessions_controller, and if there is currently a user in session--as a user is set in session in the reset action in the passwords_controller in the code at the beginning of this post--then it returns the user object, and uses that to set a current user in the Redux store, which, for the purposes of my app, is logging them in.

As a final note, there is no redirect in my ResetPassword component because my app has conditional rendering for that page--once a user is logged in, they will be redirected away from routes that logged in users don't need to see anyway.

Phew! I think that's it. If you've made it this far, thank you for sticking it out, and I hope this helps if you're trying to implement something similar!

Changing attributes on a user in Rails without having to re-enter password

Sam Markham — Mon, 15 Jun 2020 18:56:01 +0000

(originally published on May 5, 2020)

This is something that first came up for me during my Rails project for Flatiron, and I really wish I had figured it out then, but it feels fitting to have finally solved this mystery in my last weeks in the program.

The issue is: you've set up a project with Rails. You include a user model, and add validations for the user's password. Then you want to make something about the user editable. A bio attribute, or something like that. You get all of the edit functionality set up, test out submitting it, and, error! A password hasn't been entered!

This makes sense, because you didn't enter a password, and you don't want the user to have to enter a password to make changes to their profile when they're already logged in either! But because of the way the password validation is set up, Rails requires a password to be there to save the user.

To fix this, include this line in your user model:

  validates :password, length: { minimum: 5, wrong_length: "Password must be at least 5 characters." }, if: :password

The first bit is specific to my project, though having a minimum password length is probably a good idea anyway, but the last part is what does the job here: if: :password. This tiny bit of code means that if a password isn't included in the changed user object being submitted, then Rails won't worry about validating it.

Finally, if you're dealing with strong params, include this in whatever controller is dealing with updating the user:

if user_params[:password].blank?
  user_params.delete(:password)
end

This should work for projects with Rails as an API (my current project) as well as projects only using Rails (the project I may go back and add this functionality to!).

I hope this helps anyone else struggling with this issue as I was!

Dealing with overlapping reducers in Redux

Sam Markham — Mon, 15 Jun 2020 18:53:17 +0000

(originally published April 25, 2020)

My final project for Flatiron School got a lot more complicated than I was expecting it to with reducers, and there were many little finnicky things here that tripped me up, even into the last hours of coding! This made me think it might be a good thing to write a blog about.

To get briefly into the context, my project is a novel tracker app where users can keep track of their writing progress when participating in a novel writing contest. The website's functionality depends on having access to:

a current user
their current novel (from this year, as the contest is meant to run every year)
all the novels in this year's contest
(it also includes a few other things, but we don't need to worry about them here!)

With Redux, I could keep all of these things in store, which can be accessed from any component in the app--super handy!--and with Redux's combineReducers function, I could make a store with different reducers for each key I wanted in store.

import { combineReducers } from 'redux'
import allCurrentNovels from './allCurrentNovels'
import currentUser from './currentUser'
import currentNovel from './currentNovel'

const rootReducer = combineReducers({
  currentUser,
  allCurrentNovels,
  currentNovel
})

export default rootReducer;

The fun part came when I decided I wanted the currentNovel to also be part of allCurrentNovels, so that I could easily access the main novel in question for most of the app but also have that novel be visible to the user on the main page along with all the other novels in the contest.

Basically: when using rootReducer, each reducer going into it is responsible for its own piece of the store. currentNovel is either set to null or a user's novel. allCurrentNovels includes everything. What this means practically is that every change to currentNovel in its reducer must also find and change that novel in the allCurrentNovels array, because the novel is also in there, and how it appears there influences how it looks in the app somewhere else.

Here are a couple of excerpts from switch statements in each reducer:

// /reducers/currentNovel.js
...
    case 'UPDATE_NOVEL':
      return action.novel
    case 'ADD_BADGE':
      return {
        ...state,
        badges: [...state.badges, action.badge]
      }
            ...

// /reducers/allCurrentNovels.js
... 
    case 'ADD_NOVEL':
      return [...state, action.novel]
    case 'ADD_BADGE':
      return state.map(novel => {
        if (novel.id === action.badge.novel_id) {
          return {
            ...novel,
            badges: [...novel.badges, action.badge]
          };
        } else {
          return novel;
        }
      })
...

The currentNovel reducer is only responsible for the key of currentNovel in the Redux store, which is either null or an object, so it only has to return the payload of the action dispatched to it. The allCurrentNovels reducer is responsible for an array of novels, so adding a currentNovel needs to affect it too--but because it needs to hold all of the other novels too, the new state it returns spreads the old state into a new array which also includes the new novel object.

Similarly, with adding a badge to the currentNovel, the currentNovel reducer only has to return an object that spreads the rest of the pre-existing state into it, and then spreads the pre-existing badges state into the novel's badges array while also adding the new badge. The allCurrentNovels reducer needs to deal with this action in a similar way, but it needs to find the right novel before modifying it.

While my project set up might be a bit of a fringe case for this, how an action might need to go through multiple reducers is a good thing to keep in mind for a variety of different scenarios. Another one from my project that comes to mind is that when an action with the type "CLEAR_CURRENT_USER" fires, it needs to be in the currentUser reducer to set the currentUser object to null, but also in the currentNovel reducer to set that object to null--and in whatever other reducers deal with pieces of the store that should be influenced by a user logging out.

I hope this is helpful to anyone else struggling to get their head around multiple reducers like I was!