Forem: Chris Belsole

Convert to React Hooks in 6 easy steps

Chris Belsole — Sat, 21 Mar 2020 20:25:47 +0000

React hooks were released in version 16.8.0, and since then we’ve all been trying to figure out how to use them effectively and convert our components so that using newer versions of React is not an upgrade nightmare. In this article we are going to discuss the 6 steps for moving your React components to hooks using an example to-do application written in Typescript that starts with the controller pattern and commit by commit lays out my methodology for moving components. There are more complex examples, but this article should give you a good grounding in how to think about migrating your components.

Protip: Using React hooks can be a replacement for Redux bringing down the number of dependencies in your application.

Step 1: Select the component to convert

Let’s chat for a second about what our example to-do app looks like.

As you can see we have a list of to-do’s that can be completed with a button underneath that checks if all to-do’s are complete. For this example we are going to convert the Controller.tsx component which declares an empty list of to-do’s and renders a loading state:

export default class Controller extends React.Component<Props, State> {
  constructor(props: Props) {
    super(props);
    this.state = { todos: [] };
  }
…
  render() {
    const { todos } = this.state;

    if (!todos.length) {
      return <div>loading...</div>;
    }

Grabs data from the API via componentDidMount() and populates the list of to-do’s:

  componentDidMount() {
    getTodos().then(todos => this.setState({ todos }));
  }

And renders the <TodoList /> along with the All complete? button while passing down the complete callback:

render() {
    const { todos } = this.state;
    ...
    return (
      <div>
        <TodoList completeTodo={this.completeTodo} todos={todos} />
        <button onClick={this.isAllComplete}>All complete?</button>
      </div>
    );
  }

Here’s the full code:

import * as React from "react";
import { getTodos, completeTodo as completeTodoAPI, iTodo } from "../api/todos";
import TodoList from "./todoList";

interface Props {}
interface State {
  todos: iTodo[];
}

export default class Controller extends React.Component<Props, State> {
  constructor(props: Props) {
    super(props);
    this.state = { todos: [] };
  }

  componentDidMount() {
    getTodos().then(todos => this.setState({ todos }));
  }

  completeTodo = (item: string) => {
    completeTodoAPI(item).then(todos => this.setState({ todos }));
  };

  isAllComplete = () => {
    const { todos } = this.state;

    for (let i = 0; i < todos.length; i++) {
      if (!todos[i].done) {
        alert("Todos are not complete.");
        return;
      }
    }

    alert("Todos are complete.");
  };

  render() {
    const { todos } = this.state;

    if (!todos.length) {
      return <div>loading...</div>;
    }

    return (
      <div>
        <TodoList completeTodo={this.completeTodo} todos={todos} />
        <button onClick={this.isAllComplete}>All complete?</button>
      </div>
    );
  }
}

Step 2: Convert your class to a function

Here we are changing our class to a function and returning the JSX elements from that function. So we move all of our returns statements outside of the render() method. In Typescript React.FunctionalComponent (React.FC) is the interface for a function component. For Javascript you would just declare a function.

diff --git a/src/components/controller.tsx b/src/components/controller.tsx
index 7184893..e310613 100644
--- a/src/components/controller.tsx
+++ b/src/components/controller.tsx
@@ -7,7 +7,7 @@ interface State {
   todos: iTodo[];
 }

-export default class Controller extends React.Component<Props, State> {
+const Controller: React.FunctionComponent = () =>  {
   constructor(props: Props) {
     super(props);
     this.state = { todos: [] };
@@ -34,7 +34,6 @@ export default class Controller extends React.Component<Props, State> {
     alert('Todos are complete.');
   };

-  render() {
   const { todos } = this.state;

   if (!todos.length) {
@@ -47,5 +46,7 @@ export default class Controller extends React.Component<Props, State> {
       <button onClick={this.isAllComplete}>All complete?</button>
     </div>
   );
+
 }
-}
+
+export default Controller;

Step 3: Extract class methods to consts

Extracting static and class methods to consts is the simplest analogue I've found for the structure of a functional component. Class methods rely on state. So they are inlined with the function. Static methods don't rely on state. So they go outside of the function.

diff --git a/src/components/controller.tsx b/src/components/controller.tsx
index e310613..4322bf2 100644
--- a/src/components/controller.tsx
+++ b/src/components/controller.tsx
@@ -17,11 +17,11 @@ const Controller: React.FunctionComponent = () =>  {
     getTodos().then(todos => this.setState({ todos }));
   }

-  completeTodo = (item: string) => {
+  const completeTodo = (item: string) => {
     completeTodoAPI(item).then(todos => this.setState({ todos }));
   };

-  isAllComplete = () => {
+  const isAllComplete = () => {
     const { todos } = this.state;

     for (let i = 0; i < todos.length; i++) {
@@ -42,8 +42,8 @@ const Controller: React.FunctionComponent = () =>  {

   return (
     <div>
-      <TodoList completeTodo={this.completeTodo} todos={todos} />
-      <button onClick={this.isAllComplete}>All complete?</button>
+      <TodoList completeTodo={completeTodo} todos={todos} />
+      <button onClick={isAllComplete}>All complete?</button>
     </div>
   );

Step 4: Extract state via useState()

Ahhh, we finally get to use hooks. useState() is our first hook we are going to use to extract the state of our component. This hook works by declaring the default state and returning the first parameter as the state and the second as a function to update the state. Since we inlined all the class methods the new state should be accessible in the functions.

diff --git a/src/components/controller.tsx b/src/components/controller.tsx
index 4322bf2..000b077 100644
--- a/src/components/controller.tsx
+++ b/src/components/controller.tsx
@@ -1,29 +1,21 @@
-import * as React from 'react';
+import React, { useState } from 'react';
 import { getTodos, completeTodo as completeTodoAPI, iTodo } from '../api/todos';
 import TodoList from './todoList';

 interface Props {}
-interface State {
-  todos: iTodo[];
-}

 const Controller: React.FunctionComponent = () =>  {
-  constructor(props: Props) {
-    super(props);
-    this.state = { todos: [] };
-  }
+  const [todos, setTodos] = useState<iTodo[]>([])

   componentDidMount() {
-    getTodos().then(todos => this.setState({ todos }));
+    getTodos().then(todos => setTodos(todos));
   }

   const completeTodo = (item: string) => {
-    completeTodoAPI(item).then(todos => this.setState({ todos }));
+    completeTodoAPI(item).then(todos => setTodos(todos));
   };

   const isAllComplete = () => {
-    const { todos } = this.state;
-
     for (let i = 0; i < todos.length; i++) {
       if (!todos[i].done) {
         alert('Todos are not complete.');
@@ -34,8 +26,6 @@ const Controller: React.FunctionComponent = () =>  {
     alert('Todos are complete.');
   };

-  const { todos } = this.state;
-
   if (!todos.length) {
     return <div>loading...</div>;
   }
(END)

Step 5: Convert lifecycle methods

Here we have some interesting options depending on what hooks we are converting. Check out this article for some common conversions. We only want our useEffect() function to run when the component mounts. So we'll pass it an empty array ([]) in the second argument signifying it should run once and not again since there are no parameters in the array to cause it to refresh.

diff --git a/src/components/controller.tsx b/src/components/controller.tsx
index 000b077..0f85564 100644
--- a/src/components/controller.tsx
+++ b/src/components/controller.tsx
@@ -1,15 +1,11 @@
-import React, { useState } from 'react';
+import React, { useState, useEffect } from 'react';
 import { getTodos, completeTodo as completeTodoAPI, iTodo } from '../api/todos';
 import TodoList from './todoList';

 interface Props {}

 const Controller: React.FunctionComponent = () => {
-  const [todos, setTodos] = useState<iTodo[]>([])
-
-  componentDidMount() {
-    getTodos().then(todos => setTodos(todos));
-  }
+  const [todos, setTodos] = useState<iTodo[]>([]);

   const completeTodo = (item: string) => {
     completeTodoAPI(item).then(todos => setTodos(todos));
@@ -26,6 +22,10 @@ const Controller: React.FunctionComponent = () =>  {
     alert('Todos are complete.');
   };

+  useEffect(() => {
+    getTodos().then(todos => setTodos(todos));
+  }, []);
+
   if (!todos.length) {
     return <div>loading...</div>;
   }
@@ -36,7 +36,6 @@ const Controller: React.FunctionComponent = () =>  {
       <button onClick={isAllComplete}>All complete?</button>
     </div>
   );
-
-}
+};

 export default Controller;

Step 6: Cleanup unused components

A simple but important step, clean up your code if you have anything left over. Future you will be happy you took the time.

diff --git a/src/components/controller.tsx b/src/components/controller.tsx
index 0f85564..a4eaac9 100644
--- a/src/components/controller.tsx
+++ b/src/components/controller.tsx
@@ -2,8 +2,6 @@ import React, { useState, useEffect } from 'react';
 import { getTodos, completeTodo as completeTodoAPI, iTodo } from '../api/todos';
 import TodoList from './todoList';

-interface Props {}
-
 const Controller: React.FunctionComponent = () => {
   const [todos, setTodos] = useState<iTodo[]>([]);

(Bonus) Step 7: Move state management to context/provider

At this point you have a working functional component. So why not just stop here and move on to your next task? The answer is a bit complex and touches on architectural principals so first, let's talk a little about SOLID principals, state management, and component coupling.

Background

SOLID principals are a set of ideas for building maintainable software acting as guides for making decisions about architecting complex systems. The S in SOLID stands for the Single Responsibility Principal which states that "A class should only have one reason to change." In short, things do one thing. Since React is a frontend library it is easy and often required to break this principal since components are often rendering HTML and managing state. This works well enough but it often becomes unmaintainable when you have to rewrite your code for another use case since the state that drives your components is kept at the highest level.

This is where we start talking about local state vs global state. Local state is state local to your component. Think filling out an HTML form or keeping track of button clicks. That info needs to live somewhere, and often that's in the state of the component rendering the HTML. Global state on the other hand is shared across components. Imagine grabbing a user session form your API and storing that somewhere so that you can use the user's name and email to display across your application. If we used a pure component architecture to store global state we have to fetch data in the top level component and then pass it down through all other components to the one that needs it much like the the <Controller /> passing the completeTodo() function through the <TodoList /> to the <Todo /> component so that the button on the <Todo /> component can modify the state of a to-do. We can see in this example that this leads to tight coupling of components.

Why do we want to avoid tight coupling? Imagine writing a complex grocery store application where everything is tied to a single payments processing system. Something happens to them internally and now your payments processing system is shutting down. How are you going to integrate a new payments processing system into your application? You have to rewrite your ordering, refunding, and revenue systems which incurs a lot of risk when these things are so critical to your business. Alternatively, let's think of a scenario where your payments processing system is behind an abstraction. The abstraction is aware of orders and knows how to refund and calculate revenue. Now when you need to rewrite your system to deal with all the new code you only have to rewrite the logic underneath that abstraction. This is also the D in SOLID.

Following SOLID principals and thinking ahead about how your components are tied together are ideas that make a long lasting application maintainable. It is often faster to write code that works in the now, but if you engrain these concepts into your fingers future you will have a much easier time dealing with bugs and changing your software.

Let's put the background into pratice

With all that in mind let's dive into the code. First we'll write our <TodoProvider /> that holds our global state with the capability to get and complete to-do's from the API. Notice that it returns its children wrapped in the provider. This is what allows us to use the context in the component chain.

import React, { createContext, useState } from "react";
import {
  getTodos as getTodosAPI,
  completeTodo as completeTodoAPI,
  iTodo
} from "../api/todos";

interface iTodoContext {
  todos: iTodo[];
  completeTodo: (item: string) => void;
  getTodos: () => void;
}

interface TodoProviderProps {
  children?: React.ReactNode;
}

export const todoContext = createContext<iTodoContext>({
  todos: [],
  completeTodo: () => {},
  getTodos: () => {}
});

const TodoProvider: React.FunctionComponent = ({
  children
}: TodoProviderProps) => {
  const [todos, setTodos] = useState<iTodo[]>([]);

  const getTodos = () => getTodosAPI().then(todos => setTodos(todos));

  const completeTodo = (item: string) =>
    completeTodoAPI(item).then(todos => setTodos(todos));

  return (
    <todoContext.Provider value={{ todos, completeTodo, getTodos }}>
      {children}
    </todoContext.Provider>
  );
};

export default TodoProvider;

Next, we'll wrap our <Controller /> in the provider so that we can call useContext() within the component chain:

diff --git a/src/App.tsx b/src/App.tsx
index f7b1217..83ce739 100644
--- a/src/App.tsx
+++ b/src/App.tsx
@@ -1,10 +1,13 @@
 import React from 'react';
 import Controller from './components/controller';
+import TodoProvider from './components/todoProvider';

 function App() {
   return (
     <div>
+      <TodoProvider>
         <Controller />
+      </TodoProvider>
     </div>
   );
 }

We'll then rewrite our <Controller /> to call useContext() to get to-do's and pass them down to it's children while breaking the dependency of passing down the completeTodo() function making the component chain loosely coupled since it still relies on the data but not the interactions.

diff --git a/src/components/controller.tsx b/src/components/controller.tsx
index a4eaac9..1159fc7 100644
--- a/src/components/controller.tsx
+++ b/src/components/controller.tsx
@@ -1,13 +1,9 @@
-import React, { useState, useEffect } from 'react';
-import { getTodos, completeTodo as completeTodoAPI, iTodo } from '../api/todos';
+import React, { useEffect, useContext } from 'react';
 import TodoList from './todoList';
+import { todoContext } from './todoProvider';

 const Controller: React.FunctionComponent = () => {
-  const [todos, setTodos] = useState<iTodo[]>([]);
-
-  const completeTodo = (item: string) => {
-    completeTodoAPI(item).then(todos => setTodos(todos));
-  };
+  const { todos, getTodos } = useContext(todoContext);

   const isAllComplete = () => {
     for (let i = 0; i < todos.length; i++) {
@@ -21,8 +17,8 @@ const Controller: React.FunctionComponent = () => {
   };

   useEffect(() => {
-    getTodos().then(todos => setTodos(todos));
-  }, []);
+    getTodos();
+  }, [getTodos]);

   if (!todos.length) {
     return <div>loading...</div>;
@@ -30,7 +26,7 @@ const Controller: React.FunctionComponent = () => {

   return (
     <div>
-      <TodoList completeTodo={completeTodo} todos={todos} />
+      <TodoList todos={todos} />
       <button onClick={isAllComplete}>All complete?</button>
     </div>
   );

<TodoList /> also gets edited to no longer pass down the completeTodo() function.

diff --git a/src/components/todoList.tsx b/src/components/todoList.tsx
index e69edba..4f664b8 100644
--- a/src/components/todoList.tsx
+++ b/src/components/todoList.tsx
@@ -4,15 +4,14 @@ import Todo from './todo';

 interface Props {
   todos: Array<iTodo>;
-  completeTodo: (item: string) => void;
 }

-const TodoList: React.FC<Props> = ({ todos, completeTodo }) => {
+const TodoList: React.FC<Props> = ({ todos }) => {
   return (
     <ul>
       {todos.map(todo => (
         <li>
-          <Todo completeTodo={completeTodo} {...todo} />
+          <Todo {...todo} />
         </li>
       ))}
     </ul>

Finally <Todo> calls useContext() to get the completeTodo() function and update itself.

diff --git a/src/components/todo.tsx b/src/components/todo.tsx
index 47b0e44..75de4ff 100644
--- a/src/components/todo.tsx
+++ b/src/components/todo.tsx
@@ -1,11 +1,12 @@
-import * as React from 'react';
+import React, { useContext } from 'react';
 import { iTodo } from '../api/todos';
+import { todoContext } from './todoProvider';

-interface Props extends iTodo {
-  completeTodo: (item: string) => void;
-}
+interface Props extends iTodo {}
+
+const Todo: React.FC<Props> = ({ item, done }) => {
+  const { completeTodo } = useContext(todoContext);

-const Todo: React.FC<Props> = ({ item, done, completeTodo }) => {
   return (
     <div>
       task: {item} is {done ? 'done' : 'not done'}{' '}

After all that we have an abstracted functional app working off of global and local state where appropriate. I hope you found this guide useful. Please get in contact with me if you have any feedback.

My personal journey setting up a blog

Chris Belsole — Tue, 10 Mar 2020 12:17:04 +0000

Like a moth to the flame I keep coming back to the idea of maintaining a personal blog. I’ve spun up a Jekyll blog more than once and wrote some content only to abandon it days later. Until a bit ago cbelsole.github.com was still up and running. Since I haven’t touched it for 4 years it stood as a testament to set it and forget it infrastructure.

So like, why do this again? Since my Jekyll days static site generators have gotten a lot more interesting. I use Gatsby (JS) professionally which has the ability to do plug-and-play server-side rendering. This is a huge advantage since you can cut perceived load time to a minimum by pre-rendering all of your react pages and ship the static site async after the page loads. Hugo (Go) promises to render pages in 1ms making generating thousands of pages fast. Being web developers, we owe it to ourselves to explore the tools of our field so that we can craft nuanced solutions for professional and personal projects.

Goals

For my static site experiment I wanted to set a few goals with a focus on creating content and not configuration:

I want a static site generator that works out of the box without a lot of configuration
My strengths don't lie in frontend development. So I need a template to work off of.
Blog posts should be easy to create. Experiment with a CRM for creating posts and managing content.
I want the hosting platform to be bulletproof so that I can leave the blog up for years without worrying about it being down.
I want to accomplish these goals on the cheap.

Picking a framework

If we check staticgen.com there are currently 281 options for creating a static site. That’s too many. So I shortened the list to Gatsby (JS) which I have production experience with and Hugo (Go) because I mainly work in Go these days and you get a lot of tooling for free.

Gatsby

Gatsby's ability for server-side rendering is appealing especially if you have a few pages that are going to be visited frequently. For this project though I want something that works out of the box and requires very little upkeep. If you’ve ever worked with JS in production you know that dependencies can cause a maintenance nightmare if you 1. Don’t lock them down and 2. Don’t keep them up to date. For example, try upgrading your version of React after being 2 major versions behind.

Hugo

I have been following Hugo for a long time. I experimented with it once when it was first released and it lived up to its promise of rendering pages quickly. At the time the themes available were sparse and my strengths don’t lie in front end development. Since then their themes folder has grown to 299 themes as of the writing of this post. They all range in their capabilities like social integration and Google Analytics, but some of them look straight up professional. I’m looking at you hugo-academic.

Protip: Github user TrentSPalmer created a script to rank Hugo themes by stars hugo_themes_report.

What about dependencies? Installing Hugo comes with a long list of dependencies, but since the only thing I installed is Hugo I can assume that they will manage that list for me. So upgrading Hugo should be fairly straightforward. That coupled with Go's promise to maintain backward compatibility lowers the tooling and maintenance costs. I did read a few cases where Hugo did not perform the same version over version, but I’ve lived a lifetime maintaining JS applications. So if I have to deal with the occasional upgrade bug from one dependency rather myriads I am fine with it.

Setup

# create and enter directory
mkdir cbelsole.com && cd cbelsole.com

# create a new go module
go mod init github.com/cbelsole/cbelsole.com

# install hugo and lock version
go get github.com/gohugoio/hugo

# create new hugo site
hugo new site cbelsole.com && mv cbelsole.com/* . && rm -rf cbelsole.com

# add the mainroad theme
git submodule add https://github.com/vimux/mainroad themes/mainroad

Content Management System Rabbithole

To manage my blog tags and content I looked into Forestry.io and Netlify CMS since both of these had plug-and-play content tools that integrated with Github. The idea here is to make managing content easier by using a UI rather than editing post metadata manually.

TL;DR it did not work out. The need to integrate with their specific sites outweighed the benefits of a CMS, especially with so little content.

Netlify CMS

The experiment started out with a lot of promise since in their words:

The folks at Netlify created Netlify CMS to fill a gap in the static site generation pipeline. There were some great proprietary headless CMS options, but no real contenders that were open source and extensible—that could turn into a community-built ecosystem like WordPress or Drupal. For that reason, Netlify CMS is made to be community-driven, and has never been locked to the Netlify platform (despite the name).

If you hook up Netlify CMS to your website, you're basically adding a tool for content editors to make commits to your site repository without touching code or learning Git.

The downside here is that plugging in the CMS requires you to use their identity service for OAuth and that means you have to deploy via Netlify. This is not something I wanted to do since the price per usage is good compared to Zeit but not as good as AWS. You can host your own identity server, but that would necessitate standing up a server which would also increase costs.

Forestry.io

Forestry.io is another Github based CMS provider that allows you to plug it into your website pretty seamlessly. When I got it setup I took a look at what was in front of me. I have a tag manager and a markdown editor. As the sole writer with only a single post this seemed like a premature optimization. Maybe when I am writing with multiple people with a more complex use case adding a CMS will be more of a need than a nice to have. For now, with stackedit.io I have a good markdown editor and eventually I'll come up with a set of tags.

AWS Time

This guide describes how to create a static s3 site with HTTPS via CloudFront. After the $12 of registering the domain name with my current usage AWS costs me around $1.03 a month. That's well within what I am willing to pay for hosting.

1 github workflow triggered on pushes to master later:

name: build deploy hugo

on:
  push:
    branches:
      - master

jobs:
  build-deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repo with submodules
        uses: actions/checkout@v1
        with:
          submodules: true

      - name: Setup Hugo
        uses: peaceiris/actions-hugo@v2
        with:
          hugo-version: "0.65.2"

      - name: Build Static Site
        run: hugo --minify

      - name: Setup AWS CLI
        uses: chrislennon/action-aws-cli@v1.1

      - name: Deploy to S3
        run: aws s3 sync ./public/ s3://${{ secrets.AWS_S3_BUCKET }} --acl public-read --follow-symlinks --delete --cache-control="max-age=3600"
        env:
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

I have a website hosted at cbelsole.com where I can push content that I think would be useful for people. Total development time 1 day.

Future goals

Checking all of my images to Github is eventually going to blow up the size of the repository. Eventually I want a workflow that syncs images with s3 and magically creates links.
Ironically, after looking more into stackedit.io it may be the CMS solution I was looking for.

How I decide to work on a side project

Chris Belsole — Sat, 04 Jan 2020 18:52:45 +0000

How do you choose?

Generally, I ask myself 5 things when choosing a side project.

Can this potentially make me money?
Is this going to teach me something I don’t know?
Is this useful to anyone?
How long is this going to take?
What does success look like?

The general theme here is, “Am I wasting my time?” Human life is finite and your productive years are even less. Your time and attention are the 2 greatest commodities you have as an average person. Spending them wisely on things that help you grow and improve your life should be the goal of picking your side project. As your priorities change (buying a house, raising a family, affording that lux apartment) so do your criteria of what constitutes a good use of time.

Consulting work

I consider consulting work side projects since I work a full-time job. So consulting would have to be done on the side. Before I start this though I want to know it’s something I can complete in a reasonable amount of time, or if it’s a project with no clear end date is the workload light enough that I can fit it in my normal life without disrupting things too much.

Awesome tech stuff

This is my favorite reason for a side project as it has not only let me play with new technologies that I would otherwise have no reason to but experimenting with something unfamiliar gives me a broader perspective on what good programming looks like and what tools are out there to solve problems.

Things I’ve learned on the side include:

React + Native + Hooks
Rails 5
Apache
Docker
Meteor + Mongo DB (data-driven programming)
Web scraping (multiple languages/frameworks. Current favorite is Puppeteer)
Trello (and project management in general)
Bitbucket
Sqlite3
Vultr + Linux administration
Google Cloud Platform (and to a lesser extent Azure)

The main thing you want to come out of a technical project is, “What makes this technology interesting and how can I incorporate its learnings into the code I write today?” For instance, writing Rails code taught me the power of convention, working with Sqlite3 makes me rethink how I architect small projects that run on a single server, and React was immediately useful to me when our company chose to move over. I was suddenly in a position where I could take the lead on how our components were structured and the patterns/libraries that were implemented.

Open Source Projects/Contributions

When I am using OSS I often want to make a contribution that adds a certain feature or browse their issue list to see if there’s something small I can knock out. To me, this is a great reason to invest some time helping to make the code you use better. It usually won’t make you money, but it’s immediately useful. The people that create these libraries usually also have a second job. So let’s all throw on our solidarity hats and solve problems together.

Passion projects

These are the bane of side projects as they violate 3 of my 5 criteria right off the bat. Who knows if this thing will ever make money? Who knows if this thing will ever be useful? I haven’t even figured out the target audience yet. Success looks like not spending another 6 months typing away trying to figure out a user interaction that testers don’t hate. GLAR.
I have spent months of my life on passion projects that never see the light of day because they never reach the level where I want to put them in the world with my name attached.

I can’t decide

So you have a bunch of side projects you are looking at but you can’t decide which one to do, or you don’t have ideas but you want to do something. The trick here is to just start doing something. Getting in a routine where you open your laptop and start typing will reinforce this behavior and make it easier to start tomorrow. Abandoned side projects are a meme at this point. So don’t feel bad for tabeling something for later (or more realistically never). If you are stuck here are some ideas to jog your creativity.

The Pokemon API is publicly accessible. Can you create a real Pokedex where I can point my phone at a picture of a Pokemon and have it come up?
Can you scrape Craigslist for cars in the last month ordered by users’ preference that calculates the model year by how many miles per year on the car?
Stretch your design skills and create a personal website from scratch that looks like something you’d want to show people.