DEV Community: faraz ahmad

How you can have productive retrospective meetings

faraz ahmad — Fri, 15 Jan 2021 18:17:29 +0000

If you're familiar with the Agile Methodology, you've probably been part of a retrospective meeting. Retrospectives can be an incredibly powerful tool for team growth, improving quality and effectiveness of your processes and products.

However, a lot of teams hate these meetings, and aren't getting enough value out of them.

I asked some software engineers why they disliked about retros, here's what they had to say:

"Having retros is my least favorite thing. It is frustrating when nothing changes as a result." - Ben Ilegbodu, Principal Software Engineer.

"I hate using paper and post it notes! It's not good for the environment and it's not good for tracking." - Randall Kanna, Software Engineer.

Here's a list of why your retrospective meeting is broken, causing your team could be falling short of their potential.

Not creating a safe space where people can share honest opinions without being judged.
Not reviewing the recent past.
Not talking about things that your teammates think are important.
Venting without brainstorming.
Not following through on action items (no due date, no owner).
Not having retrospective regularly.

Here are some tips that can help you run more effective retrospective meetings

Start with an ice-breaker. It helps set the tone early, and puts everyone at ease.
Creating a safe space takes time, and honest communication. By having retrospectives regularly, your team will get into a rhythm of having them. Even if the first couple feel draining, keep going! They will get better.
Give some time for teammates to vote & group items that are the similar. Often, different teammates are facing the same problem. If a lot of people are bringing this up during retro, it's probably a good indication that it needs to be fixed.
For every bad item, there should be a corresponding action item. This ensures that things that are brought up are being looked at.
When you create an action item, assign it a due date and an owner. If your team is bringing up problems, but no one is committed to fixing them, you will feel the retro burnout quickly. We like to handle action items in the forthcoming sprint.
In your following retrospective, follow up on the action items. This way you can assure your team that you hear them and that we are all working together to make their work better.

Retro automatically sorts items by like count

We decided to build Retro because the tools we were using weren't helping our retrospective process. We tried Google Docs and Trello, but an issue that kept arising was teammates all writing down the same problem, before reading the other posts.

To solve this, we implemented a like button, where teammates can +1 an item that they are also experiencing. Items with the highest count are automatically sorted to the top, so when reading through them, you'll see the most impactful ones first.

Get 2 months free of Retro by joining the newsletter

If you're interested in getting more tips on how to run effective retrospective meetings, as well as learn more about Retro, join our newsletter. As a thanks we will give you 2 months free!

Get 2 Months Free

Retro will be launching at the end of Q1 2021.

Till next time,

— Faraz

Founder & CEO of Retro

React & Firebase: Authenticate a User with Email and Password

faraz ahmad — Wed, 16 Dec 2020 22:34:33 +0000

Note: With the release of v9 of firebase library, this post is now out of date.

My first egghead lesson is live! Go check it out! 👇

Authenticate a User in React with Firebase

Opinionated React - Use Status Enums Instead of Booleans

faraz ahmad — Mon, 06 Jul 2020 18:19:06 +0000

Intro

I’ve been working with React for over four years. During this time, I’ve formed some opinions on how I think applications should be. This is part 6 in the series.

Why

When I started writing React, I would often use an isLoading boolean to indicate that I was loading some data asynchronously.

This is fine for a simple example, but as I learned it does not scale well.

Why It's a Bad Idea - an Example

import * as React from "react";
import { getUserById } from "./services/user-service";
import { User } from "./types/user";

export function App() {
  const [user, setUser] = React.useState(null);
  const [isLoading, setIsLoading] = React.useState(true);

  React.useEffect(() => {
    const handleGetUser = async (id: string) => {
      const user = await getUserById(id);
      setUser(user);
      setIsLoading(false);
    };

    handleGetUser("1");
  }, []);

  return (
    <div>
      {isLoading && <p>Loading...</p>}
      {!isLoading && user && <UserProfile user={user} />}
    </div>
  );
}

function UserProfile({ user }: { user: User }) {
  return (
    <div>
      <p>{user.displayName}</p>
      <p>{user.email}</p>
    </div>
  );
}

Here's an example where we are fetching a user and flip a boolean value to indicate that we are done loading. This is fine...but we don't really know if our handleGetUser function successfully fetched the user.

user could still be null if the fetch call failed.

We could add a try / catch block to our handleGetUser function, like so.

import * as React from "react";
import { getUserById } from "./services/user-service";
import { User } from "./types/user";

