DEV Community: niwoshi

Next.js（TypeScript）のプロジェクト作成 ESLint+Prettier（＠2022-06-29）

niwoshi — Thu, 14 Jul 2022 01:24:46 +0000

ちょっと色々変わってないか確認がてらプロジェクトの作成をまとめなおします。

この辺は気がついたら推奨設定が変わってたりするのでちょいちょい見直したいところです。

プロジェクトの作成

nodeがインストールされた環境を想定しています。まずはプロジェクトを作成しておきます。

npx create-next-app [プロジェクト名] --typescript

必要最低限は上記のコマンドで準備されます。
個人的に頻繁に触りそうなファイル群はsrcというディレクトリにいれときたいので、pages、stylesはsrcというディレクトリを作成して入れておきます。
Next.jsではデフォルトでsrcというディレクトリが存在すればそちらをpagesが含まれているディレクトリとして認識してくれるので、これで動作します。
とはいえ、絶対パスに"@"を利用したい（いちいちパスを記載するのが面倒）ので、tsconfig.jsonにbaseUrlの設定を追加します。

    "incremental": true,
    "baseUrl": ".",
    "paths": {
      "@/*": ["src/*"]
    }

これで相対パスを省略して記載できます。

一応動作を確認しておきたいので、src/pages/index.tsxの4行目を下記のように変更してみます。

import styles from '@/styles/Home.module.css'

動作チェックです。

yarn dev

問題無く表示されればOKです。

Voltaでnodeとyarnのバージョン固定

自分はnodeのバージョン管理にVoltaを利用しています。

ある程度よしなにしてくれるのでほっといてもいい気はしますが、トラブルに巻き込まれた際に面倒になるのでnodeとyarnのバージョンをプロジェクトで固定しておきます。

volta pin node@16
volta pin yarn@1.22

ESLint+Prettier

ESLint

create-next-appで作成していれば必要最低限の準備は既に出来ています。
試しに、.eslintrc.jsonを次のように書き換えて、セミコロンの警告を出します。

{
  "extends": "next/core-web-vitals",
  "rules": {
    "semi": ["error", "never", {"beforeStatementContinuationChars": "never"}],
    "semi-spacing": ["error", {"after": true, "before": false}],
    "semi-style": ["error", "first"],
    "no-extra-semi": "error",
    "no-unexpected-multiline": "error",
    "no-unreachable": "error"
  }
}

index.tsxなどのどこかにセミコロンを記入して

yarn lint

すると警告が表示されると思います。
この時点で

yarn lint --fix

で修正まで入るようになります。

Prettier

整形は例にならってPrettierで行います。よって、先ほど追加したセミコロンのルールは削除してしまって構いません。（ESLint -> Prettierの順番で実行しようと考えているのでどうせ上書きされる）
PrettierとESLintのプラグインをインストールしておきます。

yarn add -D -E prettier
yarn add -D eslint-config-prettier

eslint-config-prettierの設定を適応させるために、.eslintrc.jsonを書き換えておきます。

{
  "extends": ["next/core-web-vitals", "prettier"],
  "rules": {
    "semi": ["error", "never", {"beforeStatementContinuationChars": "never"}],
    "semi-spacing": ["error", {"after": true, "before": false}],
    "semi-style": ["error", "first"],
    "no-extra-semi": "error",
    "no-unexpected-multiline": "error",
    "no-unreachable": "error"
  }
}

package.jsonに書いてもいいんですが、既に.eslintrc.jsonも生成されてますので、.prettierrc.jsonを作成してそこにPrettierの設定を書いておきます。
とりあえず自分の必要最低限のモノだけ書いています。

{
  "trailingComma": "all",
  "tabWidth": 2,
  "semi": false,
  "singleQuote": true,
  "jsxSingleQuote": true
}

