Next.jsを初心者向けツールとして捉えている自分が、実践 Next.js を読んでみて
Next.jsを初心者向けツールとして捉えている自分が、実践 Next.js を読んでみて2024-03-28 この記事は 実践 Next.js の書評です。 見本誌を頂いた上での記事です。（PR記事？） tl;dr App Router のメリットを理解しつつも、学習コストに割り合わないと思っている人にオススメ！ドキュメントを読めるようになるし、学習コストが下がる。 はじめに 自分はどちらかというと今の Next.js に対しては否定的な感情の割合の方が高く、仕事で困らない程度の最低限の知識しか持っていない。 しかし、なんだかんだ勉強の必要性に駆られていて、そのキャッチアップとして同書の発売を楽しみにしていた。 そんな折に @takepepe さんから見本誌をいただいたことで、この週末に読んだので書評を書きたい。 俺は今のNext.jsが好きではない 書評を書く前にポエム書かせてくれ！
モノレポにすべきか、レポジトリを分割すべきか
先日 フロントエンドの Monorepo をやめてリポジトリ分割したワケ というブログがバズっていた。そのおかげか、Twitter でもモノレポに関する言及がちょこちょこあった。一家言あるドメインなので書きたい。ただの一家言(a.k.a お気持ち)なのでぜひ皆さんの意見も聞いてみたい。 tl;dr 別に自分はどっち派とかではなく、どっちも選ぶ。強いて言うならリポジトリ分割派で、依存更新がしんどくなったら monorepo 派。 免責 モノレポに対する一家言を書きたいだけであって、内容自体はフロントエンドの Monorepo をやめてリポジトリ分割したワケ と全く関係なく、そのブログで述べられている施策については何も言及しません。ただ一つ言及するとしたら肉の部位がコードネームに採用されているのは良いと思いました。🍖🍖🍖 モノレポにしたくなる状態の前提にあるもの 前提は元記事と同じように
Webサーバーアーキテクチャ進化論2023
はじめに 最近プログラマーとしてのキャリアに一区切りつけようと思っており、これまでのプログラミングの勉強の集大成となるブログを書きたくなったので書く。初めてプログラミングをして、フロントエンド開発をして、サーバーから値が返ってきたときは「どういう仕組みで値が返ってきたんだ？」と疑問に思っていた。ずっと理解したくて理解できていなかった。だからずっと勉強していた。そして最近になってようやく自分の言葉で説明できるようになった気がしたのでブログを書きたい。 2015 年版が自分の原点であり、この記事を書くモチベーションになった このような記事は実は過去に存在している。 FYI: https://blog.yuuk.io/entry/2015-webserver-architecture その記事はサーバーがどういう仕組みで動いていて、どのように進化し、2015 年に至るかを解説してくれた記事だ。自
無限スクロールは考慮することが多い
毎年無限スクロールの実装をしているのだが正直なところ実装したくないので依頼されたときの反論材料として実装したくない理由を言語化しておこうと思う。 無限スクロールとは 無限スクロールが何を指すかを知らない人のために解説すると、ページにコンテンツを足す方式でページネーションする UI を指している。例えば Twitter のように下にどんどんコンテンツが伸びていく UI が良い例だろう。そのような UI を無限スクロールと呼ぶことが正式なのかは知らないが、このような体験の実現を支援するライブラリに infinite-scroll というものがあり、少しは普及している呼び方なのだと思い無限スクロールという言葉を使う。一方で WEB フロントエンド文脈で無限スクロールと言うと複雑 GUI やドローイングツール実装における "無限平面" のようなニュアンスもあるが、今は無限平面のことを指しているわけ
React ユーザー向けの Next.js ガイド
最近会社で Next.js のチュートリアルを担当することがあったり、これからもあるので資料として記事をしたためておこうと思う。 対象は、React は知っているけどこれから Next を学ぼうとする人が想定。 つまり React 単体と Next の差分をまとめる。 React そのものから学びたい人は別の資料にアクセスした方が良いだろう。 Next の学習教材 とりあえず公式だけ読めば良い。(これでいまブラウザバックされたら面白いな・・・) 主に二つあり、 ドキュメントや API: https://nextjs.org/docs/getting-started チュートリアル: https://nextjs.org/learn/foundations/about-nextjs を読むと良い。 Next は何を解決しているか、何が嬉しいか 元々は SSR のための煩雑な手続きをしなくてい
Prettier と ESLint の組み合わせの公式推奨が変わり plugin が不要になった
前に書いた ESLint と Prettier の共存設定とその根拠について が公式推奨が変わったことにより一部間違った情報になっているのでその訂正記事です。 該当記事に書いた内容は Prettier と ESLint の関係を読み解く上で役立つ情報だと思うので、警告とこのページへのリンクを書いた上でそのまま残しておきます。 (追記) この記事の内容も間違った内容を書いていました。なので一度大幅な訂正をしています。prettier-eslint も推奨ではありません。 変更点の要約 Prettier と ESLint の組み合わせについて公式 の推奨方法が変わりました。 きっといつかこの情報も古くなるので直リンクではなく、ドキュメントの GitHub のリンクを貼っておきます。 ドキュメント自体のリンクはこちらです。 新しいドキュメントを要約すると、 Linter と Formatter
ESLint の Plugin と Extend の違い
ESLint の Plugin と Extend の違いを説明できますか？ 違いを知っている人からすれば（というかそもそも全然違うものなので）、「え、それ悩む？」となるところなのですが、ユーザー向けドキュメントには Plugin の定義が書かれておらず、Extend の説明も不十分で、さらに Plugin の設定をする Extend なんてものがあるお陰で、慣れないうちは混乱すると思います。 特に最後の事象は個人的には印象的で、「Plugin の設定をしていないのに Plugin が設定されている。Plugin って何？」といった混乱の原因になっていました。 この混乱は ESLint の全体感を掴むと混乱しなくなるのでそういう話を書きたいと思います。 実際に混乱してた人も多そうです（6/24 更新) 結論を言うと、Extend は Extend です。設定を Extend する役割を持って
ブログに CSS in JS 環境下での スタイル分離リファクタリングを施してみた
そろそろブログを大幅に改修しようと思っており、その前準備をしてリファクタリングをしていました。 具体的には css modules からの脱却と、スタイル周りのリファクタリングをしていました。 そのとき、経年劣化に耐える ReactComponent の書き方 と styled-components の採用と既存資産を捨てた理由 という記事を参考にしました。 これらは styled を一つのコンポーネントに当ててその中で SASS 記法で中にスタイルを当てていくというもので、CSS in JS 環境下において、styled と DOM を分離するテクニックとして学びがあるものでした。 僕は styled-compoennts ユーザーですが、styled-components の採用と既存資産を捨てた理由でも触れられているように、 styled なラッパーコンポーネントとかがいっぱい作られ
css-loader と style-loaderを間違えない ~css-loaderを使わずにcssを使ってみる~
css-loader と style-loaderを間違えない ~css-loaderを使わずにcssを使ってみる~2020-06-26 css-loader と style-loader どっちがどっちかってたまになるので、そうならないための備忘です。 これらは webpack の loader であり、JS で構築されるアプリケーション内で CSS を扱うために利用されます。 最近は CSS in JS の利用も増え、CSS ファイルを読み込む機会は減ってはきているものの、reset.css を読み込んだり、UI ライブラリが提供するグローバルな CSS を読み込んだりと CSS を直接 JS に import する機会はまだまだ多いと思います。 そして 1 ファイルでも CSS を読み込むなら loader にその設定が必要となるので、まだまだお世話になり続けるでしょう。 そんな利用
Reactのコンポーネント周りの用語を整理する
React のコンポーネント周りの用語ってごっちゃごちゃになった経験はありませんか? 友人と話すときなどはなんとなくのニュアンスで伝わるので気にしていなかったのですが、型注釈つけるときやコードリーディングするときに言葉の定義がわからなくなって何回も調べるといったことをよくやるのでこれを機に整理しようと思います。 本記事では JSX 以外にも createElement 記法の知識も要するので、自信がない方は公式やどうして JSX を使ってもエラーにならないのか？をご覧ください。 ここでは React のドキュメント JSX Elements Components TypeScript の型定義 JSX.Element ReactElement DetailedReactHTMLElement DOMElement FunctionComponent Component ReactNode
Next.js における環境変数まわりの挙動まとめ
OGP は「環境を考慮しよう！」という画像です。 NextJS へ環境変数をセットする時、デプロイを考慮した上で.env を使いたい・ビルド時と起動時の環境変数がある・サーバーとブラウザでの環境変数があるといった風にややこしい点があり、自分はよく調べ直しています。 基本的には以下の 3 つの公式ドキュメントを見ればいいのですが、 Environment Variables Environment Variables(basic-features) Runtime Configuration 整備されたのが最近なので古い情報が定着していたり、ここに書いていない細かい挙動なんかもあったりするので、まとめて行こうと思います。 .env.* を使って読み込める Environment Variables にもある通り、.env.* を使うことで環境変数を読み込めます。 設定ファイルに環境変数を書い
vercelでの環境変数の扱いが便利になった
Vercel での環境変数周りでのあれこれ、ずっと苦しみ続けていたので自分なりのプラクティスをメモします。 辛さの原因は Vercel のアップデートのスピードが早く正しい情報にアクセスし辛いことが一因としてあるので、それをなくせたら良いなと思っています。 もしこのドキュメントが古くなっていたら Issues などからお知らせていただけると幸いです。 Next.js を前提とした解説になりますが、 Next.js の環境変数周りについては解説を省きます。 Vercel での環境変数周りがややこしいのは Next.js に起因しているものもあるとは思うのですが、話が長くなるので別の記事にて補足したいと思います。 (ビルド時・サーバー・クライアントで見える・渡せる環境変数や方法が変わる話) やりたいこと: フロント側から環境変数別にエンドポイントを切り替える Vercel は プレビュー環境と
ESLint と Prettier の共存設定とその根拠について
注意 この記事は 2020 年 09 月 24 日現在、古い情報となりました。 eslint-plugin-prettier の利用は非推奨であると公式がアナウンスを出しています。 そのことについては Prettier と ESLint の組み合わせの公式推奨が変わった にてまとめましたので、こちらもご覧ください。 また eslint-plugin-prettier は公式推奨ではなくなりましたが、それは Editor などの外部環境の進化によるものでこのプラグイン自体に何か問題が起きたわけではありません。 そして eslint-plugin-prettier を利用した設定方法、特に eslint-plugin-prettier と eslint-config-prettier が何を解決していたかを知らないと、prettier-eslint が何をどう解決したかを理解できないはずなので
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
noopener と noreferrer の整理、結局どっちを使えば良いのか