0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

静的Webページのコーダーで、サーバーサイドJavaScriptを勉強しようとしている人への共有

Last updated at Posted at 2024-11-28

記事の対象・内容

ローカルだけですが、とりあえず一通り動くNode.jsツール(Next.js+TypeScript+Playwright)を初めて作成しました。それを作成中に思ったよもやま話を伝えようかと思います。参考になれば幸いです。

作ったツール

ざっくりいうと、Webページで読み込んでいるファイルをアーカイブして、ついでに遷移先のレスポンスステータスなどを記録するツールです。使い方とかは上記遷移先をご覧ください。ChatGPTで質問しながらElectronでアプリ化を試みたのですが、どの設定を間違っているのかが分からず、断念しました。

想定している読者

HTML・CSS・JSでフルスクラッチ制作は可能で、これからサーバーサイドJavaScriptの勉強に手を付けようとしている人に向けた記事です。
※ かなり定性的で主観的な記事になっています。
※ 検索したら簡単に出てくる各ソフトウェアの概要は省略しています。

プラットフォームの選定の話

javascriptでバックエンドが書けるプラットフォームはNode.js・Deno・Bunがありますが、学習の入り口としてはまだNode.jsをお勧めします。
古いバージョンの情報が散見されるとはいえ、フレームワークやライブラリはまだまだNode.jsを基準に作成されているように思えるからです。

フレームワークの環境構築の話

フレームワークにビルドツールがあるならそれを使用したほうがいいです。手作業で構築を試みると、ネットの情報はバージョンの情報が古かったりしてうまくいかないことが多いです。
next.jsであればcreate-next-appを利用しましょう。
利用するか不明なツールの場合はとりあえず入れたほうがいいです。後から入れると苦労します。

create-next-appには選択肢が無いですが、単体テストツールであるjestも入れたほうがいいです。単体テストを繰り返しながら少しずつモジュールを増やしましょう。そうしないとかなり辛いです。

JavaScriptの話

コーダーだとIE11に対応しているJavaScriptを引き続き使用している人も多いかと思います。しかし、最低でもアロー関数と分割代入、async/awaitは使いこなせるようになったほうがいいです。コードの例ではよく見かけるのでこれが理解できないと話が先に進まないです。

TypeScriptの話

TypeScriptは必須だと思います。導入すると記述量が増えますし、全てが想像通りに動くことはまず無いです。ある処理を記述中に何かエラーが出て、解決方法にとっかかりが無い場合は別の記述を試したほうがいいです。
そんなことを書くと「使う意味あるのか」という疑問が出てくると思いますが、使ったほうがいいです。深いオブジェクトの階層の指定をミスってたとか、非同期処理なのにawaitが漏れていたりとか、JavaScriptだけだと実行しなければ検知できないバグを実行前に検知しやすくなります。
あと、変数にホバーするとツールチップである程度の型の情報や、コメントを見ることができるので日を置いた後の修正にはほんとに役に立ちます(これはTypeScriptというよりVisual Studio Codeのメリットですが…)

jest(ts-jest)の話

jestなどの単体テストツールも必須だと思います。
例えば、ツールのこのtestファイルのように、HTMLのブラウザ側でのリダイレクトの修正を確認したいときに、わざわざ修正→ツールを実行→レスポンスを確認とかしなくても

npx jest src/component/snapshot/api/sub/getResponseByPageGoto.test.ts

と実行すれば修正後の挙動の成否がわかります。
※ Windowsの場合は

npx jest src\\component\\snapshot\\api\\sub\\getResponseByPageGoto.test.ts

でも可。
単体テストの作成とまではいかなくても、モック中にconsole.logを記述するだけでも、修正の度にツールを一通り実行する手間がなくなるのでかなり楽になります。

追記:未確認ですがESModuleの場合はVitestの方がいいらしいです。

今書いているJSはどこで動く?

Web制作だとJSはWebページを閲覧しているブラウザでの挙動のみを考えれば大体は問題ないです。一方、同じくJSで処理を記述するNode.jsが絡むと考え方を切り替える必要があります。
今回作成したツールでは以下の3種類のコンテキストがあります。

  • エンドユーザーのブラウザに表示される、Reactが制御するUI画面で動くJS
  • サーバーサイドの処理(Node.js)で動くJS
  • サーバーで起動したPlaywrigthが実行するJS(evaluateメソッドに渡すpageFunction等)

このあたりを認識しないと、エンドユーザーのブラウザで動くJSに、ファイルの書き込み処理を書いて「何で動かないんだ…」と頭を抱えたりします。
気を付けましょう。

困ったときは

チャットAIに聞きましょう。コードの一例がすぐにでてきます。Google検索では情報が古かったりするのであてになりません(特にNode.js関連)。それぞれのパッケージのリファレンスも、そもそもバックエンド知識が必要だったりするのである程度慣れてからのほうがいいです。
もちろん、チャットAIだと誤った情報が出てくる可能性もありますが、上記のJestでモックを作成できればトライ&エラーはそんなに苦ではないと思います。

参考

TypeScriptは型安全じゃないからすばらしい

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?