export function App() {
  const [user, setUser] = React.useState(null);
  const [isLoading, setIsLoading] = React.useState(true);
  const [errorMessage, setErrorMessage] = React.useState('');

  React.useEffect(() => {
    const handleGetUser = async (id: string) => {
      try {
        // Clearing the error message.
        setErrorMessage('');
        const user = await getUserById(id);
        setUser(user);
      } catch (error) {
        setErrorMessage(error.message)
      }
      // Set isLoading to false regardless of 
      // if the call succeeds or fails.
      setIsLoading(false);
    };
    handleGetUser("1");
  }, []);

  return (
    <div>
      {isLoading && <p>Loading...</p>}
      {!isLoading && user && <UserProfile user={user} />}
    </div>
  );
}

function UserProfile({ user }: { user: User }) {
  return (
    <div>
      <p>{user.displayName}</p>
      <p>{user.email}</p>
    </div>
  );
}

We're now tracking error messages, but we still didn't really solve our problem of knowing what happened after isLoading is set to false. We have to do some checks to figure it out.

// loading
isLoading === true

// success
isLoading === false && user !== null && !error

// error
isLoading === false && !user && error !== ''

Even with a few different statuses, we have to do too much thinking.

A Better Approach - use Enums

An enum (short for enumeration), allows us to define a set of named constants. These constants can be used to create a set of distinct cases.

export enum UserStatus {
  LOADING = "loading",
  SUCCESS = "success",
  ERROR = "error",
}

We can define our distinct "states", and use them like so:

*Note that I'm using three separate useState calls here, not something I would actually do. This is for the purpose of learning. If you want to learn how I manage state, you can check out this post.

import * as React from "react";
import { getUserById } from "./services/user-service";
import { User } from "./types/user";
import { UserStatus } from "./constants/user-status";

export function App() {
  const [user, setUser] = React.useState<User | null>(null);
  const [status, setStatus] = React.useState<UserStatus>(UserStatus.LOADING);
  const [errorMessage, setErrorMessage] = React.useState<string>('');

  React.useEffect(() => {
    const handleGetUser = async (id: string) => {
      try {
        // Clearing the error message.
        setErrorMessage('');
        const user = await getUserById(id);
        setUser(user);
        setStatus(UserStatus.SUCCESS);
      } catch (error) {
        setErrorMessage(error.message)
        setStatus(UserStatus.ERROR);
      }
    };
    handleGetUser("1");
  }, []);

  if (status === UserStatus.ERROR) {
    return <div><p>Oops, something went wrong.</p></div>
  }

  return (
    <div>
      {status === UserStatus.LOADING && <p>Loading...</p>}
      {status === UserStatus.SUCCESS && <UserProfile user={user} />}
    </div>
  );
}

function UserProfile({ user }: { user: User }) {
  return (
    <div>
      <p>{user.displayName}</p>
      <p>{user.email}</p>
    </div>
  );
}

This is a lot easier to reason about, and allows us to add some more states later if needed. 👍

Wrapping Up

This is the 6th post in my Opinionated React series. As always, I'm open to feedback.

If you'd like more content like this, or have some questions, you can find me on Twitter.

Till next time.

Opinionated React: Use Context for Shared State

faraz ahmad — Tue, 09 Jun 2020 23:14:16 +0000

Intro

I’ve been working with React for over four years. During this time, I’ve formed some opinions on how I think applications should be. This is part 5 in the series of such opinionated pieces.

My Pattern for React Context

My buddy Nader asked how I use React Context in my apps. I promised I'd write about it, so here we are.

// Detect dark theme var iframe = document.getElementById('tweet-1233180102747246593-261'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1233180102747246593&theme=dark" }

Why

There are some instances in your application state is needed by multiple components. I will use context if this shared state requires a lot of prop drilling. In the past, Redux was a popular solution to avoid prop drilling. However, I don't believe Redux is needed anymore. React's context api works great for this.

Use Cases - Important!

You should use React context for global state. That being said, there aren't that many pieces of global state. Some good examples of global state are the current user, the current language setting, or a map of feature flags.
You don't need to use context only for global state. Context can be applied to a specific sub-tree of your application.
It's common to have multiple sub-tree specific contexts.

Inspiration

I originally learned this pattern from Kent C. Dodd's excellent post How to use React Context effectively, I recommend reading this. Tanner Linsley also covers similar concepts in his talk Custom Hooks in React: The Ultimate UI Abstraction Layer.

Example

The end goal is to have an api that looks like this.