Prettierでプロジェクト全体を整形したい場合用に、package.jsonのscriptsにformatというコマンドを追加しておきます。

    "format": "prettier --write ./**/*.{js,jsx,ts,tsx,json,css} --ignore-path .gitignore"

とりあえず上記までで

yarn lint --fix
yarn format

で全体を解析＋フォーマットできるようになりました。
ここから先はお好みで、ローカルで解析やテストを回すなら「husky+lint-staged」、コミット先でやるなら「Github ActionsでESLint+Prettier+テスト」という構成などが考えられると思います。

参考

https://qiita.com/mysticatea/items/9da94240f29ea516ae87

Django REST frameworkのユニットテスト

niwoshi — Thu, 20 Jan 2022 10:37:02 +0000

Django REST framework（以下DRF）のテストについて軽くまとめておきます。
一応前回の続きという事で進めて行きます。
正直Djangoのテストは慣れていないのでなにからやれば良いか試行錯誤している段階ではあります。

テストフォルダの作成

DRFの場合、テスト対象としてはアプリケーション毎にモデル、シリアライザ、ビューの3種類が考えられます。
startappで自動生成されるapiv1/tests.pyにテストを書いていってもいい気もしますが、上記3種のテストを1ファイルに書いてしまうと肥大化していくのは目に見えているので、上記を分離しておきます。
apiv1/testsフォルダを作成して

apiv1/tests/__init__.py
apiv1/tests/test_models.py
apiv1/tests/test_serializers.py
apiv1/tests/test_views.py

の用にテストファイルを作成します。（必要なものだけで大丈夫かと思います。）
__init__.pyは空ファイルで大丈夫です。ついでに

apiv1/tests.py

は削除しておきます。

ビューのテスト

今回はDRFのviewsetsをそのまま継承して利用しているだけなので、おそらくテストは不要だと思います。
とはいえ一応チュートリアル的な観点で試したいのでTodoの生成だけテストを書いておきます。apiv1/tests/test_views.pyを作成します。

from django.urls import reverse
from rest_framework.test import APITestCase


from todos.models import Todo


class TodoCreateTests(APITestCase):
    def test_create_success(self):
        params = {
            "title": "test_create_success",
        }
        url = reverse("apiv1:todos-list")
        response = self.client.post(url, params, format="json")

        self.assertEqual(Todo.objects.count(), 1)
        self.assertEqual(response.status_code, 201)
        todo = Todo.objects.get()
        expected_json_dict = {
            "id": str(todo.id),
            "title": todo.title,
            "checked": todo.checked,
        }
        self.assertJSONEqual(response.content, expected_json_dict)

    def test_create_bad_request(self):
        params = {
            "title": "",
        }
        url = reverse("apiv1:todos-list")
        response = self.client.post(url, params, format="json")

        self.assertEqual(Todo.objects.count(), 0)
        self.assertEqual(response.status_code, 400)

下記コマンドで全テストが捜索され実行されます。

python manage.py test

アプリケーションやクラスを指定して実行もできますが、ここでは割愛します。

シリアライザのテスト

シリアライザのテストは、実際のリクエストを受け入れる際のバリデーションと、レスポンスを返す時の出力内容を検証すれば大丈夫だと思います。引き続き、apiv1/tests/test_serializers.pyを作成します。

from django.test import TestCase

from todos.models import Todo
from ..serializers import TodoSerializer


class TodoSerializerTest(TestCase):
    def test_input_valid(self):
        input_data = {"title": "test_input_valid"}
        serializer = TodoSerializer(data=input_data)

        self.assertEqual(serializer.is_valid(), True)

    def test_input_invalid_if_title_is_blank(self):
        input_data = {"title": ""}
        serializer = TodoSerializer(data=input_data)

        self.assertEqual(serializer.is_valid(), False)
        self.assertCountEqual(serializer.errors.keys(), ["title"])
        self.assertCountEqual([x.code for x in serializer.errors["title"]], ["blank"])

    def test_output_data(self):
        todo = Todo.objects.create(
            title="test_output_data",
        )
        serializer = TodoSerializer(instance=todo)

        expected_data = {
            "id": str(todo.id),
            "title": todo.title,
            "checked": todo.checked,
        }
        self.assertDictEqual(serializer.data, expected_data)

