DEV Community: Randy

I made a VS Code code snippet manager

Randy — Thu, 22 Sep 2022 03:35:40 +0000

Hi all. I often use VS Code code snippet to speed up my coding. It's a very useful feature in VS Code that I can create some snippet and use some special syntax to transform the snippet (like capitalize and generate uuid).

For example, I can use this snippet to quickly generate a setState code:

const [$1, set${1/(.*)/${1:/capitalize}/}] = useState($2)

But it's very hard to maintain the snippet because snippet file in VS Code is a JSON file. Every line of snippet was separate into an Array like:

{
  "For Loop": {
    "prefix": ["for", "for-const"],
    "body": ["for (const ${2:element} of ${1:array}) {", "\t$0", "}"],
    "description": "A for loop."
  }
}

To make it easier to maintain the snippets in VS Code, I made a code snippet manager tool to write snippet in nature way, then one click sync to VS Code.

You can download it now on: https://codespeedy.randyloop.com

It supports Windows and macOS. And the app size is only 7MB (No electron).

It's not open source yet because I'm not sure how many users it will have.

Print your GitHub contributions as an artwork

Randy — Sat, 19 Mar 2022 17:19:14 +0000

I made a tool to generate a GitHub contribution artwork https://getoss.art/

How I built a SaaS with Next.js in a week

Randy — Fri, 04 Jun 2021 01:37:01 +0000

Update: I wrote a little book about building fullstack application with Next.js https://fullstack-nextjs-in-action.taonan.lu/

I built Cusdis in April 2021, an open-source, light-weight, privacy-friendly alternative to Disqus. I built it in just a week and got a large amount discussions on HackerNews. It also was shown on HackerNews front page.

In this post, I want to share how did I build Cusdis and what I've learnt in this project. Especially some experiences of efficiently building application with Next.js.

How did I come up with this idea

I used Disqus in my personal blog. It works well but sometimes spends too much time to load the whole comment thread. One day I saw this article which discuss about the privacy issue and slow loading speed issue of Disqus. It makes me think of building a Disqus alternative that solves theses issues. And named it as the reverse of Disqus -- Cusdis.

System design

I think a most minimalist comment system contains at least three parts:

A database, to store threads info, comments.
A frontend widget that can be embedded to website.
A dashboard to manage (approve, reply, delete) comments.
A server that provides API to the widget and as the backend of the dashboard.

Database