export const App = ({ userId }) => {
  return (
    <UserProvider id={userId}>
      <Dashboard />
    </UserProvider>
  );
};

const Dashboard = () => {
  const { isLoading, user } = useUserState();
  if (isLoading) {
    return <div>Loading...</div>;
  }
  return (
    <div>
      <h1>Dashboard</h1>
      <div>Hello {user.displayName}!</div>
    </div>
  );
};

Let's work backwards to get to this solution.

First, let's start with defining the state of our context, as well as the two contexts we will be creating.

interface UserState {
  user?: User;
  isLoading: boolean;
}

const UserStateContext = React.createContext<UserState | undefined>(undefined);
const UserDispatchContext = React.createContext<UserDispatch | undefined>(
  undefined
);

We are creating two separate contexts because not all components will need access to both state and dispatch. This way, a component can use only the context it requires. The added benefit is that if a component is only using dispatch, it will not re-render on state change because it is not using that context.

For state management within the context, we're going to use useReducer.

// omitted rest of the file

enum UserActionTypes {
  LOADING = "loading",
  SUCCESS = "success"
}
type UserAction =
  | { type: UserActionTypes.LOADING }
  | { type: UserActionTypes.SUCCESS; payload: User };
type UserDispatch = (action: UserAction) => void;

function userReducer(state: UserState, action: UserAction): UserState {
  switch (action.type) {
    case UserActionTypes.LOADING: {
      return { isLoading: true };
    }
    case UserActionTypes.SUCCESS: {
      return { isLoading: false, user: action.payload };
    }
    default: {
      throw new Error("Invalid action type");
    }
  }
}

I often write contexts like this. At app startup, we'd like to fetch information about the currently logged in user, and make that data available globally.

The user you want to fetch might be determined by an id, and since Provider components can accept props, we can simply pass in an id so when our Context mounts, we fetch the user.

Here's what the provider component looks like.

export const UserProvider: React.FC<{ id: string }> = ({ id, children }) => {
  const [state, dispatch] = React.useReducer(userReducer, { isLoading: true });

  React.useEffect(() => {
    const handleGetUser = async id => {
      dispatch({ type: UserActionTypes.LOADING });
      const user = await getUserById(id);
      dispatch({ type: UserActionTypes.SUCCESS, payload: user });
      return;
    };
    handleGetUser(id);
    return;
  }, [id]);

  return (
    <UserStateContext.Provider value={state}>
      <UserDispatchContext.Provider value={dispatch}>
        {children}
      </UserDispatchContext.Provider>
    </UserStateContext.Provider>
  );
};

In most of my applications, I'm using hooks, so we will define the hooks here.

export const useUserState = () => {
  const userStateContext = React.useContext(UserStateContext);
  if (userStateContext === undefined) {
    throw new Error("useUserState must be used within a UserProvider");
  }
  return userStateContext;
};

export const useUserDispatch = () => {
  const userDispatchContext = React.useContext(UserDispatchContext);
  if (userDispatchContext === undefined) {
    throw new Error("useUserDispatch must be used within a UserProvider");
  }
  return userDispatchContext;
};

Wrapping Up

Here's everything together:

import * as React from "react";
import { getUserById } from "../services/user-service";
import { User } from "../types/user";

interface UserState {
  user?: User;
  isLoading: boolean;
}
enum UserActionTypes {
  LOADING = "loading",
  SUCCESS = "success"
}
type UserAction =
  | { type: UserActionTypes.LOADING }
  | { type: UserActionTypes.SUCCESS; payload: User };
type UserDispatch = (action: UserAction) => void;

const UserStateContext = React.createContext<UserState | undefined>(undefined);
const UserDispatchContext = React.createContext<UserDispatch | undefined>(
  undefined
);

function userReducer(state: UserState, action: UserAction): UserState {
  switch (action.type) {
    case UserActionTypes.LOADING: {
      return { isLoading: true };
    }
    case UserActionTypes.SUCCESS: {
      return { isLoading: false, user: action.payload };
    }
    default: {
      throw new Error("Invalid action type");
    }
  }
}

export const UserProvider: React.FC<{ id: string }> = ({ id, children }) => {
  const [state, dispatch] = React.useReducer(userReducer, { isLoading: true });

  React.useEffect(() => {
    const handleGetUser = async id => {
      dispatch({ type: UserActionTypes.LOADING });
      const user = await getUserById(id);
      dispatch({ type: UserActionTypes.SUCCESS, payload: user });
      return;
    };
    handleGetUser(id);
    return;
  }, [id]);

  return (
    <UserStateContext.Provider value={state}>
      <UserDispatchContext.Provider value={dispatch}>
        {children}
      </UserDispatchContext.Provider>
    </UserStateContext.Provider>
  );
};

