アルパカログ

easy-notion-blog バージョン0.13 では新たに ToDoブロック、Table of contentsブロック（目次）に対応しました。

また、大きな変更点としてコードの可読性を向上するために Notion API レスポンスの型を定義しました。

変更の詳細は下記をご覧ください。

Release v0.13.0 · otoyo/easy-notion-blog

What’s Changed Support todo blocks by @otoyo in #128 🐌 Fix inline-break in table-block by @herohoro in #129 Support table of contents by @otoyo in #130 Refactor tests and fix interfaces by @otoyo…

https://github.com

この記事ではなぜ API レスポンスの型定義を行ったのか、easy-notion-blog の今後の展望について説明します。

TypeScript にはその名の通り、型 (type) の概念があります。

しかし、型の概念は TypeScript 特有ではなく、JavaScript や Ruby、Python といった他の多くのプログラミング言語にも存在します。

型の概念を持つプログラミング言語は、静的型付けと動的型付けの2つに大別されます。

TypeScript は静的型付け言語で、JavaScript や Ruby、Python は動的型付け言語です。

静的型付けと動的型付けは何が違うのでしょうか？

それは変数やオブジェクトの型が評価されるタイミングの違いにあります。

プログラムは書かれてそのまま実行されるのではなく、コンパイラによって実行に適した形に変換されます。

この工程をコンパイルと言います。

コンパイル時に変数やオブジェクトの型が評価される言語のことを静的型付け言語と言います。

一方、コンパイルされたプログラムの実行時に型が評価される言語のことを動的型付け言語と言います。

静的型付け言語のメリットは、プログラムが実際に実行されていなくとも、型チェックによって事前にエラーに気付けるところにあります。

静的型付け言語には TypeScript の他に C、Java、Go などがあります。

TypeScript のおもしろいところは、厳密に型を定義しなくとも any 型としてプログラムをコンパイル（トランスパイル）できるところでしょう。

これによって、ひとまずは型定義せずに動くものを作る、動くものができたら型を定義する、といった2段階のフェーズでスピーディに開発することができます。

easy-notion-blog の開発ではこの恩恵を最大限に生かしていました。

初期の Notion API は対応ブロックが増えたり、レスポンスのフォーマットが変わったりすることが少なくなく、初めから API レスポンスを厳密に定義したとしても、途中でガラッと変わってしまう可能性がありました。

型を定義するということは、API の変更に際して追従すべき箇所が増えるということです。

そういう意味で、API レスポンスの型をここまで定義せずに開発してこれたのは大きなアドバンテージでした。

ここ最近は API の変更がほとんどなくなったので、ようやく型を定義しました。

型を定義しておくことで、今度は API レスポンスが急に変更されたときに何が原因かすぐに気付けるようになります。

API レスポンスの型を定義することで、開発者のメリットもあります。

例えば paragraph ブロックを取得した際に、型定義がなければ都度 API リファレンスを参照しなければなりません。

しかし下記のように型定義があると、いちいち公式リファレンスを参照しなくて済みます。

rich_text というフィールドに RichTextObject の配列を持っているとか、 color は文字列で表されるんだな、ということがひと目でわかります。

interface Paragraph {
  rich_text: RichTextObject[]
  color: string
  children?: BlockObject[]
}

また、テキストエディタによっては型定義があることで、フィールド名をサジェストしてくれるようになります。

エディタのサジェスト機能を最大限に生かすことで typo を減らし高速にプログラミングできるようになります。

これが API レスポンスの型定義を追加した理由です。

easy-notion-blog は今回のバージョン0.13 の次はいよいよ正式版となるバージョン1.0 のリリースを予定しています。

バージョン1.0 では Next.js 13 へのアップデートを含むかもしれませんが、他には大きな変更は予定していません。

easy-notion-blog の作者として、今なんとなく持っている目標は2つあります。

ひとつはリポジトリの star 数で、先日70に達しました。

star はその OSS がどれだけの人に使われているかを表す一つの指標だと思っているので、まだ star してないよという方は star していただけると喜びます。

当面は 100 の大台が目標です。

二つめは、企業のオフィシャルブログに採用されることです。

円安のため Vercel 含む海外ホスティングサービスの費用が高騰しているのでなかなか難しそうではありますが、これまで Notion の対応ブロックも増やしてきましたし、型定義やテストも必要最低限は確保できていると思うので、首を長くしながら待ちたいと思います。

企業のブログ担当者の方は easy-notion-blog の採用をご一考ください。

こちらの記事で easy-notion-blog を採用することのメリットを紹介しています。

以上です。

この記事ではなぜ API レスポンスの型定義を行ったのか、easy-notion-blog の今後の展望について説明しました。