DEV Community: Miyuki Tuisku

Setting Up a Front-end Using Vite + React + Firebase Hosting

Miyuki Tuisku — Mon, 18 Sep 2023 05:57:39 +0000

Setting up an environment.

Something that can manage to make you feel excited yet demoralizing at the same time. It resembles the feeling when you get a new apartment knowing you have 50+ boxes to unpack.

But luckily, thanks to the new services and technology, it is easier than ever for us to set up and get our apps up and running on the web.
I've learned the easier way his over time, often by not finishing one project before jumping into another.

⚠️ Please do not expect this to be suitable for massive projects. It is intended for use with small to mid-sized projects or for prototyping.

Prerequisites

You need to install node globally on your computer. Currently v18+ is a safer choice (My environment uses v18.16.0).

1 Set Up a Code Base

1.1. Scaffolding a Vite Project

Starting by running the Vite command:

npm create vite@latest

Then follow the prompts:

Name your project with whatever name you prefer.
Select a framework: React
Select a variant: › TypeScript + SWC
Navigate to the project directory and run npm install and npm run dev.

1.2. (Optional) Enable Absolute Import Path

This is an optional choice, but I personally dislike importing with relative paths, and it is always easier to configure it at the beginning..

Add this line into your tsconfig.json:

{
  "compilerOptions": {
    ...
    "baseUrl": "./src"
  },
  ...
}

And then let the Vite project know about your alias with adding these lines to vite.config.ts

export default defineConfig({
  ...
  resolve: {
    alias: {
      src: '/src',
    },
  },
})

Now you are able to import components like this:

import { Button } from 'src/components/Button';

1.3. Set up a Formatter

Run: npm install --save-dev prettier eslint-config-prettier
Create a config file: touch .prettierrc.yml

printWidth: 80
tabWidth: 2
singleQuote: true
semi: false

1.4 Set up Tailwind CSS

Install: npm install --save-dev tailwindcss postcss autoprefixer
Configure the template path at tailwind.config.js:

/** @type {import('tailwindcss').Config} */
export default {
  content: [
    "./index.html",
    "./src/**/*.{js,ts,jsx,tsx}",
  ],
  theme: {
    extend: {},
  },
  plugins: [],
}

Add the Tailwind directives to the master CSS index.css

@tailwind base;
@tailwind components;
@tailwind utilities;

You only need the above to use Tailwind, but I love working with Tailwind UI, which requires some extra libraries:

npm install --save @headlessui/react @heroicons/react
npm install --save-dev @tailwindcss/forms

Okay, now you're done with setting up the working frontend.
Let's deploy it and publish them on the web!

2. Set Up Firebase Hosting

2.1 Create Your Project in Firebase

You first need to go to Firebase Console and create a project.
Here's an official documentation for that.
https://firebase.google.com/docs/web/setup

2.2 Initialize Your Application

First you need to install firebase-tools globally:
npm install -g firebase-tools

Then run this:
firebase login
This will launch a pop up to ask you to sign in.

Then you hit this command in the directory you created with the earlier step: firebase init

Then follow the prompts:

Select Hosting and (optionally) set up GitHub Action deploys as a feature
Select the project you just made
Set dist as your public directory (WARNING: public is the default for firebase hosting, but it's easier to use dist if you're using Vite as that's the default output directory for Vite.)
Answer yes when you're asked if you want to configure as a single-page app

2.3 Deploy

You need to use firebase sdk to deploy with a script:
npm install --save firebase

Then copy and paste config information. Your config info can be obtained on the console.

export const HOSTING_CONFIG = {
  apiKey: XXX,
  authDomain: XXX,
  projectId: XXX,
  storageBucket: XXX,
  messagingSenderId: XXX,
  appId: XXX,
}

Then initialize the firebase app using that config.
This can be done with any file, but I would recommend putting somewhere close to root like App.tsx or index.ts because that has to be processed first before you use any firebase feature.

    import { initializeApp } from 'firebase/app'
    import { HOSTING_CONFIG } from 'env/config'

    initializeApp(HOSTING_CONFIG);

Finally, add a script in your package.json

"scripts" : {
    ...
    "deploy": "tsc && vite build && firebase deploy --only hosting"
}

And that's it! 🎉

Once you hit npm run deploy in your terminal, you'll be able to see the default screen for Vite project.

Now all you have to do is finish your project...

Thanks for reading! Happy coding!🙌

Human-Friendly Programming

Miyuki Tuisku — Sun, 13 Nov 2022 06:25:53 +0000

Some believe that we programmers decided to do what we’re doing, because we don’t have to interact with other humans.

But is it so?

I believe not.

Background

As a developer of a SaaS product, I have been thinking about why reviewing some of the Pull Requests (PRs) has been more difficult or demoralizing than others and this is the conclusion I've come to.

I would like to call the concept Human-friendly programming.

It is nothing new, super flashy nor shiny. But hopefully more powerful than you think.

What is Human-friendly Programming?

The basic idea is really simple.

Your programs are FOR HUMANS.

A darker and cynical version of that would be:

Your colleagues ain't your therapists.
They ain't bothered figuring out what you think.

Your codes will be read, reviewed, and maintained by people (including you). Duh.🙄

“The Art of Readable Code”, one of the go-to programming books of all time suggests:

The code should be easy to understand.

Here’s another quote from Martin Fowler.

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

Yeah, yeah. We already know that, right?

But yet, I’ve seen many fairly experienced programmers work like they aren’t bothered by that.😢

So what exactly are we supposed to do?
I’ve come up with some suggestions, and I’ll explain them in the next chapter.

What are the Practices of Human-friendly Programming?

All of the code examples are written in Javascript and React. But I believe the essential concept would be universal.

The following is a list of some of the fundamental key rules I would like to present to make your PRs human-friendly. I’ll explain each with an example.

1. Name It Like You Mean It

🥶 Non-Human-Friendly Way

const onClick = () => {
  const data = getData();
  clickCallback(data);
}
<Button onClick={onClick}>Hooray!</Button>

Let’s say your colleague asked you to review their PR, and you find these lines of code.
Do you get what happens when you click the button?

😶‍🌫️ What I See

const whatever = () => {
  const thing = getSomething();
  youFigureItOut(thing);
}
<Button onClick={whatever}>Hooray!</Button>

When I see codes like that, what I see in my head is this. (I know I’m being cynical here. But I’m just trying to make my point.)

😍 The Human-friendly Way

const createTodo = () => {
  const blankTodoData = generateBlankTodoData();
  setTodoInServer(blankTodoData);
}
<Button onClick={createTodo}>Hooray!</Button>

This looks MUCH BETTER to me. I can clearly see what happens when you click the button, and the setTodoInServer is trying to set blank data in the server. You can tell if the code is not behaving that way.

2. Use Comments to Explain What the Code Can’t

Ultimately, self-explanatory and understandable code without any comments are the best, so people should work on them first.

But sometimes you have to make some completely random implementations in completely random places.
And the chances are, your future self let alone your colleagues will have no clue why you had made such exceptions.

Except for, if there’re comments about it.

🥶 Non-Human-Friendly Way

const addTodo = async(todo: Todo) => {
  setInLocalState(todo);
  const todoData = await saveInServer(todo);
  setInLocalState(todoData); //NOTE: set saved todo data in local 
}

😶‍🌫️ What I See

const addTodo = async(todo: Todo) => {
  setInLocalState(todo);
  const todoData = await saveInServer(todo);
  setInLocalState(todoData); //It's a complete mystery why it is setting the local state again
}

The Problems

It does not give any information
The comment exists for no reason. I’d know what the code is doing by the name of the function by looking at the code. We want to know why you did it. It makes the code confusing and difficult to understand.
Makes the code more vulnerable to be broken in the future
If people don’t understand why the code is doing what it’s doing, there is a chance that they will modify the code and break it. Trust me, it happens. I’ve actually done it myself and learned a lesson (that time actually there were no comments, so it’s even worse).
Codebase gets messy
Not only it is useless, but it is violating the cleanliness of the code. Codes should be simple and clean.

😍 The Human-friendly Way

const addTodo = async(todo: Todo) => {
  setInLocalState(todo);
  const todoData = await saveInServer(todo);
  setInLocalState(todoData); //NOTE: setting id generated in server, which is required for updating
}

I don’t know if there is a case like this realistically, but at least you know why setInLocalState is called twice.

3. Write Git Commit Message for Documenting

Bad commit messages.
This is one of the things I run into the most. And I have to admit, I find it very difficult to get it right myself.

🥶 Non-Human-Friendly Way

quick fix
add button
fixed because of review comment

😶‍🌫️ What I See

something was wrong
what the button is for, is for you to figure out
someone pointed out there is something wrong with my code

The Problems

It does not give any information
Like the useless comments, the message does not explain why you’ve made the change.
Makes the code more vulnerable to be broken in the future
Again, like the bad comments.

😍 The Human-friendly Way

🐛 hide deleted todos from todo list
✨ enable creating todos from todo list page
♻️ use common utility function to create blank todo

One tip I read in this article(Japanese) is that commit messages should explain what the program does instead of what the programmer did. So instead of (the programmer) added button , write **(the program) **enabled creating todos from todo list page .

Having your own rule for prefixes to categorize the commit type is handy. Emoji prefix helps you understand what the commit is about at a glance. For example, if you see ♻️ then you know that the behavior should not have been changed. Our team is highly inspired by gitmoji, but you can have your own rules. Conventional commits is also a powerful way to make your commits sorted automatically and make it readable for humans.

4. Make Pull Requests With Care

This one is also one of the most common and most difficult ones.

🥶 Non-Human-Friendly Way

Hundreds of lines of code in a single pull request
The pull request is doing too much shit (e.g. creating, listing, and deleting todos)
This is what the pull request cover looks like:

Ugh. There is nothing more demoralizing than getting this kind of review request.

😶‍🌫️ What I See

You don’t care about how difficult and time-consuming it is for others to go through the entire codes
You are not even bothered to explain how this PR’s supposed to affect the program
No specification about how it’s supposed to work whatsoever

The Problems

More risks for overlooking mistakes
The more codes you have to check, the more likely the reviewer will miss mistakes in the code. Moreover, it doesn’t help if you don’t give them any information on how it’s supposed to work.
Takes more time
Some think combining pull requests and having them reviewed once will save time. I really doubt that. Because firstly, it takes time to go through, so the feedback cycle takes a longer time. Secondly, you’ll have more chances to get more comments, so it takes longer to modify the code. Commenting on multiple topics (in this case about creating, listing and deleting) at the same time makes the communication super cumbersome. You should always stick with smaller feedback cycles.

😍 The Human-friendly Way
Luckily, we can make a template with GitHub and many other git management services.
Here are some part of the template we use in the team.

# Why
- Some users want to see only todos that aren't completed and some wants to see all of the todos including completed ones

# Summary
- Create a toggle button to switch between "show allevery todos including completed" and "hide completed todos"
- Set default as "hide completed todos"
- Exclude completed todos when "hide completed todos" was chosen

# Test 
(Ideally this should be automated...)
- Completed todos DO NOT appear on the list when "hide completed todos" is chosen
- Completed todos DO appear on the list when "show alevery todos including completed" is chosen

# Related Links
- Link to the UI design file
- Link to the conversation about the specification

# Screeenshot
(Screenshot to show a grasp of what has changed)

Conclusion

These practices are just a few examples. I believe there are loads of ways to make your code more human-friendly.

But the main point is again:

Your programs are FOR HUMANS.

Whatever you do, if you answer these questions with a “Yes”, then that is the human-friendly way.

Would you understand your code a year later?
Did you explain what the code does in your commit messages?
Would you understand what the PR is about without context?
Can the reviewer finish reviewing within 10-20 mins?