export const useUserState = () => {
  const userStateContext = React.useContext(UserStateContext);
  if (userStateContext === undefined) {
    throw new Error("useUserState must be used within a UserProvider");
  }
  return userStateContext;
};

export const useUserDispatch = () => {
  const userDispatchContext = React.useContext(UserDispatchContext);
  if (userDispatchContext === undefined) {
    throw new Error("useUserDispatch must be used within a UserProvider");
  }
  return userDispatchContext;
};

This is the fifth post in a series of posts I will be doing. If you enjoyed this, please give me some hearts and leave a comment below. What else would you

As always, I'm open to recommendations.

Thanks for reading.

React & Firebase: Add Firebase to a React App

faraz ahmad — Thu, 04 Jun 2020 21:20:01 +0000

Note: With the release of v9 of the firebase library, this post is out of date.

I've been using React together with Firebase for several years now, and I've decided to share some things I've learned along the way. This is my first post in a series which I am titling "React & Firebase". If you are interested in more posts like this, please follow me and share this article. Thanks!

Getting started

All you need is a free Firebase account. To create a Firebase project, you'll need an email address that is powered by Google/Gmail.

Create a Firebase project

Go to https://console.firebase.google.com
Click on + Add Project.
Follow the steps to create your Firebase project.

Register a web app for your Firebase project

Navigate to the Firebase project settings.
Select the web platform under Your Apps section.
Enter an app name to register your app. Note, we won't be going over Firebase Hosting in this lesson, so you don't have to enable it.
Once you finish the steps, you will be presented with your Firebase app's configuration. Copy the configuration values, we will need these when we are initializing Firebase in your React app.

You only need to copy the the configuration object, not the entire snippet, because we will be installing the Firebase client SDK from npm.

Add Firebase to your React app

Install the Firebase SDK via `yarn`.

yarn add firebase

Initialize your Firebase app

Using the config values you copied in the previous step, you can initialize your Firebase application.

Initialize Firebase in the index.js file.



import React from "react";
import ReactDOM from "react-dom";
import App from "./App";
import firebase from "firebase/app";

// Use your config values here.
firebase.initializeApp({
  apiKey: "AIzaSyDHE9fVBUM_mto-p_SkWnyKtOiRu8M5F98",
  authDomain: "react-firebase-farazamiruddin.firebaseapp.com",
  databaseURL: "https://react-firebase-farazamiruddin.firebaseio.com",
  projectId: "react-firebase-farazamiruddin",
  storageBucket: "react-firebase-farazamiruddin.appspot.com",
  messagingSenderId: "338564911587",
  appId: "1:338564911587:web:c34e6fee0ff41bbe7fd0d6"
});

const rootElement = document.getElementById("root");
ReactDOM.render(
  <React.StrictMode>
    <App />
  </React.StrictMode>,
  rootElement
);

Verify the application was initialized correctly

To verify, we can simple display some information about our Firebase app in the browser.

Add the following to the App.js file.



import React from "react";
import firebase from "firebase";

export default function App() {
  const firebaseApp = firebase.apps[0];
  return (
    <div>
      <h1>React & Firebase</h1>
      <h2>By @farazamiruddin</h2>
      <code>
        <pre>{JSON.stringify(firebaseApp.options, null, 2)}</pre>
      </code>
    </div>
  );
}

When you initialize a Firebase app, the Firebase will append this app in the apps array. We are grabbing the first item in this array (since we only have one app) and printing out it's options to the browser. These options should match our config values we copied from the Firebase project settings page.

If you followed along, you should see this in your browser.

Wrapping up

In this lesson, we went over how to add Firebase to a React app. If you liked this post, please follow me and share it online.

If you'd like to stay in touch, reach out to me on twitter.
@farazamiruddin

Till next time.

Opinionated React: Use State Colocation

faraz ahmad — Thu, 23 Apr 2020 18:22:56 +0000

Intro

I’ve been working with React for over four years. During this time, I’ve formed some opinions on how I think applications should be. This is part 4 in the series of such opinionated pieces.

Why

State location helps reduce the complexity of your application. In some cases, it can actually improve performance.

What does colocate your state mean?

Simply put, it means to put your state as close to where it's being used. You should avoid global state unless it's absolutely necessary.

An example

Here's some code that I've come across several times in my career. I would avoid doing this.

import * as React from "react";

