Forem: Andrej Tlčina

Building a Collaborative Todo App w/ live cursors using GraphQL subscriptions

Andrej Tlčina — Sat, 03 Sep 2022 14:54:59 +0000

Hello! I started a new project! I initially wanted to do a chat app, but then I realized, I would be just following tutorials, so I decided to build a collaborative real-time todo app, where each user can see the cursors of other users. My immediate thinking went to socket.io, but then I found video by Jack Herrington. In this video, Jack used GraphQL subscriptions, which are (by my super scientific explanation) GraphQL WebSockets. When a subscription is defined on the server and the client subscribes to it, the user can get new data via a WebSocket connection.
Once I did a little research, I realized I could build a real-time app with the help of GraphQl. Two things (real-time and GraphQL) I always wanted to try.
So, here's a little preview of what I've built and a bit of explanation of how I did it 😉

By the way, I won't be talking about things like "what is GraphQL", because there's a lot of better sources for that. Also, no styles or react components, because I'm hoping you'll create your own components and styles.

Set-up

For this project, I needed a server and client. In the empty directory, I created a server folder. In the server folder I created src/index.tsx, then ran npm init -y and downloaded a few things

yarn add -D @types/node @types/uuid nodemon ts-node typescript
yarn add graphql-yoga uuid

nodemon is there for running the server, for that I also had to create a new script "dev": "nodemon" and nodemon.json next to package.json. nodemon.json holds configuration mine can be found here

For this project I used MongoDB. You can get free DB following this link. To work with DB, I love to use prisma. You can set up prisma following this link

For client set-up we can use Vite by running

yarn create vite client --template react-ts

I also added tailwind via this guide.

We can add really necessary packages on client via

yarn add @apollo/client graphql subscriptions-transport-ws throttle-typescript

In the previous paragraph, I wrote really necessary packages, because I used packages like @react/dialog, which are cool but not necessary, and you don't even need tailwind, if you like other full-fledged UI libraries, for instance, Chakra UI.

Initialize Server-Client connection

Obviously, we want the server and client to "talk" to each other. For that, we have to initialize the server and then connect the client to it.
In server/index.tsx

import { GraphQLServer, PubSub } from "graphql-yoga";
import { PrismaClient } from "@prisma/client";

const pubsub = new PubSub();
const prisma = new PrismaClient();

export interface Context {
  pubsub: PubSub;
  prisma: PrismaClient;
}

const typeDefs = `
  type Query {
    hello: String!
  }
`

const resolvers = {
  Query: {
    hello: () => "world",
  },
}

const server = new GraphQLServer({
  typeDefs,
  resolvers,
  context: { pubsub, prisma } as Context,
});

server.start(({ port }) => {
  console.log(`Server on http://localhost:${port}/`);
});

After running yarn dev we should get a log with the following:

Server on http://localhost:4000/

That means server is running, and after visiting http://localhost:4000/, there's a GraphiQL interface, where we can test our queries and whatnot.

To connect client to server I like to create a file app/App.tsx, where I'll have something like

import React from "react";

import WithApollo from "./withApollo";

function App() {
  return (
    <WithApollo>
      // other providers and components
    </WithApollo>
  );
}

export default App;

You can see me importing a WithApollo provider. Code for that is in app/withApollo.tsx

import React from "react";
import { ApolloClient, ApolloProvider, InMemoryCache } from "@apollo/client";
import { WebSocketLink } from "@apollo/client/link/ws";

const link = new WebSocketLink({
  uri: `ws://localhost:4000/`,
  options: {
    reconnect: true,
  },
});

const client = new ApolloClient({
  link,
  uri: "http://localhost:4000/",
  cache: new InMemoryCache(),
});

const WithApollo = (props: React.PropsWithChildren<{}>) => {
  const { children } = props;

  return <ApolloProvider client={client}>{children}</ApolloProvider>;
};

export default WithApollo;

You can see a WebSocketLink, which listens to websocket traffic and ApolloClient which helps us with creating GraphQL request to server. Speaking of let's make one in app/App.tsx

import { gql, useQuery } from '@apollo/client';
const GET_HELLO = gql`
  query {
    hello
  }
`;

function App() {
  const { data } = useQuery(GET_HELLO);

  console.log(data) 

  return (
    <WithApollo>
      // other providers and components
    </WithApollo>
  );
}

In console, you should see something like:

{
 "hello" : "world"
}

Live cursors

When adding a new feature on the server I usually first define types in the schema and then I complete the feature in the resolver. In the schema, I added

const typeDefs = `
  type Cursor {
    id: ID!
    name: String!
    x: Float!
    y: Float!
  }
  input CursorInput {
    id: ID!
    name: String!
    x: Float!
    y: Float!
  }
  type Query {
    cursors: [Cursor!]
  }
  type Mutation {
    updateCursor(c: CursorInput!): ID!
    deleteCursor(id: ID!): ID!
  }
  type Subscription {
    cursors(c: CursorInput): [Cursor!]
  }

There's no addCursor mutation, because that's done via subscription, speaking of, to resolver, I added

import type { Context } from "./server";

interface Cursor {
  id: string;
  name: string;
  x: number;
  y: number;
}

const cursors: { [id: string]: Cursor } = {};

const cursorsSubscribers: (() => void)[] = [];
const onCursorsUpdates = (fn: () => void) => cursorsSubscribers.push(fn);
const spreadCursors = () => cursorsSubscribers.forEach((fn) => fn());

const generateChannelID = () => Math.random().toString(36).slice(2, 15);

const resolvers = {
  Query: {
    cursors: () => [...Object.values(cursors)],
  },
  Mutation: {
    updateCursor: (_: any, args: { c: Cursor }) => {
      if (!args?.c?.id) return "";

      cursors[args.c.id] = {
        ...cursors[args.c.id],
        ...args.c,
      };
      spreadCursors();
      return args.c.id;
    },
    deleteCursor: (_: any, args: { id: string }) => {
      if (!args?.id) return "";

      delete cursors[args.id];
      spreadCursors();

      return args.id;
    },
  },
  Subscription: {
    cursors: {
      subscribe: (
        _: any,
        args: { c: Cursor },
        { pubsub }: { pubsub: Context["pubsub"] }
      ) => {
        const channel = generateChannelID();

        if (!args.c.id) return;

        cursors[args.c.id] = { ...args.c };

        onCursorsUpdates(() =>
          pubsub.publish(channel, { cursors: [...Object.values(cursors)] })
        );
        setTimeout(
          () =>
            pubsub.publish(channel, {
              cursors: [...Object.values(cursors)],
            }),
          0
        );

        return pubsub.asyncIterator(channel);
      },
    },

  },
};

There's some any types, because I did not set up codegen, and also I do not use that first argument (hence the _).

That's the server setup. The subscription is listening for when the new cursor is added through the client. updateCursor updates the position of the cursor, when the user moves the mouse and lastly, the cursor is deleted when a client leaves the app (closes the tab).

Let's add these events to client, but first I want to bring up an article that helped me understand animating cursors (I also copied their cursor code). You can read it here

The code for cursor is here

// components/Cursor.tsx

function CursorSvg({ color }: { color: string }) {
  return (
    <svg
      width={CURSOR_SIZE}
      height={CURSOR_SIZE}
      viewBox="0 0 24 36"
      fill="none"
    >
      <path
        fill={color}
        d="M5.65376 12.3673H5.46026L5.31717 12.4976L0.500002 16.8829L0.500002 1.19841L11.7841 12.3673H5.65376Z"
      />
    </svg>
  );
}

First, I created a collab area, where all cursors, including the current user's cursor, will be

//  components/CollabArea.tsx

interface Cursor {
  id: string;
  name: string;
  x: number;
  y: number;
}

interface Cursors {
  cursors: Cursor[];
}

const CURSORS = gql`
  subscription ($cursor: CursorInput!) {
    cursors(c: $cursor) {
      id
      name
      x
      y
    }
  }