とはいえ、先ほどのビューのテストで作成を検証していて、titleがブランクの時にエラーがでる処理を検証しているので少し被っている気もします。
上記の例で言えばシリアライザのテストのみでいいと思いますが、そもそもviewsetsを利用している場合は開発段階で十分テストされていると思うので、省略してしまっても大丈夫だと思います。

モデルのテスト

こちらは通常のDjangoでのテストと変わらないので割愛します。

参考

Django REST frameworkの初期セットアップ

niwoshi — Thu, 20 Jan 2022 10:36:45 +0000

Django REST framework（以下DRF）でバックエンドを構築する際の初期設定をメモ代わりに書いておきます。
（書かないと無限に忘れるので・・・）

プロジェクトの作成

プロジェクト名はtutorialとしておきます。
ディレクトリを作成して仮想環境(venv)が導入されている前提です。

まずはrequirements.txtに必要最低限のライブラリのみ書いておきます。
よく使うライブラリもこのタイミングで入れていいと思います。

django
djangorestframework

必要パッケージのインストール

pip install -r requirements.txt

Djangoプロジェクトの作成をコマンドで行います。
この辺は完全に好みだと思うのですが、プロジェクト名/プロジェクト名/settings.pyみたいにプロジェクト名が二重にネストするのがちょっと気持ち悪いので、この設定ファイルなどがあるディレクトリ名をconfigにするために、下記のようにDjangoプロジェクトを作成します。
仮想環境を入れたプロジェクトファイル下で下記のコマンドを実行します。

django-admin startproject config .

プロジェクト全体のディレクトリ構成は下記の様になります。

tutorial
├─ venv
├─ requirements.txt
├─ manage.py
└─ config
   ├─ __init__.py
   ├─ asgi.py
   ├─ settings.py
   ├─ urls.py
   └─ wsgi.py

機能的にはtutorial/tutorialになってもなんら問題無いのでこの辺は完全に好みです。むしろこっちの方が面倒。
動作チェックはDRFとして動いて欲しいので、適当なモデルを作成してから行います。

アプリケーションの追加

試しにTodoを管理するアプリケーションを想定して構築してみます。
DRFはAPIエンドポイントとして運用される想定なので、一応バージョニングを意識して

APIエンドポイント用のアプリケーション（ここではapiv1）
モデル用のアプリケーション（ここではtodos）

を分離しておきます。
manage.pyでアプリケーションを作成しておきます。

python manage.py startapp apiv1
python manage.py startapp todos

ここで初期設定もかねてconfig/settings.pyを編集します。

...

from pathlib import Path
from django.conf.locale.ja import formats as ja_formats

...

INSTALLED_APPS = [
    "django.contrib.admin",
    "django.contrib.auth",
    "django.contrib.contenttypes",
    "django.contrib.sessions",
    "django.contrib.messages",
    "django.contrib.staticfiles",
    "rest_framework",
    "apiv1.apps.Apiv1Config",
    "todos.apps.TodosConfig",
]

...

# Internationalization
# https://docs.djangoproject.com/en/3.2/topics/i18n/

LANGUAGE_CODE = "ja"

TIME_ZONE = "Asia/Tokyo"

USE_I18N = True

USE_L10N = True

USE_TZ = True

ja_formats.DATE_FORMAT = "Y/m/d"
ja_formats.DATE_INPUT_FORMATS = ("%Y/%m/%d",)
ja_formats.DATETIME_FORMAT = "Y/m/d H:i:s"
ja_formats.DATETIME_INPUT_FORMATS = ("%Y-%m-%d %H:%M:%S",)