interface PersonFormState {
  firstName: string;
  lastName: string;
}

interface PersonFormAction {
  type: "SET_VALUE";
  payload: { [name: string]: string };
}

function personFormReducer(state: PersonFormState, action: PersonFormAction) {
  switch (action.type) {
    case "SET_VALUE": {
      return { ...state, ...action.payload };
    }
    default: {
      return state;
    }
  }
}

export const PersonFormContainer: React.FC = () => {
  const [state, dispatch] = React.useReducer(personFormReducer, {
    firstName: "",
    lastName: ""
  });

  const handleChange = (name: string, value: string) => {
    const updatedValue = { [name]: value };
    return dispatch({ type: "SET_VALUE", payload: updatedValue });
  };

  return <PersonForm values={state} onChange={handleChange} />;
};

interface PersonFormProps {
  values: {
    firstName: string;
    lastName: string;
  };
  onChange: (name: string, value: string) => void;
}

const PersonForm: React.FC<PersonFormProps> = ({ values, onChange }) => {
  return (
    <form>
      <label htmlFor="firstName">First name</label>
      <input
        name="firstName"
        value={values.firstName}
        onChange={event => onChange(event.target.name, event.target.value)}
      />
      <label htmlFor="lastName">Last name</label>
      <input
        name="lastName"
        value={values.lastName}
        onChange={event => onChange(event.target.name, event.target.value)}
      />
    </form>
  );
};

I find this code overcomplicated and hard to follow. It's also good to note that this will perform poorly, because we are causing a re-render of our entire state tree every time an input's value changes.

Use colocation to simplify your code.

Here's how I would write this.

import * as React from "react";

export const PersonForm: React.FC = () => {
  return (
    <form>
      <label htmlFor="firstName">First name</label>
      <PersonInput name="firstName" />
      <label htmlFor="lastName">Last name</label>
      <PersonInput name="lastName" />
    </form>
  );
};

interface PersonInputProps {
  name: string;
}

const PersonInput: React.FC<PersonInputProps> = ({ name }) => {
  const [value, setValue] = React.useState("");

  return (
    <input
      name={name}
      value={value}
      onChange={event => setValue(event.target.value)}
    />
  );
};

I would always start with state colocation and then lift state when needed. Keep things simple!

Q&A

Every post I will answer a question I received on twitter. Here's this week's question.

Best indicators for when something should be handled as application-level state vs. component-level state?
— jackgannon_ (@jackgannon_) February 28, 2020

There are very few things that I consider global. Most state should be colocated where it's being used. Here are a couple things that I consider global:

The current user
Language settings
A theme

Outside of these three, I'm not sure anything else needs to be global. 👍

Wrapping Up

This is the 4th installment in a series of pieces I will be writing. If you enjoyed this, please comment below. What else would you like me to cover? As always, I’m open to feedback and recommendations.

Thanks for reading.

P.S. If you haven’t already, be sure to check out my previous posts in this series:

Opinionated React: State Management

faraz ahmad — Fri, 06 Mar 2020 15:40:12 +0000

Intro

I’ve been working with React for over four years. During this time, I’ve formed some opinions on how I think applications should be. This is part 3 in the series of such opinionated pieces.

What I'll be covering

There are a lot of parts to state management. I won't be able to cover them all in one sitting. For this post, I'll show you how I use plain React to manage state in my components.

Make sure to follow me for my future posts related to state management, where I'll write about:

Component level state vs global state
Good use cases and my pattern for React context
Status enums instead of booleans

Just use React

Too often have I seen teams adopt state management libraries like Redux, MobX, or something else before using React‘s built in state management solution.

There's nothing wrong with these libraries, but they are not necessary to build a fully functioning React application. In my experience, it is significantly easier to use plain React.

If you have a reason to use one of these libraries instead of using useState or useReducer, please leave a comment because I would love to know your use case.

Next time you build a component, try using plain React.

Hooks

I mentioned two hooks above, useState and useReducer. Here’s how I use each of them.

Start with useState

I start by building my components with the useState hook. It’s quick and gets the job done.