`;

const CollabArea = (props: React.PropsWithChildren<{}>) => {
  const { children } = props;

  const [currentUser, setCurrentUser] = React.useState({ id: "", name: "" });

  const { data } = useSubscription<Cursors>(CURSORS, {
    variables: {
      cursor: { id: currentUser.id, name: currentUser.name, x: 0, y: 0 },
    },
    shouldResubscribe: !!currentUser.id,
    skip: !currentUser.id,
  });

  return (
    <React.Fragment>
      /* this can be a simple form, where users will type their names, the ID can be done with simple Date.now().toString(), at least for now (probably not in production) */
      <UserEnter setCurrentUser={setCurrentUser} />

      {data?.cursors.map((c) => {
        const posX = c.x * window.innerWidth;
        const posY = c.y * window.innerHeight;

        return (
          <Cursor
            key={c.id}
            id={c.id}
            name={c.name}
            x={posX}
            y={posY}
          />
        );
      })}

      {children}
    </React.Fragment>
  );
};

The CollabArea is a wrapper containing all cursors. With the help of useSubscription I could subscribe to the server and now every time, there will be a change on the server, involving cursors, the server will send the updated data to the client. To display the cursor I've made a component called (you guessed it) Cursor

// components/Cursor.tsx

import { motion, useMotionValue } from "framer-motion";

const CURSOR_SIZE = 30;

const Cursor = (
  { id, name, x, y, current } = {
    id: "0",
    name: "",
    x: 0,
    y: 0,
  }
) => {
  const posX = useMotionValue(0);
  const posY = useMotionValue(0);

  React.useEffect(() => {
    posX.set(x - CURSOR_SIZE / 2);
  }, [x]);

  React.useEffect(() => {
    posY.set(y - CURSOR_SIZE / 2);
  }, [y]);

  /* you can get color however you like, even randomly */
  const color = getColor(name);

  return (
    <motion.div
      style={{
        top: "0",
        left: "0",
        position: "absolute",
        zIndex: "999999999",
        pointerEvents: "none",
        userSelect: "none",
        transformOrigin: "left",
      }}
      initial={{ x: posX.get(), y: posY.get() }}
      animate={{ x: posX.get(), y: posY.get() }}
      transition={{
        type: "spring",
        damping: 30,
        mass: 0.8,
        stiffness: 350,
      }}
    >
      <CursorSvg color={color} />
    </motion.div>
  );
};

Now, I have these cursors changing their position, when x or y coordinates change, but they're not changing 😅. All the cursors are now in the position [0, 0]. To update their positions I'll create a hook

// components/CollabArea.tsx

import { throttle } from "throttle-typescript";

const UPDATE_CURSOR = gql`
  mutation ($cursor: CursorInput!) {
    updateCursor(c: $cursor)
  }
`;

const useUpdateCursor = (id: string, name: string) => {
  const [updateCursor] = useMutation(UPDATE_CURSOR);

  const [visible, setVisible] = React.useState(false);

  const hideCursor = () => setVisible(false);
  const showCursor = () => setVisible(true);

  const onMouseMove = (e: MouseEvent) => {
    const posX = e.clientX;
    const posY = e.clientY;

    const serverPosition = {
      x: posX / window.innerWidth,
      y: posY / window.innerHeight,
    };

    updateCursor({
      variables: {
        cursor: {
          id,
          name,
          ...serverPosition,
        },
      },
    });
  };
  const onThrottledMouseMove = React.useCallback(throttle(onMouseMove, 30), [
    id,
  ]);

  React.useEffect(() => {
    document.addEventListener("mousemove", onThrottledMouseMove);
    document.addEventListener("mouseleave", hideCursor);
    document.addEventListener("mouseenter", showCursor);

    return () => {
      document.removeEventListener("mousemove", onThrottledMouseMove);
      document.removeEventListener("mouseleave", hideCursor);
      document.removeEventListener("mouseenter", showCursor);
    };
  }, [id]);

  return { visible };
};

Here, I'm defining mutation and on each cursor move, I call it. I added an extra state for when the user leaves the collab area via visible state. To use it just add it to CollabArea component.

const CollabArea = (props: React.PropsWithChildren<{}>) => {
  ...

  const { visible } = useUpdateCursor(currentUser.id, currentUser.name);

  ...
  return (
    ...
    {data?.cursors.map((c) => {
        const posX = c.x * window.innerWidth;
        const posY = c.y * window.innerHeight;
        /* check if cursor belongs to current user */
        const isCurrent = currentUser.id === c.id;
        /* if it does and it's not visible don't display the cursor */
        if (isCurrent && !visible) return null;

        return (
          <Cursor
            key={c.id}
            id={c.id}
            name={c.name}
            current={isCurrent}
            x={posX}
            y={posY}
          />
        );
      })}

  )
}

Now, we can see the cursor updates when moving the mouse.

The movement will be a bit delayed. If you want your cursor to be "real-time" make a hook or use the state to achieve that, I kind of don't mind.

The last thing is to remove the cursor on the server when the user closes the tab. For that, I created another hook

const DELETE_CURSOR = gql`
  mutation ($id: ID!) {
    deleteCursor(id: $id)
  }
`;

const useRemoveUser = (userID: string) => {
  const [deleteCursor] = useMutation(DELETE_CURSOR);

  const onUserLeaving = async (event: Event) => {
    event.preventDefault();

    await deleteCursor({
      variables: {
        id: userID,
      },
    });

    return true;
  };

  React.useEffect(() => {
    window.onunload = onUserLeaving;

    return () => {
      window.onunload = null;
    };
  }, [userID]);

  return null;
};

Now, just add it to the CollabArea and we're done with the live cursors.

const CollabArea = (props: React.PropsWithChildren<{}>) => {
  ...
  useRemoveUser(currentUser.id);
  ...
}

Todos

So, todos are a little easier, mainly because we'll be implementing CRUD functionality. The todos will be saved in the database, so let's create a model

model Todo {
  id           String   @id @default(auto()) @map("_id") @db.ObjectId
  text         String
  is_completed Boolean
  order        Int
  created_at   DateTime @default(now())
  updated_at   DateTime @updatedAt
}

Let's continue with the schema. I kind of enjoy making these function definitions to get the bird's-eye view of the API or the server functionality.

const typeDefs = `
  type Todo {
    id: ID!
    text: String!
    is_completed: Boolean!
    order: Int!
  }
  type Query {
    ...
    messages: [Message!]
  }
  type Mutation {
    ...
    addTodo(text: String!): ID!
    updateTodo(id: ID!, is_completed: Boolean!): ID!
    deleteTodo(id: ID!): ID!
  }
  type Subscription {
    ...
    todos: [Todo!]
  }