In my opinion (I'm not a database expert), SQLite is good enough to implement a comment system. But because I want to have a hosted service, SQLite is not fit for serverless environment and concurrent usecase, while PostgreSQL is suitable in this case but it's over complicate for self-host users. In the end I decided:

For the self host user, SQLite is by default. They don't have to set up a PostgreSQL instance to use Cusdis
Giving an option to use PostgreSQL (for the self host user and our hosted service)

See how to deploy Cusdis in Docker

To CURD database in Node.js, I choose Prisma. It's because Prisma uses an elegant schema syntax to describe data model, for example:

model User {
  id String @id @default(uuid())
  username String
  password String
  bio String?

  posts Post[]

  createdAt DateTime @default(now())
}

model Post {
  id String
  title String
  userId String
  user User

  createdAt DateTime @default(now())
}

Even if you haven't heard of Prisma, you can probably understand how the database is like through this schema file.

Prisma will generate a js client to query database for you when you run npx prisma generate. This js client is typed so that you can get intellisense.

Use Next.js for dashboard and as an API server

Next.js is a very good framework for building fullstack application. You don't need to do a frontend setup and then do a backend setup. Instead, Next.js takes care of both.

Use Prisma in Next.js

There is no difference between using Prisma in Next.js and Node.js. The only thing you need to take care is that in development environment, Next.js will clear cache when hot reload. New PrismaClient would be initialized many time. It will cause a warnning:

warn(prisma-client) Already 10 Prisma Clients are actively running.

To deal with it, I create a singleton helper to make a singleton instance:

export const singleton = <T>(id: string, fn: () => T) => {
  if (process.env.NODE_ENV === 'production') {
    return fn()
  } else {
    if (!global[id]) {
      global[id] = fn()
    }
    return global[id] as T
  }
}

This helper caches the instance on global, which won't be clear in Next.js. I use this helper to create a singleton prisma, which can be imported from everywhere without being worried about duplicated db connections.

export const prisma = singleton('prisma', () => {
  return new PrismaClient()
})

Using middlware in API routes

I use next-connect to use connect-like middlewares. A traditional API route handler in Next.js is like:

import { NextApiRequest, NextApiResponse } from "next";

export default async function handler(req: NextApiRequest, res: NextApiResponse) {
  if (req.method === 'GET') {
    // ...
  } else if (req.method === 'POST') {
    // ...
  }
}

With next-connect, it becomes:

import nc from "next-connect"

export default nc()
  .use(someMiddleware())
  .get(async (req, res) => {
    // ...
  })
  .post(async (req, res) => {
    // ...
  })

So I can write an auth middleware that inject a user object in the req:

function auth(req, res, next) {
  const user = await getUser(req.cookies.token)
  req.user = user
  next()
}

export default nc()
  .use(auth)
  .post(async (req, res) => {
    console.log(req.user)
    // ...
  })

Handling API route error

I used to think handling error in Next.js is hard. But next-connect is a game changer. I can handle all errors in api route handler in a single catch-all error handler onError like:

// src/pages/api/foo.ts

const handler = nc({
  onError(err, req, res, next) {
    console.error(err)
    next()
  }
});

export handler
  .get(async (req, res) => {
    throw new Error('foo')
  })

It makes error handling more easy because I can apply the Exception Filters pattern:

Throw unified error object anywhere and deal with it in a single place.

I choose @hapi/boom as the unified HTTP exception object. I can throw Boom exception in api routes and handle it on onError:

import * as Boom from '@hapi/boom'

export const apiHandler = () => nc({
  onError(err, req, res, next) {
    if (Boom.isBoom(e)) {
      res.status(e.output.payload.statusCode);
      res.json({
        error: e.output.payload.error,
        message: e.output.payload.message,
      });
    } else {
      res.status(500);
      res.json({
        message: "Unexpected error",
      });
      console.error(e);
      // unexcepted error, catch with Sentry, etc.
    }
  }
});

apiHandler()
  .get(async (req, res) => {
    const post = await getPost(req.query.postId)
    if (!post) {
      throw Boom.notFound(`Post not found`)
    }
  })

I write a apiHandler method that return a next-connect instance.

In the above example, I throw a Boom.notFound exception in the api route handler, this exception will be caught in onError, and set the corresponding http response status code and message.

Setup authentication in a minute

In hosted service, I don't want to implement my own user system because it can be complicated. I prefer using third-party login through OAuth.

next-auth is a authentication solution for Next.js. I follow the Prisma Adapter guide and integrate GitHub providers just in a minute! All I need to do is create a GitHub OAuth application and set up the next-auth provider in src/pages/api/[...nextauth].ts.

In api routes, I can simply call getSession() to get the current user. Remember we can use middleware in api route with next-connect? This is how do I secure the api route with a middleware:

// middleware
import { getSession }  from 'next-auth/client'
import * as Boom from '@hapi/boom'

export async function authGuard(req, res, next) {
  const user = await getSession({ req })

  if (!user) {
    throw Boom.forbidden('Please sign in first')
  }

  req.user = user

  next()
}

Then, I can use this authGuard middleware in any api routes that need to be secured:


// src/pages/api/foo.ts

apiHandler()
  .use(authGuard)
  .get(async (req, res) => {
    console.log(req.user)
    res.json({})
  })

Secure frontend page

If the whole page is not visible without signed in, I will check the session in getServerSideProps. If session is null, return a redirect to sign in page:

import { getSession } from 'next-auth/client'

export default PageOne() {
  return (
    <div>
      Not visible
    </div>
  )
}

export const getServerSideProps = (ctx) => {
  const session = await getSession({ req: ctx.req })

  if (!session) {
    return {
      redirect: {
        destination: '/api/auth/signin',
        permanent: false,
      }
    }
  }

  return {}
}

Comment widget

One of the main goal of Cusdis is being light-weight. I set a package size "budget" for the widget, that the sdk embedded in user's website and the resouces the sdk loads must be less than 10kb.

Svetle is the best choice in this case. It doesn't come with a runtime and compiles the component into vanilla JavaScript.

To my suprise, the final full-feature SDK was only 5kb (gzipped).

pic.twitter.com/LgPli2ysdb
— Randy (@randyloop) April 28, 2021

The widget source code

In the first SDK version, the SDK will append the widget element to the user's website. It works well at first. But the problem is that the stylesheet of the user's website will affect the style in the widget component. Also, we have to prefix the class name when styling the element, to prevent our style won't affect the user's website.

The best practice would be put the widget component into an iframe. Everything works well except one question:

How to set iframe's height automatically according to the content height?

The iframe's height is fixed when it was created, no matter how the document in iframe would change. In order to make its' height automatically set to the document height, I use MutationObservable in the iframe to observe any document changes, when a change happens, it postMessage to parent window with the new offsetHeight, then the parent window change the iframe's height:

// in iframe

function requestResize() {
  window.parent.postMessage({
    event: 'resize',
    offsetHeight: document.documentElement.offsetHeight
  })
}

const resizeObserve = new MutationObserver(() => {
  requestResize()
})

resizeObserve.observe(target, {
  childList: true,
  subtree: true
})

// in main window

window.addEventListener('message', e => {
  if (e.data.event === 'resize') { 
    iframe.style.height = `${e.data.offsetHeight}px`
  }
})

I'm not sure this is the best implementation. If you have better idea, please leave a comment.

Dealing with timezone

Comment created date would be saved as current UTC time in database when the comment is created. Users around the world would see this time in the widget the same, but not as their local time.

For example, when a user from China (UTC+8) see 2021-04-28 10:00 (in UTC), he thought the comment was created at Beijing time 2021-04-28 10:00 but is is not true. It was created at 2021-04-28 18:00 in Beijing time.

It means that when we display the time, we need to transform it by user's UTC offset first.

Fortunately, there is an API getTimezoneOffset() in browser, to get the UTC offset value. I send this value through HTTP request header:

import axios from 'axios'

export const apiClient = axios.create({
  headers: {
    'x-timezone-offset': -new Date().getTimezoneOffset()
  }
});

Then on the server side, we use dayjs to handle this offset:

const timezoneOffset = req.headers['x-timezone-offset']
const parsedCreatedAt = dayjs.utc(comment.createdAt).utcOffset(timezoneOffset).format('YYYY-MM-DD HH:mm')

Use Vite to bundle the SDK

The SDK should be bundle in a single JS file. I choose Vite because it's fast, and it has a built in PostCSS support. In other words, I don't need to care about the bundler, the only plugin I use is rollup-plugin-svelte for compiling Svelte component:

// vite.config.js

module.exports = {
  build: {
    lib: {
      entry: path.resolve(__dirname, '..', 'widget', 'sdk.js'),
      name: 'cusdis',
    },
    outDir: path.resolve(__dirname, '..', 'widget', 'dist'),
  },
  plugins: [
    require('rollup-plugin-svelte')({
      emitCss: false,
    }),
  ],
}

Wrapping up

Cusdis spent me one week to release the first version. Now there are around 50 active websites using Cusdis as their comment system. More than 10 people sponsor this project. All of these tools combine together makes me build a full-stack SaaS project so fast:

next-auth to integrate third-party login in a minute
next-connect to add a middleware layer in Next.js and comes with a better error handling solution
prisma to generate typed ORM sdk
chakra-ui to write usable and beautiful UI
react-query to handle HTTP request

I also make a boilerplate with these awesome tools so that you can bootstrap your next SaaS project just in a minute!

I'm working on an open-source, lightweight alternative to Disqus

Randy — Fri, 23 Apr 2021 16:25:18 +0000

I used Disqus on my personal blog. Last week I tried to make a Disqus alternative for myself called Cusdis. Here are the key features:

Open source, easy to self-hostable (on Vercel or Docker). Users own their data.
The embedded SDK to the website is lightweight (only ~5kb gzipped)
All comments won't be displayed until it's approved by moderator.
Email notification, one-click to approve new comment.
Don't track users.

Here are some screenshots:

The tech stack:

Next.js
Prisma
Chakra-ui
Svelte (the JS SDK)
next-auth

My next step is to make it integrate with more existed system (hexo, hugo, wordpress, gatsby, etc.)

Hope you like it 🥰

Repo: https://github.com/djyde/cusdis
HackerNews Discussion: https://news.ycombinator.com/item?id=26878153
Product Hunt: https://www.producthunt.com/posts/cusdis

A tool for managing VS Code code snippets

Randy — Fri, 25 Dec 2020 05:20:08 +0000

When you realized you have typed some codes 100 times, you should save it as a code snippet. For example, I made a snippet for hapi route, when I type hapi:route it will trigger intellisense and then generate the router boilerplate code for me.

https://dev-to-uploads.s3.amazonaws.com/i/u1zwukev53co6g3pnlma.gif

It hard to write and maintain the VS Code code snippet because the code snippet was in a JSON file. So I wrote a tool to generate this JSON file for me, and I need only write the snippets in a folder.

The tool

The tool called snp (which means snippet). You can install it by curl:

$ curl -sf https://gobinaries.com/djyde/snp | sh

It is written in Go so it can run on many platforms, include Windows.

Create your snippets

You can create a folder to organize all your code snippets now:

$ mkdir snippets
$ cd snippets

Then you can create a file with .snp extension. The file name would become the trigger text.

For example, I want to write a hapi route snippet, now I
create a hapi:route.snp file:

$ touch hapi:route.snp

// hapi:route.snp
---
scope: typescript,javascript
description: hapi route
---

server.route({
  path: '$1',
  method: '${2|GET,POST,PUT,DELETE|}',
  async handler(req, h) {
    $0
  }
})

As you can see, .snp file is just a file that contains a front matter and the code snippet.

If you are not familiar about the VS Code code snippet syntax, please see https://code.visualstudio.com/docs/editor/userdefinedsnippets#_snippet-syntax

Run snp -u, now go to VS Code and type hapi:route, you will see the magic:

Conclusion

You can now use snp to manage your VS Code NATIVE code snippets, instead of using some code snippet manager apps that only help you copy and paste.

See more on https://github.com/djyde/snp

my personal snippets: https://github.com/djyde/snippets

Using file-test to test your generated file

Randy — Sun, 07 Apr 2019 15:54:18 +0000

When we write a program that will generate some files, how do we test this kind of program? I always use the fs module, test if the directories or files are existed. But I need to write many boring codes for this.

So I write file-test, for the test cases that care about the generated.

Suppose I wrote a program that should generate this directory structure:

- root
  - readme.md
  - A
    - a.js
    - b.js
  - B
    - a.ts 
    - b.ts

With file-test, I can simply test it like:

const FileTest = require('file-test')

const ft = new FileTest(path.resolve(__dirname, './root'))

ft.includeFile('readme.md') // => true
ft.includeFile('blabla.md') // => false
ft.includeFile('A/a.js') // => true
ft.includeFile('A/b.js') // => true

ft.readFile('A/a.js') // => console.log('hello js')

ft.includeDirectory('A') // => true
ft.includeDirectory('B') // => true
ft.includeDirectory('A/a.js') // => false

ft.include([
  'readme.md',
  'A/a.js',
  'B/a.ts',
]) // => true

ft.include([
  'readme.md',
  'A/a.ts',
  'B/a.ts',
]) // => false

It is easy to use with Jest too:

test('directory structure', () => {
  expect(ft.includeDirectory('B')).toBe(true)
  expect(ft.includeDirectory('A/a.js')).toBe(false)
  expect(ft.readFile('A/a.js')).toEqual(`console.log('hello js')`)
  expect(ft.include([
    'readme.md',
    'A/a.js',
    'B/a.ts',
  ])).toBe(true)
})

Github Repo: https://github.com/djyde/file-test

Generate Project Logo with Google Fonts

Randy — Thu, 20 Dec 2018 10:37:00 +0000

Motivation

Every time I want to make a logo for my project, I love using Google Fonts, and select a font, download the font, open Sketch.app, create a text field using that font, type my project's name, and finally export it to png.

Here is some crafts I'd made, for example:

https://github.com/djyde/rehux

https://github.com/djyde/serlina

Picas

So today I build Picas, which helps you generate these kind of logo.

Automatically load Google Web Fonts

Just go Google Fonts to find your favorite font name. Tell Picas the font name and it will automatically generate the logo with this font.

Retina friendly

For retina friendly, the image is 2x large.

Hope to see the logos you create with Picas!