...

INSTALLED_APPSの追記は、Django 3.2からAutomatic AppConfig discoveryで不要になったと聞いたのですが、自分の環境では何故か管理画面にモデルが表示されないので追記しています。

モデルの作成

models.pyの編集

何はともあれモデルがないと始まりません。
Todoモデルtodos/models.pyを作成していきます。

import uuid
from django.db import models


class Todo(models.Model):
    class Meta:
        db_table = "todo"

    id = models.UUIDField(primary_key=True, default=uuid.uuid4, editable=False)
    title = models.CharField(max_length=200)
    checked = models.BooleanField(default=False)
    created_at = models.DateTimeField(auto_now_add=True)
    updated_at = models.DateTimeField(auto_now=True)

    def __str__(self):
        return self.title

idをUUIDにしていますが、ここは好みです。（とはいえ、UUIDの方が推奨されそうですが・・・）

admin.pyの編集

モデルを作ったら管理画面で編集できる様にしておきたいです。
todos/admin.pyを編集します。

from django.contrib import admin

from .models import Todo


class TodoAdmin(admin.ModelAdmin):
    fields = ["title", "checked"]
    list_display = ("title", "checked", "id", "created_at", "updated_at")


admin.site.register(Todo, TodoAdmin)

一応管理画面を確認しておきたいので念のためDBを更新してからcreatesuperuserで管理ユーザーを作成しておきます。

python manage.py makemigrations
python manage.py migrate
python manage.py createsuperuser

ここまでやれば管理画面からモデルを操作できるので、動作に不安のある場合はこの辺で新規作成などしてみても良いと思うます。

シリアライザの作成

DRF特有の存在であるシリアライザを作成します。
これはAPIの機能なのでapiv1/serializers.pyに作成します。

from rest_framework import serializers

from todos.models import Todo


class TodoSerializer(serializers.ModelSerializer):
    class Meta:
        model = Todo
        fields = [
            "id",
            "title",
            "checked",
        ]

ビューの作成

API用のビューapiv1/views.pyを編集します。

from rest_framework import viewsets

from todos.models import Todo
from .serializers import TodoSerializer


class TodoViewSet(viewsets.ModelViewSet):
    queryset = Todo.objects.all()
    serializer_class = TodoSerializer

ルーティングの設定

大体の機能は実装できたので、ルーティングの設定をしておきます。
まずはapiv1/urls.pyを作成します。

from django.urls import path, include
from rest_framework import routers

from . import views

router = routers.DefaultRouter()
router.register("todos", views.TodoViewSet, basename="todos")

app_name = "apiv1"
urlpatterns = [path("", include(router.urls))]

routerにtodosを登録する際にbasename="todos"と指定しているのは、django.urlsのreverse関数で逆引きする際にapiv1:todos-listとしたい為です。コレを指定していない場合はビューのquerysetに登録したモデルの名称が採用されてapiv1:todo-listと参照されてしまう様です。

今回はビューをModelViewSetで実装したのでルーティングが楽です。
あとはconfig/urls.pyを編集します。

from django.contrib import admin
from django.urls import path, include

urlpatterns = [path("admin/", admin.site.urls), path("api/v1/", include("apiv1.urls"))]

ここまでやれば、APIとしては実装完了です。

動作チェック

DRFはデバッグモードではブラウザ上で色々確認出来ます。
試しにアクセスしてみると、何もないリストが返却されているのが確認出来ると思います。

POST用のフォームもあるので、そちらから追加して見るもヨシ、cURLなどで追加して見るもヨシです。

おわり

上記だけでCRUD操作ができるAPIが構築でき、管理画面も使いやすいしカスタマイズしやすいのがDRFの良さだと思います。
本来であれば認証まわりも実装すると思いますが、今回は簡略化のため省きました。
実際に実装する場合はDRFの設定（settings.py）とビューでの設定などが必要になると思います。