`;

The names are hopefully self-explanatory. Again, the Read portion of the app will be done via Subscription or Query. Let's first subscribe to todos.

const todosSubscribers: (() => Promise<boolean>)[] = [];
const onTodosUpdates = (fn: () => Promise<boolean>) =>
  todosSubscribers.push(fn);
const spreadTodos = () => todosSubscribers.forEach(async (fn) => await fn());

const resolvers = {
  Query: {
    ...
    todos: async (
      _: any,
      _args: any,
      { prisma }: { prisma: Context["prisma"] }
    ) => await prisma.todo.findMany(),
  },
  Mutation: {
    ...
  },
  Subscription: {
    ...
    todos: {
      subscribe: async (_: any, _args: any, { pubsub, prisma }: Context) => {
        const channel = generateChannelID();

        // using function here, b/c if we would just get the todos, the result would be stale
        const getTodos = async () => await prisma.todo.findMany();

        onTodosUpdates(async () =>
          pubsub.publish(channel, { todos: await getTodos() })
        );
        setTimeout(
          async () => pubsub.publish(channel, { todos: await getTodos() }),
          0
        );

        return pubsub.asyncIterator(channel);
      },
    },
  },
};

Now, in components, I created TodosList component, which displays all the todos.

// components/TodosList.tsx

interface Todo {
  id: string;
  text: string;
  is_completed: boolean;
}

interface TodosQuery {
  todos: Todo[];
}

const GET_TODOS = gql`
  subscription {
    todos {
      id
      text
      is_completed
    }
  }
`;

const Todos = () => {
  const { data } = useSubscription<TodosQuery>(GET_TODOS);

  return (
    // map over data.todos and display them
  )
}

At first, there are no todos, unless the database was seeded. So, the next step will be adding an add todo functionality in resolvers.

const resolvers = {
...
Mutation: {
addTodo: async (_: any, { text }: { text: string }, ctx: Context) => {
const todos = await ctx.prisma.todo.findMany();

  const created = await ctx.prisma.todo.create({
    data: {
      text,
      is_completed: false,
      order: todos.length,
    },
  });

  spreadTodos();
  return created.id;
},

},
...
};

The adding of todo is done via Prisma client and all we have to pass in is a text of the todo. On the client we define mutation like this

const ADD_TODO = gql`
  mutation ($text: String!) {
    addTodo(text: $text)
  }
`;

const [postMessage] = useMutation(ADD_TODO);

and call it like this

postMessage({
  variables: { text: some_text },
});

The delete and update functionality is pretty similar so I'll show them both at once

const resolvers = {
  ...
  Mutation: {
    ...
    updateTodo: async (
      _: any,
      { id, is_completed }: { id: string; is_completed: boolean },
      ctx: Context
    ) => {
      await ctx.prisma.todo.update({
        where: {
          id,
        },
        data: {
          is_completed,
        },
      });

      spreadTodos();
      return id;
    },
    deleteTodo: async (_: any, { id }: { id: string }, ctx: Context) => {
      await ctx.prisma.todo.delete({
        where: {
          id,
        },
      });

      spreadTodos();
      return id;
    },
  },
};

And on the client we define mutations as

const UPDATE_TODO = gql`
  mutation ($id: ID!, $is_completed: Boolean!) {
    updateTodo(id: $id, is_completed: $is_completed)
  }
`;

const DELETE_TODO = gql`
  mutation ($id: ID!) {
    deleteTodo(id: $id)
  }
