Help us understand the problem. What is going on with this article?

2019年のWebフロントエンド技術学び(TypeScript, Next.js, GraphQL, etc.)

追記

続き :arrow_down_small:


機会があって最近Webフロントエンド開発に入門したので雑メモです。
あくまで自分で触った範囲の話なので網羅性は限定的です。
理解の客観的な誤りはコメントなどいただけると喜びます :sparkles:

TypeScript

  • 型ありJavaScript
  • コンパイル(トランスパイル)するとJavaScriptになる
  • 単に「文字列型」だけではなく「”mysql” か “sqlite” だけ」みたいな縛りを表現できる
  • 「文字列か数値」など柔軟な表現もできる
  • まとまった型だけを定義する方法に type と interface があるが差はだいぶ減ってきている模様
    • いまいち使い分けわかってない
    • 私は今のところ型だと思えばtype、I/Fだと思えばinterface使ってる
  • いわゆるOO言語のようにClass書ける
    • 最近のJavaScript(ECMAScript)知らないので、ECMAScriptとTypeScriptの差分がよくわかってない

SPA, SSR, Next.js

  • SPA == Single Page Application
  • SSR == Server-Side Rendering
  • SPAはかっこいいが404ページが作れないなど制限もある
    • "not found"と表示はできるが、status 404を返すことが原理的にできない
  • SSR組み合わせるとちゃんと404返せる
    • Status 404返した後でJSでかっこよくページ表示するのは自由
  • 検索エンジン対策はGoogleさんに限ってはもはやSSR不要
  • 個人的なSSRのモチベーションは2つ
    • ちゃんとステータスコード返したい
    • SlackやSNSに貼ったときにOG表示されてほしい
  • SPAとSSRを同時にやろうとしたけどなかなか難しかった
    • 私は主にwebpackで死んだ
  • そこでNext.jsですよ
    • https://nextjs.org
    • SPAっぽく作りながらSSRもサポートしてくれる
    • Reactで書ける
    • フロントエンドのroutingをディレクトリツリーで書けるので初心者には楽
  • Next.jsとよく間違えたやつにNuxt.jsがある
    • https://nuxtjs.org
    • 全く別もの、解決してる問題のレイヤーは近そう
    • こちらはVueベース

Webpack

  • JSを中心に各種リソースを文字通りpackしてくれる仕組み
  • loaderなどを組み合わせて設定する
    • 「TypeScriptをtranspileするならts-loader」など
  • 概念は単純なんだが組み合わせるものが多すぎてよく負ける
  • フロントエンドについてはNext.js使うとある程度隠蔽してくれるので楽

Redux

  • 「イマドキなGlobal変数の入れ物」と理解した
  • フロントエンドで使う
  • ただし各所から読み書きしてカオスにならない仕組みがある
  • 変数に階層作ることができるので「これはUI用」「これはリソース用」など分けて設計すべし
    • UI用: drawerの開閉状態, etc.
    • リソース用: テーブルで表示する実データ, etc.

ORM

  • 個人的に触ってみたのはSequelizeとTypeORM
    • https://sequelize.org
    • https://typeorm.io/#/
    • どちらもmigrationなどもある程度サポートあり開発には困らない印象
    • 本番運用は未知数、まぁ高負荷な本番でORMのmigrationそのまま使えることなんてきっと稀ですよ😇
  • 好みとしてはしばらくTypeORM一択だと思う
    • SequelizeでTypeScriptなかなか大変そうだった
  • TypeORMはTypeScriptでClass書いてpublic変数にアノテーション付けてくだけなので馴染みがある人には楽

GraphQL

  • https://graphql.org
  • REST以外の選択肢として提示されたフロントエンド←→BFFのプロトコル
    • 別にどこで使ってもいい
  • RESTのエンドポイント命名に疲れた方に
  • 要は「ER図そのまんまクエリにすればええやろ」的発想
    • 人類はなぜ今までこれに気づかなかったのか
    • もちろんDBの内容と関係なくエンティティを定義して扱える
  • 難点は「エンティティの定義をあちこちで」やりがちなこと
    • フロントエンドとBFFで同じ定義使いたい
    • ORMとI/Fでエンティティ定義を共通化するソリューションとしてはTypeORM+TypeGraphQLがある
  • 「認証とかどうすんの?」と思ってたが普通に書けた
    • ログインはmutationとして書く
    • 以降認証状態の検証はリクエストヘッダにtokenなり埋めとけばいい
    • 当初混乱したけど慣れたらふつーふつー
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
No comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ユーザーは見つかりませんでした