const MovieList: React.FC = () => {
  const [movies, setMovies] = React.useState<Movie[]>([])

  React.useEffect(() => {
    MovieService
      .fetchInitialMovies()
      .then(initialMovies => setMovies(initialMovies))
  }, [])

  return (
    <ul>
      {movies.map(movie => <li key={movie.id}>{movie.title}</li>}
    </ul>
  )
}

If we need another piece of state, simply add another useState hook

const MovieList: React.FC = () => {
  const [isLoading, setIsLoading] = React.useState<boolean>(true)
  const [movies, setMovies] = React.useState<Movie[]>([])

  React.useEffect(() => {
    MovieService
      .fetchInitialMovies()
      .then(initialMovies => setMovies(initialMovies))
      .then(() => setIsLoading(false))
  }, [])

  if (isLoading) {
    return <div>Loading movies...</div>
  }

  return (
    <ul>
      {movies.map(movie => <li key={movie.id}>{movie.title}</li>}
    </ul>
  )
}

useReducer when you have a lot of state

My limit for related pieces of state is 2. If I have 3 pieces of state that are related to each other, I opt for useReducer.

Following the above example, let's say we wanted to display an error message if fetching the movies failed.

We could add another useState call, but I think it looks a bit messy 😢.

export const MovieList: React.FC = () => {
  const [isLoading, setIsLoading] = React.useState<boolean>(true);
  const [movies, setMovies] = React.useState<Movie[]>([]);
  const [error, setError] = React.useState<string>("");

  const handleFetchMovies = () => {
    setIsLoading(true); // 😢
    setError(""); // 😢
    return MovieService.fetchInitialMovies()
      .then(initialMovies => {
        setMovies(initialMovies);
        setIsLoading(false); // 😢
      })
      .catch(err => {
        setError(err.message); // 😢
        setIsLoading(false); // 😢
      });
  };

  React.useEffect(() => {
    handleFetchMovies();
  }, []);

  if (isLoading) {
    return <div>Loading movies...</div>;
  }

  if (error !== "") {
    return (
      <div>
        <p className="text-red">{error}</p>
        <button onClick={handleFetchMovies}>Try again</button>
      </div>
    );
  }

  return (
    <ul>
      {movies.map(movie => (
        <li key={movie.id}>{movie.title}</li>
      ))}
    </ul>
  );
};

Let's refactor this to use useReducer, which will simplify our logic.

interface MovieListState {
  isLoading: boolean;
  movies: Movie[];
  error: string;
}

type MoveListAction =
  | { type: "fetching" }
  | { type: "success"; payload: Movie[] }
  | { type: "error"; error: Error };

const initialMovieListState: MovieListState = {
  isLoading: true,
  movies: [],
  error: ""
};

const movieReducer = (state: MovieListState, action: MoveListAction) => {
  switch (action.type) {
    case "fetching": {
      return { ...state, isLoading: true, error: "" };
    }
    case "success": {
      return { ...state, isLoading: false, movies: action.payload };
    }
    case "error": {
      return { ...state, isLoading: false, error: action.error.message };
    }
    default: {
      return state;
    }
  }
};

export const MovieList: React.FC = () => {
  const [{ isLoading, error, movies }, dispatch] = React.useReducer(
    movieReducer,
    initialMovieListState
  );

  const handleFetchMovies = () => {
    dispatch({ type: "fetching" });
    return MovieService.fetchInitialMovies()
      .then(initialMovies => {
        dispatch({ type: "success", payload: initialMovies });
      })
      .catch(error => {
        dispatch({ type: "error", error });
      });
  };

  React.useEffect(() => {
    handleFetchMovies();
  }, []);

  if (isLoading) {
    return <div>Loading movies...</div>;
  }

  if (error !== "") {
    return (
      <div>
        <p className="text-red">{error}</p>
        <button onClick={handleFetchMovies}>Try again</button>
      </div>
    );
  }

  return (
    <ul>
      {movies.map(movie => (
        <li key={movie.id}>{movie.title}</li>
      ))}
    </ul>
  );
};

Q&A

Every post I will answer a question I received on twitter. Here's this week's question.

My main problem is that I don't understand when I should use Redux. I don't hate Redux, I know how it works (on a simple way) but don't understand why hooks are not enough in comparison of state managers like Redux, Effector or MobX

would love to hear opinions about that
— ｖ１ｒｔｌ (@v1rtl) February 28, 2020

I don't use redux anymore. I haven't used it since React's context api was released. IMO, I think hooks + context are enough to build your application.

Wrapping Up

This is the 3rd installment in a series of pieces I will be writing. If you enjoyed this, please comment below. What else would you like me to cover? As always, I’m open to feedback and recommendations.

Thanks for reading.

P.S. If you haven’t already, be sure to check out my previous posts in this series:

Opinionated React: Component File Structure

faraz ahmad — Mon, 24 Feb 2020 13:56:01 +0000

Intro

I’ve been working with React for over four years. During this time, I’ve formed some opinions on how I think applications should be. This is part 2 in the series of such opinionated pieces.

Component File Structure

I have a convention that I use when creating component files. I like the put the things that I find the most important at the top, and anything that is not necessary for someone using my component to know at the bottom.

File Structure

import * as React from "react";
import { gql } from "apollo-boost";
import { useQuery } from "@apollo/react-hooks";
import { Movie } from "../types/Movie";

const MOVIE_LIST_QUERY = gql`
  query MovieListQuery($movieListId: ID!) {
    movieList(movieListId: $movieListId) {
      id
      name
      movies {
        id
        title
        releaseDate
      }
    }
  }
`;

interface MovieListProps {
  movieListId: string;
}

export const MovieList: React.FC<MovieListProps> = ({ movieListId }) => {
  const { data, loading } = useQuery(MOVIE_LIST_QUERY, {
    variables: { movieListId }
  });

  if (loading) {
    return <div>Loading...</div>;
  }

  return (
    <div>
      <h1>{data.movieList.name}</h1>
      <ul>
        {data.movieList.movies.map((movie: Movie) => (
          <MovieListItem key={movie.id} {...movie} />
        ))}
      </ul>
    </div>
  );
};

const MovieListItem: React.FC<Movie> = ({ title, releaseDate }) => {
  return (
    <div>
      <h3>{title}</h3>
      <p>{releaseDate}</p>
    </div>
  );
};

When I use a component, I ask myself these questions:

Is this component fetching any data?
What are the props that this component is expecting?
What does this component render?

This is why I lay my files out this way:

Queries first: The first thing I want to see is what external data is this component using, if any. That’s why I put my GraphQL calls at the top of the file. When I first open the file, I can see that this component is fetching a list of movies, and I know what the shape of that response will be. I put my GraphQL queries in the same file as the component consuming them, because I don’t want to have to jump between files to know what’s being fetched.

Type definitions: I follow the data dependencies with the type definitions for the component. This way I know what props this component needs for me to pass in.

The actual component: This is when I place the code for my component. After I know what data it is fetching, and what props it needs, I want to know what JSX is actually being rendered. I use a named export and export the component inline so that it is easier to change the name of the component if needed.

Sub components: In my previous post, I mentioned that I like to have any sub-components related to the current component in the same file. I place these after the main component, since it is not required for a user to know about these components at all.

Wrapping Up

This is the 2nd installment in a series of pieces I will be writing. If you enjoyed this, please comment below. What else would you like me to cover? As always, I’m open to feedback and recommendations.

Thanks for reading.

P.S. If you haven’t already, be sure to check out my first post in this series, An Opinionated Guide to React: Folder Structure and File Naming.

Opinionated React: Folder Structure & File Naming

faraz ahmad — Sun, 16 Feb 2020 20:44:59 +0000

Intro

I've been working with React for over 4 years. During this time, I've formed some opinions on how I think applications should be. This is part 1 in a collection of those opinions.

Folder Structure & File Naming

I have gone through many iterations of folder structure in the applications that I worked on. The one that I have found scales the best is to have flat folders and long file names. Since I use VSCode, it is easy to search for files, so the longer the name, the better. Here's how I layout most of my React applications.

Folder Structure

/react-app
  /build
  /node_modules
  /public
  /src
    /assets
    /components
    /contexts
    /lib
    /pages
    /services
    /styles
    AppRoutes.tsx
    index.tsx
    react-app-env.d.ts

  package.json
  README.md
  tsconfig.json
  yarn.lock

Here's a quick overview of what are in these folders.

/assets - images, logos.
/components - components that are shared between multiple pages.
/contexts - I keep all of the context components in a separate folder, to not confuse them with plain old react components. A common context I like to implement is UserAuthContext.tsx.
/lib - When using a 3rd party library, let's say like Firebase for example, I like to put all of the initialization in a folder called lib. I'll then export the instance of that initialized library.

import firebase from "firebase/app";
firebase.initializeApp({
  apiKey: process.env.REACT_APP_FIREBASE_API_KEY,
  authDomain: process.env.REACT_APP_FIREBASE_AUTH_DOMAIN,
  appId: process.env.REACT_APP_FIREBASE_APP_ID
});
export default firebase;

/pages - Pages are also react components, but they represent a page or screen of an app. These map 1:1 with a route in the AppRoutes.tsx file.
/services - All of my api methods are put in a folder called services. I like to do this so that I don't put the business logic of an API call directly into a component, and so that any component can easily reference a service that it needs.
/styles - I very rarely write custom css, instead opting to use a framework like tailwindcss. This styles folder is where my generated styles and any custom css goes.
AppRoutes - This file contains all the routes of my application. I've been using react-router for a while, and I like to have one file that contains all my routes so that I can see it all at a glance.

import React from "react";
import { Switch, BrowserRouter, Route } from "react-router-dom";
import { useAuthContext } from "./contexts/AuthContext";
import { Navbar } from "./components/Navbar";
import { LandingPage } from "./pages/LandingPage";
import { DashboardPage } from "./pages/DashboardPage";

export const AppRoutes: React.FC = () => {
  const authAccount = useAuthContext();

  return (
    <BrowserRouter>
      <div className="mt-8 w-4/5 max-w-6xl m-auto">
        <Navbar />
      </div>
      <Switch>
        {authAccount ? (
          <AuthenticatedAppRoutes />
        ) : (
          <UnauthenticatedAppRoutes />
        )}
      </Switch>
    </BrowserRouter>
  );
};

const UnauthenticatedAppRoutes: React.FC = () => {
  return (
    <React.Fragment>
      <Route exact path="/" component={LandingPage} />
    </React.Fragment>
  );
};

const AuthenticatedAppRoutes: React.FC = () => {
  return (
    <React.Fragment>
      <Route exact path="/" component={DashboardPage} />
    </React.Fragment>
  );
};

index.tsx - This is your typical index file, where you render your React app to the document.

File Naming

My rule of thumb is the longer and more descriptive the file name, the better. For files that that export React components I use PascalCase, for everything else I use dash-case.

# PascalCase
/components/NavBar.tsx
/contexts/UserAuthContext.tsx
/pages/DashboardPage.tsx
# dash-case
/services/auth-service.ts
/lib/apollo-client.ts

I always prefer named exports instead of default exports. This makes it easier to search what I'm looking for in my editor.

Updates

I received some questions about this post, here are my responses:

Would be very interesting to see the structure inside of /components. Is there any nesting? A folder for each component with styles/test/... next to the component file itself?

I don't use any nesting in any of the folders. I also typically don't have a separate styles file, since I use frameworks like tailwind or bootstrap. The shape of of my components folder is like so:

/components
  /__tests__
    Button.test.tsx
Button.tsx

What do you do with one-off components? For example, a Contacts.jsx page has a ContactList component?

I will split up my page into sub-components, all within the same file as the page.

import * as React from 'react'

export const ContactsPage: React.FC = () => {
  return (
    <div>
      <h1>Contacts</h1>
      <ContactsList />
    </div>
  )
}

const ContactsList: React.FC = () => { ... }

Wrapping Up

This is the first post in a series of posts I will be doing. If you enjoyed this, please give me some hearts and leave a comment below. What else would you

As always, I'm open to recommendations.

Thanks for reading.

DEV Community: faraz ahmad

How you can have productive retrospective meetings

Here's a list of why your retrospective meeting is broken, causing your team could be falling short of their potential.

Here are some tips that can help you run more effective retrospective meetings

Retro automatically sorts items by like count

Get 2 months free of Retro by joining the newsletter

Get 2 Months Free

React & Firebase: Authenticate a User with Email and Password

Note: With the release of v9 of firebase library, this post is now out of date.

Opinionated React - Use Status Enums Instead of Booleans

Intro

Why

Why It's a Bad Idea - an Example

A Better Approach - use Enums

Wrapping Up

Opinionated React: Use Context for Shared State

Intro

My Pattern for React Context

Why

Use Cases - Important!

Inspiration

Example

Wrapping Up

React & Firebase: Add Firebase to a React App

Note: With the release of v9 of the firebase library, this post is out of date.

Getting started

Create a Firebase project

Register a web app for your Firebase project

Add Firebase to your React app

Install the Firebase SDK via yarn.

Initialize your Firebase app

Verify the application was initialized correctly

Wrapping up

Opinionated React: Use State Colocation

Intro

Why

What does colocate your state mean?

An example

Use colocation to simplify your code.

Q&A

Wrapping Up

Opinionated React: State Management

Intro

What I'll be covering

Just use React

Hooks

Start with useState

useReducer when you have a lot of state

Q&A

Wrapping Up

Opinionated React: Component File Structure

Intro

Component File Structure

File Structure

Wrapping Up

Opinionated React: Folder Structure & File Naming

Intro

Folder Structure & File Naming

Folder Structure

File Naming

Updates

Wrapping Up

Install the Firebase SDK via `yarn`.