`;

const [updateTodo] = useMutation(UPDATE_TODO);
const [deleteTodo] = useMutation(DELETE_TODO);

Calling of mutations can be something like this

data.todos.map(({ id, text, is_completed }) => (
...
<label>
   <input
     onChange={async (e) =>
       await updateTodo({
         variables: {
           id,
           is_completed: e.target.checked,
         },
       })
     }
     checked={is_completed}
     type="checkbox"
     className="checkbox"
   />
</label>
...
<button
  onClick={async () =>
    await deleteTodo({
      variables: {
        id,
      },
    })
  }
  className="btn btn-circle btn-outline btn-error"
>
  <CoolIcon />
</button>
...
)

And that's about it for Todos.

Conclusion

This was over how I implemented live cursors and todo app in GraphQL. The functionality can be, of course, extended by updating/deleting more todos at once, changing the order of todos, and adding codegen for better DX. I also added a chat feature.

Here's a github for the whole project, styles, and whatnot.

Building Training Plan builder: Dealing w/ complex forms in Remix

Andrej Tlčina — Sun, 07 Aug 2022 18:09:00 +0000

Hello! Continuing this mini-series I'd like to share with you how I dealt with complex forms in Remix. You see, I'm creating this training plan builder, that currently looks like this

The Remix expects you to process data, sent to the backend, via actions. It's pretty cool when you're dealing with simple forms, but here I have these columns and each column has multiple exercises, so it'd be great if I could group the data somehow.

The first idea was to deal with it as they have it in docs, so something like this

export const action = async ({ request }) => {
  const formData = await request.formData();

  const title = formData.get("title");
  const slug = formData.get("slug");
  const markdown = formData.get("markdown");
  ...
}

This way I would somehow call Object.entries on formData while giving the input names like col-1-ex-1. You can imagine how tedious that was/would be. So, I searched for a solution and I found a pretty clever one with the help of the qs (querystring) package.

The package ensures I can give each of the exercise inputs names like

phases[${idx}][${exercise.id}][title]
phases[${idx}][${exercise.id}][sets]
phases[${idx}][${exercise.id}][reps]

which, after parsing the request with this snippet

export const action: ActionFunction = async ({ request }) => {
  const text = await request.text();
  const parsed = qs.parse(text) as YourCustomType

  ...
}

gives the following structure

phases: [
  {
     exerciseId: { 
        sets: number,
        reps: number,
        title: string,
     },
     exerciseId2: { 
        sets: number,
        reps: number,
        title: string,
     }
  },
  {
     exerciseId3: { 
        sets: number,
        reps: number,
        title: string,
     }
  },
  {
     exerciseId4: { 
        sets: number,
        reps: number,
        title: string,
     },
     exerciseId5: { 
        sets: number,
        reps: number,
        title: string,
     }
  },
] // 3 objects represent 3 columns (phases) in the app

This structure is much easier to work with. And the best thing is that I got this structure using only two lines of code 😅

Thanks for reading and hope this helps someone! Take care 😉

Source code -> Strongion

Original thread -> github discussion

Building Training Plan builder: DnD & Autocomplete

Andrej Tlčina — Sun, 31 Jul 2022 14:27:25 +0000

Hello! In the previous article I promised to talk about something more interesting. I was always curious about Drag and Drop functionality and I wanted to build something, which is going to use it as a feature. So, I came up with an app that helps you build a training plan by looking up different exercises. A plan consists of multiple phases, displayed as rectangle columns. I made up a scenario where the user will search for exercise. Upon selecting one, it will be appended into the special non-phase column. Users can then, drag this exercise from the non-phase column to any other. Exercises will be displayed as simple rectangles with a name, a button for removing a given exercise, and two inputs for filling out sets and reps. So let's start building.

Autocomplete

I'd like to start things off by first creating autocomplete component, so we get the exercise options. For the component, I'll be using a library called Downshift. It is a headless UI component, which means I'll have all the needed functionality and state management, but no UI, which is a great pattern. Sometimes these component libraries can be too rigid that you can't customize them, this however gives you as much freedom as you want. I pretty much looked at the docs and followed along. The stuff that I added was fetching data from an external API. For that, I used debounce, so we don't fetch on every key press, but after some time of inactivity. However there's a catch with debounce in React, you have to use it in useCallback (more on that here). Also, when there are no exercises found I display the "No results" option in the list of options. The component will look like this

const NO_OPTIONS_OPT = {
  value: "NO_OPTIONS",
  data: {
    id: 0,
    name: "NO_OPTIONS",
    category: "",
    image: null,
    image_thumbnail: null,
  },
  info: { sets: 0, reps: 0 },
};

const getExerciseFilter =
  (inputValue: string | undefined) => (item: ExerciseSuggestion) => {
    return !inputValue || item.value.includes(inputValue);
  };

const AutoComplete = (props: {
  setSearchedExercises: (r: ExerciseSuggestion[]) => void;
}) => {
  const { setSearchedExercises } = props;

  const [items, setItems] = React.useState<ExerciseSuggestion[]>([]);

  const onInputValueChange = React.useCallback(
    debounce(
      async ({ inputValue }: UseComboboxStateChange<ExerciseSuggestion>) => {
        const { suggestions } = await searchExercises(inputValue || "");

        if (!suggestions || !suggestions.length) {
          setItems([NO_OPTIONS_OPT]);
        } else {
          const filteredExercises = suggestions.filter(
            getExerciseFilter(inputValue)
          );
          setItems(filteredExercises);
        }
      },
      1000
    ),
    []
  );

  const {
    isOpen,
    getLabelProps,
    getMenuProps,
    getInputProps,
    getComboboxProps,
    highlightedIndex,
    getItemProps,
    selectedItem,
  } = useCombobox({
    onInputValueChange,
    items,
    itemToString(item) {
      return item ? item.value : "";
    },
    onSelectedItemChange(changes) {
      const exercise = changes.selectedItem;
      if (exercise) setSearchedExercises([exercise]);
    },
  });

  return (
    <div
      {...getComboboxProps()}
      className="form-control relative w-72 flex flex-col gap-1"
    >
      <label {...getLabelProps()} className="label label-text">
        Search for exercise
      </label>
      <input {...getInputProps()} className="input input-bordered w-full" />
      <ul
        {...getMenuProps()}
        className="absolute top-24 w-72 bg-white shadow-md max-h-80 overflow-y-auto"
      >
        {isOpen
          ? items.map((item, index) => {
              if (item.value === NO_OPTIONS_OPT.value) {
                return <li className="w-full">No results...</li>;
              }

              return (
                <li
                  key={item.value}
                  className="w-full cursor-pointer"
                  {...getItemProps({
                    key: item.value,
                    index,
                    item,
                    style: {
                      backgroundColor:
                        highlightedIndex === index ? "lightgray" : "white",
                      fontWeight: selectedItem === item ? "bold" : "normal",
                    },
                  })}
                >
                  {item.value}
                </li>
              );
            })
          : null}
      </ul>
    </div>
  );
};

export default AutoComplete;

This component has "a lot of state" and Remix will try to render it on the server which will cause errors/warnings of mismatching ids. To avoid that, we have to save the file as AutoComplete.client.tsx. This still won't fix the problem, because now the component will be rendered as undefined, to render it only on the client we have to install a package called remix-utils. This package will provide us with a ClientOnly utility, which will make sure the component gets rendered only on the client. So, we'll use AutoComplete component like this

<ClientOnly fallback={<div>Loading...</div>}>
  {() => <AutoComplete setSearchedExercises={...} />}
</ClientOnly>

Drag and Drop

For Drag and Drop I used the component library beautiful-dnd. I was sold on the fact that it gives me the exact functionality I needed and it's headless.
The library gives us three main elements

DragDropContext (context holding all of the values)
Droppable (the container holding draggable elements)
Draggable (the element user drags)

The general structure when working with beautiful-dnd will look like this

<DragDropContext onDragEnd={...}>
 <Droppable>
   <Draggable />
   <Draggable />
   ...
 </Droppable>
 <Droppable>
   <Draggable />
   <Draggable />
   ...
 </Droppable>
 ...
</DragDropContext>

For state I'm going to keep 2 state variables:

elements of phase columns
elements of search column

const getItems = (phases: TPhases) => {
  const result = [];
  for (let index = 0; index < phases.length; index++) {
    const phase = phases[index];
    const exercises = phase.exercises.map((el) => ({
      name: el.name,
      id: el.id,
      info: { reps: el.exerciseData.reps, sets: el.exerciseData.sets },
    }));
    result.push([...exercises]);
  }
  return result;
};

const [phases, setPhases] = React.useState<DndExercise[][]>(
    getItems(initialPhases)
  );

const [searchedExercises, setSearchedExercises] = React.useState<
    DndExercise[]
  >([]);

Now, we can also update Autocomplete component by passing a props which will set searchedExercises

<AutoComplete
  setSearchedExercises={(e) => {
  const newlyAdded: DndExercise[] = [
    {
       name: e[0].value,
       id: String(e[0].data.id),
       info: { sets: 0, reps: 0 },
    },
  ];
  setSearchedExercises((prevStat) => [...prevStat, ...newlyAdded]);
  }}
/>

Also, each Droppable should have an id which is going to help with moving elements. So, we can rewrite the general code as

<DragDropContext onDragEnd={...}>
 {
  phases.map((phase, idx) => {
    return (
      <Droppable id={idx}>
        {phase.exercises.map(e => {
          return <Draggable>some content</Draggable>
        }
      </Droppable>
    )
  }
 }
 <Droppable id={phases.length}>
    {searchExercises.map(e => {
      return <Draggable>some content</Draggable>
    }
 </Droppable>
</DragDropContext>

Now, for the hardest part, moving elements. The onDragEnd gives you the result object as an argument that holds important things like source ID (from which column we're dragging out) and destination ID (into which column we're dragging to).

const onDragEnd = (result: DropResult) => {
    const { source, destination } = result;

    // dropped outside the list
    if (!destination) {
      return;
    }
    const sInd = +source.droppableId;
    const dInd = +destination.droppableId

    // move and reorder elements
}

For moving and reordering elements I'm using functions you can find in the beautiful-dnd examples. You can look at how they work, they're quite simple. I used them as these black box functions which need some input and return some output.
There are a couple of scenarios that can happen. I made a little diagram, which will hopefully explain it better than a paragraph of text.

In code:

  const onDragEnd = (result: DropResult) => {
    const { source, destination } = result;

    // dropped outside the list
    if (!destination) {
      return;
    }
    const sInd = +source.droppableId;
    const dInd = +destination.droppableId;

    if (sInd === dInd) {
      if (sInd === phases.length) {
        const newItems = reorder(
          searchedExercises,
          source.index,
          destination.index
        );
        setSearchedExercises(newItems);
      } else {
        const newItems = reorder(phases[sInd], source.index, destination.index);
        const newState = [...phases];
        newState[sInd] = newItems;
        setPhases(newState);
      }
    } else {
      if (sInd === phases.length) {
        const result = move(
          searchedExercises,
          phases[dInd],
          source,
          destination
        );
        const newState = [...phases];
        newState[dInd] = result[dInd];
        setPhases(newState);
        const newSearchedExercises = result[sInd];
        setSearchedExercises(newSearchedExercises);
      } else if (dInd === phases.length) {
        const result = move(
          phases[sInd],
          searchedExercises,
          source,
          destination
        );
        const newState = [...phases];
        newState[sInd] = result[sInd];
        setPhases(newState);
        const newSearchedExercises = result[dInd];
        setSearchedExercises(newSearchedExercises);
      } else {
        const result = move(phases[sInd], phases[dInd], source, destination);
        const newState = [...phases];
        newState[sInd] = result[sInd];
        newState[dInd] = result[dInd];
        setPhases(newState);
      }
    }
  };

I'm storing all the phase values in state variables. Meaning phase attributes like name, description, but also phase exercise attributes. I mentioned each displayed exercise will have two inputs, so the user can set sets and reps. I made a function for changing these values in state variables. I hooked it up on blur. Depending on column's id it changes the contents of a particular state variable.

const changeSetsAndReps = (
    value: number,
    what: "sets" | "reps",
    whichCol: number,
    whichRow: number
  ) => {
    if (whichCol === phases.length) {
      const copied = [...searchedExercises];
      copied[whichRow] = {
        ...copied[whichRow],
        info: {
          ...copied[whichRow]["info"],
          [what]: value,
        },
      };
      setSearchedExercises(copied);
    } else {
      const copied = [...phases];
      copied[whichCol][whichRow] = {
        ...copied[whichCol][whichRow],
        info: {
          ...copied[whichCol][whichRow]["info"],
          [what]: value,
        },
      };
      setPhases(copied);
    }
  };

In the end, I just implemented remove functionality, depending on if the displayed exercise is in the search column or phase column I call either:

  const removeSearched = (exerciseIdx: number) => {
    const newSearched = [...searchedExercises];

    newSearched.splice(exerciseIdx, 1);

    setSearchedExercises(newSearched);
  };


  const removeExercise = (phaseIdx: number, exerciseIdx: number) => {
    const newPhases = [...phases];

    newPhases[phaseIdx].splice(exerciseIdx, 1);

    setPhases(newPhases);
  };

If you were to test the functionality of this, you'd find that when inputting some value (sets/reps) and trying to drag the element it will set that value to 0.

It's because of that blur listener. To avoid this, I created a ref

const inFocus = React.useRef<HTMLInputElement>();

which I'm setting on input focus like this

<input onFocus={(e) => (inFocus.current = e.target)} />

, then, I just add prop to DragDropContext

<DragDropContext
  onBeforeDragStart={() => inFocus.current?.blur()}
  ...

Conclusion

In the end, we can look up exercises and drag and drop them into particular phases. But, that's not the end cause we have to submit them to the backend. Will do that in the next part. See you there 😉

Building Training Plan builder: Introduction

Andrej Tlčina — Sun, 31 Jul 2022 10:41:00 +0000

Hello! So, I started a new mini side project. The app is supposed to help you create a training plan and export it in PDF format. In this article, I'm going to talk about setting up the project and building authentication and DB schema.

Setting the project up

I did the setup with the help of this tutorial. Sabin Adams will help you set up the development environment with Remix, Tailwind, MongoDB, and Prisma. I don't want to take credit for that, so if you want to set up a simple project, take a look at that article/tutorial.

Authentication

This part will be pretty short. Mainly because, I did a lot of the same stuff as I did in the previous project and again there's already a great article talking about the auth in Remix with MongoDB, that I followed. You can find it here

User info in the app

When it came to keeping user information on the frontend I immediately went to creating context. But I felt a little lazy and I didn't need user data in a lot of places, so because I have the info saved in the request header I decided to create a simple function

export const authenticateUser = async (req: Request) => {
  const user = await getUser(req);

  if (!user) throw redirect("auth/login");

  return user;
};

, which I call in loader and get the result in the component.

export const loader: LoaderFunction = async ({ request }) => {
  const user = await authenticateUser(request);

  return user;
};
...
// in Route component
const user = useLoaderData<Awaited<ReturnType<typeof authenticateUser>>>();

The result is then passed to Layout component, which displays the name of the user in the navbar

const Navbar = (props: { user: { name: string; id: string } }) => {
  const { user } = props;

  return (
    <div className="navbar bg-base-100">
      <Link to="/" className="btn btn-ghost normal-case text-xl">
        Strongion
      </Link>
      <div className="ml-auto font-semibold text-lg">{user.name}</div>
      <form action="/auth/logout" method="POST">
        <button name="_action" value="delete" className="btn btn-nav-sm ml-2">
          Log out
        </button>
      </form>
    </div>
  );
};

const Layout: React.FC<{ user: { name: string; id: string } }> = (props) => {
  const { user, children } = props;

  return (
    <div className="h-screen bg-base-100">
      <Navbar user={user} />
      <div className="w-2/3 mx-auto">{children}</div>
    </div>
  );
};

DB Schema

I created the schema with four main models: User, Plan, Phase, Exercise. Each user can create multiple Plans, so we get one-to-many relations. Each plan has multiple Phases, and each Phase has multiple exercises attached to it. All relations are of type one-to-many. Here's the whole schema with attributes

model User {
  id            String   @id @default(auto()) @map("_id") @db.ObjectId
  createdAt     DateTime @default(now())
  updatedAt     DateTime @updatedAt
  name          String   @unique
  password      String
  trainingPlans Plan[]
}

model Plan {
  id          String   @id @default(auto()) @map("_id") @db.ObjectId
  title       String   @unique
  description String?
  trainee     User     @relation(references: [id], fields: [traineeId], onDelete: Cascade)
  traineeId   String   @db.ObjectId
  createdAt   DateTime @default(now())
  updatedAt   DateTime @updatedAt
  phases      Phase[]
}

model Phase {
  id          String     @id @default(auto()) @map("_id") @db.ObjectId
  title       String
  description String?
  exercises   Exercise[]
  plan        Plan       @relation(references: [id], fields: [planId], onDelete: Cascade)
  planId      String     @db.ObjectId

  createdAt DateTime @default(now())
  updatedAt DateTime @updatedAt
}

model Exercise {
  id           String       @id @default(auto()) @map("_id") @db.ObjectId
  name         String
  description  String?
  exerciseData ExerciseData
  phase        Phase        @relation(references: [id], fields: [phaseId], onDelete: Cascade)
  phaseId      String       @db.ObjectId

  createdAt DateTime @default(now())
  updatedAt DateTime @updatedAt
}

type ExerciseData {
  reps Int
  sets Int
}

Conclusion

In this section, we went through setting up a simple project, authentication, and creating a DB schema. If you ask me, pretty uninteresting things, but they have to be done 😅, so, to make the project more exciting, in the next section I'm going to explain building the Drag and Drop component with autocomplete search. See you there 😉

Github -> Strongion

Create fullstack book app: CRUD operations w/ tRPC

Andrej Tlčina — Wed, 13 Jul 2022 17:13:01 +0000

Hello! In this part of the series, I'd like to talk a little bit about CRUD operations done via tRPC in my made-up book app. That means our book app should be able to Create, Update, Read and Delete records. Also, we'll fetch (read) data from external API. At first, all the operations may feel a bit overwhelming. That's why I prefer to list all of the operations and start crossing them out of the list, one by one.

Here's my list

create a chapter (C)
display book detail with all the chapters (R)
update a chapter (U)
delete a chapter (D)

I think it makes sense to start with the read portion.

Display book detail with all the chapters

To get a book detail, first, we need to have its ID, in this case, we'll be using the isbn13 code. I've previously mentioned an API I've chosen to work with called https://api.itbook.store/. The API can fetch the newest books by calling https://api.itbook.store/1.0/new. You can look at what's being returned. I'll make a type of just some attributes. On top of that, I could've mapped over the result, but this isn't a production site and so I didn't bother. I got my fetch function from Kent C. Dodds' blog.

export type Book = {
  title: string;
  subtitle: string | null;
  isbn13: string;
  price: string;
  image: string;
};

export type BookList = {
  error: number;
  total: number;
  page?: number;
  books: Book[];
};

export function fetchBooks(type = "", customConfig = {}): Promise<BookList> {
  const config = {
    method: "GET",
    ...customConfig,
  };

  const url = `${process.env.BOOKS_URL}${type}`;

  return fetch(url, config).then(async (response) => {
    if (response.ok) {
      return await response.json();
    } else {
      const errorMessage = await response.text();
      return Promise.reject(new Error(errorMessage));
    }
  });
}

What I've done at first was to create a new router and chained a query function that calls fetchBooks function above, like this

export const booksRouter = createRouter()
  .query("newest", {
    async resolve() {
      const bookList = await fetchBooks("new");

      return bookList.books;
    },
  })

Not sure how I feel about it yet, but I don't think this is the best, so either call it with react query

const result = useQuery('newest', async () => await fetchBooks('new')

or in getServerSideProps of page component and pass it as props

type Props = {
  books: Books;
};

export const getServerSideProps: GetServerSideProps<Props> = async (
  ctx
) => {
  const book = await fetchBook('new');

  return {
    props: {
      books,
    },
  };
};

const NewestBooks = ({
  books,
}: InferGetServerSidePropsType<typeof getServerSideProps>) => {
  ...
}

Now that we have a list of the newest books we can loop over them. Let's display some cards or something, important thing is we have to have a link to an individual book detail page. In general, you'll have something like this

books.maps((book) => {
  return (
    <div className="card">
       ...
       <Link href={`/books/${book.isbn13}`}>
         <a>...</a>
       </Link>
    </div>
  )
})

Style it however you want. Don't forget to create new page at pages/books/[isbn13]/index.tsx. This might look weird, but later on, when working with chapters, I want to have URLs like

/books/[isbn13]/chapter/add <- for adding new chapter
and
/books/[isbn13]/chapter/[id] <- for updating existing chapter

It probably doesn't make much of a difference, so don't sweat it if you'll have different file structure/routes, as long as it makes sense to you 😄. We're already at creating pages, so let's create pages for adding and updating chapters, like I mentioned previously.

At this point, we have the "newest books" page, "book detail" page, "add chapter" page and "edit chapter" page. In "book detail" page, we'll fetch the book by ISBN code by calling

import { useRouter } from 'next/router'

const BookDetail = () => {
  const router = useRouter()
  const { isbn13 } = router.query
}

or in getServerSideProps

export const getServerSideProps: GetServerSideProps<LocalProps> = async (
  ctx
) => {
  const code = ctx?.params?.isbn13;
  ...
};

We can fetch a book by isbn13 code by calling

export function fetchBook(isbn13 = "", customConfig = {}): Promise<Book> {
  const config = {
    method: "GET",
    ...customConfig,
  };

  const url = `${process.env.BOOKS_URL}books/${isbn13}`;

  return fetch(url, config).then(async (response) => {
    if (response.ok) {
      return await response.json();
    } else {
      const errorMessage = await response.text();
      return Promise.reject(new Error(errorMessage));
    }
  });
}

Similarly, like we did fetch the newest books.

export const getServerSideProps: GetServerSideProps<LocalProps> = async (
  ctx
) => {
  const book = ctx.params
    ? await fetchBook(ctx?.params?.isbn13 as string)
    : null;

  return {
    props: {
      book,
    },
  };
};

sidenote: if you used useRouter, then fetch with react-query

Thanks to this request, the book detail may contain additional book info, but I definitely want list of chapters, that I can edit and delete, and I want to be able to create a new chapter.

Create a chapter

sidenote: when talking about the next chapter we're gonna be creating, lets use term, "callable" pieces of code. When talking about a query, picture using it at the top of some component, on the other hand, when talking about a mutation, picture some kind of a button user will be clicking

Creating a chapter makes sense to do the next, because I want to have some chapters in DB first, which I'll edit or delete later. The scenario is: user comes to the book detail page, where they can either add the book to their "library", or if they've already done so, can add a new chapter.
Let's define, that both of these actions are done by clicking some kind of a button. At this stage, I'm not thinking about which one I'm gonna show or not. I'll be doing testing and I know in which order I have to be clicking buttons.
Creating mutations for both buttons is a safe bet. I'll show you adding the book first

  .mutation("add-book", {
    input: z.object({
      title: z.string(),
      subtitle: z.string().nullish(),
      isbn13: z.string(),
      price: z.string(),
      image: z.string(),
    }),
    async resolve({ ctx, input }) {
      const bookNote = await ctx.prisma.bookNote.create({
        data: {
          ...input,
          authorId: ctx.user?.id || "",
        },
      });

      return bookNote;
    },
  })

Do you remember context from the previous post? Having a user at each function is super handy, like here. So, we'll create a new book note. Once that's done, we can add a chapter by calling

  .mutation("add-chapter", {
    input: z.object({
      bookID: z.string(),
      payload: z.object({
        title: z.string(),
        text: z.string(),
      }),
    }),
    async resolve({ ctx, input }) {
      const chapter = await ctx.prisma.chapter.create({
        data: {
          ...input.payload,
          bookNoteId: input.bookID,
        },
      });

      return chapter;
    },
  })

In both cases, we can generalize, that when creating a new record, we call create method of the particular model. There, we're passing a data object, that will expect certain values defined in the schema.

You hook to this mutation like this

import { trpc } from "utils/trpc"

const exampleMutation = trpc.useMutation(["router.example"]);

...

<button disabled={exampleMutation.isLoading} onClick={exampleMutation.mutate} >Click to mutate</button>

Usually, after mutating, one wants to let's say refetch some kind of a query or redirect the user. Just as with react-query, you can use onSuccess attribute


const exampleMutation = trpc.useMutation(["router.example"], {
  onSuccess: (data) => {...}
});

At this point, we have two buttons, but in production, I'd like to switch between them. I'll have to be checking if I already have the book in my "library", and that way I'll decide which button to show

  .query("get-book", {
    input: z.object({
      isbn13: z.string(),
    }),
    async resolve({ ctx, input }) {
      const bookNote = await ctx.prisma.bookNote.findFirst({
        where: {
          authorId: String(ctx.user?.id),
          isbn13: input.isbn13,
        },
      });

      return bookNote;
    },
  })

Here, we're asking Prisma to give us a record with the given isbn13 and author. We call this query like this

import { trpc } from 'utils/trpc'

const exampleQuery = trpc.useQuery(["router.example", $input$]);

You could have a different flow of adding chapters. Like

  .mutation("add-chapter", {
    input: z.object({
      book: z.object({
        title: z.string(),
        subtitle: z.string().nullish(),
        isbn13: z.string(),
        price: z.string(),
        image: z.string(),
      }),
      payload: z.object({
        title: z.string(),
        text: z.string(),
      }),
    }),
    async resolve({ ctx, input }) {
      const bookNote = await ctx.prisma.bookNote.upsert({
        where: {
          id: input.book.id 
        },
        update: {},
        data: {
          ...input.book,
          authorId: ctx.user?.id || "",
        },
      });

      const chapter = await ctx.prisma.chapter.create({
        data: {
          ...input.payload,
          bookNoteId: input.book.id,
        },
      });

      return chapter;
    },
  })

This option uses upsert, which can be used as find or create. We're saying to find a book or create it otherwise, which ensures that, when we're adding a chapter, there will be a record with id of input.book.id. Your choice, I'll go with the first one 😀.

Update a chapter

Definition of function for updating a chapter is pretty straightforward, when adding a chapter, we were creating a record, which is C out of CRUD. When updating, you guessed it, we'll use the update

  .mutation("update-chapter", {
    input: z.object({
      chapterID: z.string(),
      payload: z.object({
        title: z.string(),
        text: z.string(),
      }),
    }),
    async resolve({ ctx, input }) {
      const chapter = await ctx.prisma.chapter.update({
        data: {
          ...input.payload,
        },
        where: {
          id: input.chapterID,
        },
      });

      return chapter;
    },
  })

Delete a chapter

And at the end, we're deleting (literally calling delete).

  .mutation("remove-chapter", {
    input: z.object({
      chapterID: z.string(),
    }),
    async resolve({ ctx, input }) {
      await ctx.prisma.chapter.delete({
        where: {
          id: input.chapterID,
        },
      });

      return true;
    },
  })

All of the mutations and query can be called the way you want, or the way it suits you best.

Conclusion

I know, that was intense! But, you've made it! And know you know how to define CRUD functions with tRPC. I hope you can see just how simple it can be.

Thanks for reading, and keep an eye out for the next part. Till then take care 😉

Create a fullstack book app: Authentication and DB models

Andrej Tlčina — Mon, 11 Jul 2022 12:51:59 +0000

Hello! In this part of the series, we'll dive into authentication and how I designed the database schema. Initially, I wanted to do just authentication, but when adding a user model with Prisma I realized it would be wise to create all models, so I get a bird's eye view of the whole DB.

Building schema

I'll be using Prisma for working with DB. But Andi, what is Prisma? Glad you asked. It is a database ORM, which is a layer of abstraction, that helps you with DB actions, like searching in DB or creating new records. On top of that, it has full type safety.

create-t3-app does a lot of initializing for you. You'll have a folder called prisma at the root of your project, which will have schema.prisma file containing this

generator client {
    provider = "prisma-client-js"
}

datasource db {
    provider = "sqlite"
    url      = "file:./db.sqlite"
    // url      = env("DATABASE_URL")
}

This essentially sets your DB of type sqlite. Now, every time there's change in the schema, to see changes reflected in DB we have to run either

npx prisma db push

npx prisma migrate dev

I was using mainly the first one, because I was quickly prototyping. When running push, the DB will be wiped. To keep changes you'll want to run the latter.

So, as I wrote in the last post the DB will consist of users, which will have book-notes assigned to them, and book-notes will have chapters assigned to them. Here are the initial models

model User {
    id String @id @default(uuid())
}

model BookNote {
    id String @id @default(uuid())
    isbn13 String
}

model Chapter {
    id String @id @default(uuid())
}

Each model has to have an identifier. You can set default value with @default(uuid()). ~~I didn't do it for the BookNote model, cause a booknote identifier will be isbn13 code of the book.~~ That will be received via the external endpoint https://api.itbook.store/.
EDIT: yes, the isbn13 code will be received from external endpoint, but we have to set id to BookNote model, as well. Otherwise, we'll have one bookNote for one book.

Next up, I added more attributes that either made sense or I could retrieve from the endpoint mentioned above.

model User {
    id String @id @default(uuid())

    name String @unique
    password String
}

model BookNote {
    isbn13 String @id 

    title String
    subtitle String?
    image String
    price String

    createdAt DateTime @default(now())
    updatedAt DateTime @updatedAt
}

model Chapter {
    id String @id @default(uuid())

    title String
    text String

    createdAt DateTime @default(now())
    updatedAt DateTime @updatedAt
}

Here are some special attributes like @unique which make the column unique (so there are no two names identical). Then, there is @default(now()), which adds time to createdAt column, and @updatedAt which updates time, whenever we make a change.

Now, as I wrote earlier, each user will have multiple book-notes. Each book-note will have multiple chapters. This leads us to using one-to-many relation. If a book-note would be shareable, i.e. a book-note can have multiple users, I would use many-to-many relation.

Looking at the docs of one-to-many relation (sidenote: don't be scared to look at docs, memorizing is a waste of everybody's time), we get final schema

model User {
    id String @id @default(uuid())
    name String @unique
    password String
    bookNotes BookNote[]
}

model BookNote {
    isbn13 String @id 
    title String
    subtitle String?
    image String
    price String
    author User @relation(fields: [authorId], references: [id])
    authorId String
    chapters Chapter[]
    createdAt DateTime @default(now())
    updatedAt DateTime @updatedAt
}

model Chapter {
    id String @id @default(uuid())

    title String
    text String
    bookNote BookNote @relation(fields: [bookNoteId], references: [isbn13])
    bookNoteId String
    createdAt DateTime @default(now())
    updatedAt DateTime @updatedAt
}

JWT Authentication with trpc

First things first... what is JWT? It's a shortcut for jsonwebtoken. It helps you take some data, like name, email, and essentially hash it and save it to help with identifying user, by unhashing it and checking the data. This token can be saved on the client, which, from what I read, can be dangerous, or can be saved on the server (we'll do that).

Let's install some packages

npm i cookie jose bcrypt --save
npm i @types/cookie @types/jose @types/bcrypt --save-dev

I like to make checklist of everything that has to be done:

on the sign-in, set the user's JWT token in the request's cookie
verify the given JWT token
get hashed values out of the JWT token
on the sign-out, expire user's JWT token in requests cookie

I like to first have an interface, so I can easily test stuff. Next.js has file-based routing, which means, when you create a file like example.tsx in the pages directory, you already have a route /example. Let's create sign-up.tsx and login.tsx files. Both will follow structure

function FormPage() {
  create a function that will send auth data to server and redirect to particular page

  return (
    // render a form that calls function mentioned above
  );
}

export default FormPage;

I don't want to go to specifics, the main idea is written above. We can refactor to infinity, but that's not important... right now, I just want an interface.

Register

The whole Backend will be written thanks to tRPC. It is a technology, that lets you define functions on the Backend and call them on the Frontend. For creating such a function one needs a router. Let's create one in server/router directory, it will be called auth.router.ts. Here, we'll create a new router by calling createRouter() and chaining mutation() to it. The tRPC has 2 main types of functions mutation and query. I use mutation, whenever I have to fetch the data on some event, like on click. And I use query, whenever I just have to fetch stuff in the component. We'll use mutation for sign-up, because we're sending data on click.

export const authRouter = createRouter()
  .mutation("signup", {
    input: z.object({
      name: z.string(),
      password: z.string(),
    }),
    async resolve({ input, ctx }) {
      const { prisma } = ctx;

      const { name, password } = input;


      const user = await prisma.user.create({
        data: {
          name: name,
          password: bcrypt.hashSync(password, 10),
        },
      });

      return { name: user.name };
    },
  })

The function expects you to send some input, in above-defined format, then creates a new user with Prisma. On Frontend we'll create mutation via

const mutation = trpc.useMutation(["auth.sign-up"]);

tRPC is a layer above React-Query, so it works like useMutation there.

Login

Let's chain another function login.

.mutation("login", {
    input: z.object({ name: z.string(), password: z.string() }),
    async resolve({ ctx, input }) {
      const { prisma } = ctx;

      const { name, password } = input;

      const user = await prisma.user.findUnique({
        where: {
          name: name,
        },
      });

      if (bcrypt.compareSync(password, user.password)) {
        const token = await setUserCookie(user.name, ctx.res);
        return { name: user.name, token };
      } 
    },
  })

Login takes some input and searches the DB to find the unique name (that's why @unique is in the schema). Finding users is not enough though, we have to compare passwords. If they're the same we take the name and hash it with JWT and set in on the server. Create a new file auth.ts.

// src/lib/auth.s

const SECRET = process.env.JWT_SECRET;

export async function setUserCookie(name: string, res: NextApiResponse) {
  try {
    const token = await new SignJWT({})
      .setProtectedHeader({ alg: "HS256" })
      .setJti(name)
      .setIssuedAt()
      .setExpirationTime("2h")
      .sign(new TextEncoder().encode(SECRET));

    res.setHeader(
      "Set-cookie",
      cookie.serialize("token", token, {
        httpOnly: true,
        path: "/",
        maxAge: 60 * 60 * 2, // 2 hours in seconds,
      })
    );

    return token;
  } catch (e) {
    console.error({ setCookies: e });
  }
}

The signing part is a little scary with all the chaining, but I literally just copied it from their docs. In function, we're setting the header with setHeader (method of Next API Response). Thanks to package cookie we can serialize the hashed token to header cookies, here we're setting httpOnly: true, which makes it so we have cookies on the server and not the client, path these cookies exists on, and maximum age of the cookie.

You can see there's also a SECRET variable. It is a key that hashes the data. We'll be using this value at verifying the given token, speaking of... let's do that

// src/lib/auth.s

interface UserJwtPayload {
  jti: string;
  iat: number;
}

export async function verifyJWT(token: string) {
  const authSession = await jwtVerify(token, new TextEncoder().encode(SECRET));
  return authSession.payload as UserJwtPayload;
}

We'll get some payload from the hashed token. The payload will be of type UserJwtPayload, and the data, we hashed, will be in jti attribute.

Logout

At last, we want to expire token, when user logs out. For that, let's chain new method in auth.router.ts.

 .mutation("logout", {
    async resolve({ ctx }) {
      await expireUserCookie(ctx.res);

      return true;
    },
  })

// src/lib/auth.s

export function expireUserCookie(res: NextApiResponse) {
  res.setHeader(
    "set-cookie",
    cookie.serialize("token", "invalid", {
      httpOnly: true,
      path: "/",
      maxAge: 0,
    })
  );
}

tRPC Context

You may wonder, what is the ctx variable in resolve? The tRPC comes with the handy thing called context, which runs on every request (that's the ctx in router resolve). We can pass the user there, so, we have it at our disposal. You can do that for any other data you feel have to be globally available for each request. If we remove user data from the server cookie, the context will pass null as user data.

const getUserFromCookies = async (req: NextApiRequest) => {
  // get JWT `token` on cookies
  const token = req.cookies["token"] || "";

  try {
    // if token is invalid, `verify` will throw an error
    const payload = await verifyJWT(token).catch((err) => {
      console.error(err.message);
    });

    if (!payload) return null;

    // find user in database
    const user = await prisma.user.findUnique({
      where: {
        name: payload.jti,
      },
    });

    return user;
  } catch (e) {
    return null;
  }
};

export const createContext = async ({
  req,
  res,
}: trpcNext.CreateNextContextOptions) => {
  const user = await getUserFromCookies(req);

  return {
    req,
    res,
    prisma,
    user,
  };
};

Logout can be tested with a simple button. However, it would be nice to know if the user is logged in on the client-side. Having something like context from tRPC on the client, you know... Oh wait, we have just the thing, React Context.

Authentication Context

Context can be a tricky thing with (what sometimes feels like) random re-renders and such. Thanks to this article on developerway, created by Nadia Makarevich, I view context differently and use it with more confidence. I really recommend reading it, but long story short, people put a lot of data into the context's state. What you want to do, is split the state to API part, where you call dispatch type of functions and part with some values, like user name, email, and such. Then you create the context for each of these values, so when one changes, this change does not trigger unnecessary rerenders. It will look like this

const AuthAPIContext = createContext({
  logoutUser: () => {},
  loginUser: () => {},
});

const AuthUserContext = createContext({
  user: initialState.user,
});

const reducer = (state: TState, action: TAction): TState => {
  switch (action.type) {
    case "AUTH/LOGIN":
      return {
        ...state,
        user: action.payload?.name,
      };
    case "AUTH/LOGOUT":
      return {
        ...state,
        user: null,
      };
    default:
      return state;
  }
};

export const AuthProvider = ({ children }) => {
  const [state, dispatch] = React.useReducer(reducer, initialState);

  const api = React.useMemo(
    () => ({
      loginUser: (s: string) => dispatch(loginUser(s)),
      logoutUser: () => dispatch(logoutUser()),
    }),
    []
  );

  return (
    <AuthUserContext.Provider value={{ user: state.user }}>
      <AuthAPIContext.Provider value={api}>{children}</AuthAPIContext.Provider>
    </AuthUserContext.Provider>
  );
};

export const useAuthAPI = () => useContext(AuthAPIContext);
export const useAuthUser = () => useContext(AuthUserContext);

Protecting routes

Cool! We have the login system, we have an auth context, but we're still missing some protection for routes. For example, we don't want an unauthenticated user to be looking at some parts of the website. We can do this multiple ways, however, I found two that I personally like the best, HOC and middleware.

Higher Order Component solution

With this solution, we'll create HOC wrapping getServerSideProps. When there's a user logged in, we can redirect the user by returning

redirect: {
  permanent: false,
  destination: "/login",
}

Here's the definition

export const withAuth =
  (getServerSidePropsFn) =>
  async (ctx) => {
    const token = ctx.req.cookies?.token;

    if (!token) {
      return {
        redirect: {
          permanent: false,
          destination: "/login",
        },
      };
    }

    // if token is invalid, `verify` will throw an error
    const payload = await verifyJWT(token).catch((err) => {
      console.error(err.message);
    });

    if (!payload) {
      return {
        redirect: {
          permanent: false,
          destination: "/login",
        },
      };
    }

    return getServerSidePropsFn(ctx);
  };

And here's how I used it

export const getServerSideProps = withAuth(async (
  ctx
) => {
  return {
    props: {
      ...
    },
  };
});

I like this solution, because redirect happens on the server, instead of the client, therefore no flashes, but we have to do this for each and every protected page. Luckily with the newest version of Next.js we might have a solution in form of middleware.

Middleware solution

In Next 12.2 they released middleware. From Next.js docs:

Middleware allows you to run code before a request is completed, then based on the incoming request, you can modify the response by rewriting, redirecting, adding headers, or setting cookies.

Which is the exact thing we want, we run this middleware, before a request is completed where, we'll check request cookies and if there's something wrong, we redirect the user. It can even run on just particular pages with

export const config = {
  matcher: here you write a path or array of paths you want to match,
};

Here's how I used it

export const config = {
  matcher: ["/my-notes", "/books/:path*"],
};

export async function middleware(req: NextRequest) {
  const verifiedToken = await verifyAuth(req).catch((err) => {
    console.error(err.message);
  });

  // redirect if the token is invalid
  if (!verifiedToken) {
    return NextResponse.redirect(new URL("/login", req.url));
  }

  return NextResponse.next();
}

Conclusion

Well, that was a lot. But to conclude, we created the whole schema for our DB. Then, we created a whole login system with tRPC router, JWT tokens, client and server context and we finished up with protecting our routes.

You can look at the project here https://github.com/Attanox/it-notes

Thanks a lot for reading! The next part will be about CRUD operations. See you there! 😉

Create a fullstack book app: Introduction

Andrej Tlčina — Mon, 11 Jul 2022 12:48:49 +0000

Hello! In this series of posts, I'd like to document my journey of creating a fullstack app as a frontend dev. Don't get me wrong, I love frontend, but there is something cool about fullstack. Therefore, I decided to create this series to share how I go about creating and learning new stuff, and maybe hopefully you, as a reader, will get something from it. If not or you feel like there is something I explained wrong or could be done better, feel free to hop in the comments 😄

Main goal

Have you ever read a book, but then forgotten about the concepts it had, or you've been told to make notes, so it will be easier to comprehend the material? Well, I've been there (no this is not a commercial), but I never stuck with the classic paper notebook. So, I had this idea that instead of creating another To-Do app, I'd make an app that will fetch books from an external API and each book can be given notes. The app would also have authentication, so each user has their own set of notes to a particular book. This way, I'll work with multiple different fullstack concepts.

The stack

The stack I'll use is the one Theo from Theo - ping.gg YouTube channel recommends. Mainly, because I like the promise of end-to-end type-safety and also Jack Herrington said it is easy to grasp for beginners. So, in my projects directory I ran:

npx create-t3-app@latest

This command helped me bootstrap the project. The command also lets you pick technologies. I chose everything (tailwind, prisma, trpc), but the next-auth. I thought by creating my own login system I'd learn a lot, and boy was I right, more on that in the next part of this series, Authentication.