2019 年の夏に前職を辞め、そのまま無職として過ごし今年の 10 月にようやく再就職して働き始めた。 何か事情があって働けなかったわけではなく、プログラミングの能力を伸ばすために敢えて就職しなかった。 自分にとってそれなりに重要な期間だったと思うので、記録を残しておく。 予め断っておくが、何か「すごいこと」を成し遂げたわけではない。「すごくないプログラマ」が少しでもすごくなりたくて勉強していた話に過ぎない。 「すごいプログラマ」が「すごいこと」をした話を読みたければ、以下の記事などがよいと思う。 会社をやめて約1年プログラミングの勉強に費やしたことに対する満足と後悔 | blog.ojisan.io 2年間の独学をふりかえって – Happy Coder 予防線を張ったところで、本題に入る。 背景や動機 プログラミングの勉強をするために前職を辞めたわけではなく、退職の理由は別にある。 そ

去年からフロントエンドのパフォーマンスについて断続的に学んでいるが、自分の頭のなかにある知識はどれも断片的で、まとまりを欠いているような感覚があった。 知識と知識がつながっておらず、各施策が何のために行われるのかも、必ずしも自明ではなかった。何となく「パフォーマンスに効果がある」と言ってしまうが、それが何を指しているのかは実は曖昧だった。 このような状態では新しい知識を得ていくのが難しいというか、効率的に行えないように思えた。議論の背景が分からないし、文脈や問題意識を上手く掴めないから。何の話をしているのかよく分からない、という状態になりがち。書かれてあることの意味は分かっても論旨を掴めているわけではないから、自分のなかに定着しない。 そこで、現時点で自分が知っていることを整理して、自分なりに分類しておくことにした。 当たり前だが、どのテクニックがどの程度有効なのかは、状況によって違う。

History API は、HTML5 で導入された API。 これを使うことで、JavaScript で URL の履歴を管理できるようになる。 多くの場合、そういった操作は React Router や Vue Router などのルーティングライブラリを通して行うことになる。そのため、History API を直接操作する機会は稀だと思う。 しかし、ルーティングライブラリを使いこなし、特殊なユースケースにも対応できるようになるためには、History API そのものについても理解しておきたい。 この記事では、ルーティング機能を持った React アプリを開発しながら、History API について学んでいく。 使用している React のバージョンは16.13.1。 動作確認は Google Chrome の81.0.4044.113で行っている。 コンテンツに対して URL を

「発生し得ない値」などのように説明されるnever型。 概念としては分かるのだが、実際にどのようなケースで使えばよいのかイメージできずにいた。 neverを使ったテクニックを調べていて多少のイメージは掴めてきたので、整理しておく。 動作確認は TypeScript のv3.7.5で行っている。 never 型の特性 まずはnever型がどういった型なのか、理解する。 決して発生し得ない値や型は、never型になる。 例えば以下のif文では、elseブロックは絶対に実行されないため、そのなかではfooはneverになる。 const foo = true; if (foo) { foo; // const foo: true } else { foo; // const foo: never } 「存在し得ない値」なので、どんな値も代入することはできない。 const foo: never

SPA を開発する際に必須のタスクの一つとして、History APIのフォールバック（以下、単に「フォールバック」と記述する）がある。 この事象について掻い摘んで説明すると、SPA においては URL と HTML ファイルが一対一になっていないので、それに伴う対応を行うこと。 SPA ではその名の通りページは一枚しかなく、URL の管理や表示するコンテンツの切り替えは、ルーティングライブラリが行っている。 例えば、唯一のページを返す URL がhttp://example.com/である場合、その URL が返す HTML ファイルが JS ファイルを読み込み、その JS ファイルがルーティングライブラリによるプログラムを実行することで、http://example.com/fooやhttp://example.com/barといった URL が有効になる。 問題となるのが、いきなりh

Cookie とは、HTTP でステートフルなやり取りを実現するために、ブラウザとサーバ間で情報を送受信する仕組みである。 HTTP は本来ステートレスなプロトコルである。そのため、同一のユーザーが連続でリクエストを行っても、それぞれ独立したリクエストであり、「同じユーザーからのリクエストである」とサーバが認識することはできない。 これは例えば、ログイン状態の管理で問題となる。ID とパスワードで認証を行っている場合、リクエストの度に ID とパスワードを送信しなければならない。 Cookie を使うことで、このような事態を解決できる。 まず、サーバがブラウザに対して、Cookie としてどのような情報を保存するのか指示する。具体的には、レスポンスヘッダにSet-Cookieフィールドを含め、そこに Cookie として保存させたい情報を設定する。ログイン状態を管理したい場合は、セッション

React.SuspenseとReact.lazyを使うことで、import()で動的に読み込んだコンポーネントを通常のコンポーネントとしてレンダリングすることができる。 動的読み込みはパフォーマンス向上のためなどに使われるが、それを簡単に React アプリに取り入れることができる。 import()の概要はこちらを参照。 numb86-tech.hatenablog.com この記事に出てくるコードは React のv16.10.2で動作確認している。 React.lazy React.lazyは、コンポーネントを返す関数。引数には、import()の返り値をそのまま返す関数を渡す。そしてimport()で読み込まれるモジュールは、コンポーネントをdefaultでエクスポートしている必要がある。 そのため、以下のようになる。 // One.js import React from 'r

なぜグローバルな Store を作るのか React アプリの設計論では、複数のコンポーネントで利用する値をどのように管理するか、というテーマがよく話題になる。 前提として、コンポーネントは小さく分割すべき、という考え方がまずある。 これは React に特有のものではなく、プログラミングの一般論として、ひとつひとつの関数は小さくするのがベストプラクティスだとされる。それには様々な理由があるが、単一責任の原則、疎結合、テスタブル、などがよく理由として挙げられる。 React のコンポーネントも同じで、肥大化しないように管理することが、保守しやすいアプリへの道だ。いかに適切な粒度でコンポーネントを分割できるかが、React を使いこなす上で重要となる。 だがコンポーネントを分割していくと、複数のコンポーネントで共通の値を扱う、という状況が発生しうる。 それにどのように対処するか、というのが、

ドメイン駆動設計（以下 DDD）に関心があるので読んでみた。 私のような初心者にも分かりやすい内容だったので、DDD に興味を持ったけど挫折した、という人は読んでみるといいと思う。 gihyo.jp DDD に関心を持ったキッカケはよく覚えていて、今年の2月。 SPA のフルリニューアルを一人でやることになり、設計や技術選定について考えていた。 既存の SPA の出来があまりにもひどくて、毎日がとにかく苦痛で不愉快だった。その体験があったため、自分はちゃんとしたモノを作ろうという気持ちが強かった。 そこらへんの話は以下の記事にも書いた。 numb86-tech.hatenablog.com その時期に出会った記事のひとつが、これ。 medium.com この記事の内容そのものも参考になったが、この記事で触れられている DDD にも関心を持った。 詳しくは分からないが、DDD というものを使

使用している React のバージョンは16.8.4。 レンダー後の処理を指定するための仕組み React Hooks の一つであるuseEffectは、レンダー後に実行したい処理を React に伝えるための仕組み。 useEffect(fn)と記述すると、DOMの更新が終わったあとにfnを実行する。 useEffectはレンダー後に必ず実行される。最初にレンダーした際もそうだし、propsやstateに変更があってレンダーし直した際もそう。そこに区別はない。 以下の例では、このコンポーネントが表示された際にeffect!というログが流れる。 そしてボタンを押下した際にも、その都度effect!というログが流れる。 import React, {useState, useEffect} from 'react'; const App = () => { const [state, set

2020/05/31 追記 勉強や経験を重ねた結果、この記事を執筆した時より知識が増え、コードの書き方にも変化があります。 サンプルアプリも同様で、以下のプロダクトのコードのほうが、今の自分の考えが反映されていると思います。 github.com 追記終わり 2019/07/14 追記 ディスカウント後の価格みたいな導出項目はselector (reselect)を使うとよいのでは https://redux.js.org/recipes/computing-derived-data - YonmanHasse のブックマーク / はてなブックマーク というコメントを頂き、確かに便利そうだったので導入した。 それに合わせてこの記事の内容もアップデートした。 追記終わり タイトルに書いた組み合わせで SPA を作るときにどのような設計にするのか、現時点での考えを記録しておく。 チュートリアル

SPA のフルリニューアルを技術選定や設計からやることになった。 前回の記事も、そのために検討や調査を行っている際に生まれた副産物をまとめたものだ。 目指すべきは変更しやすいシステムであり、そしてそれは、堅牢性を実現することで達成されるはずだという結論に至った。 numb86-tech.hatenablog.com 今回の記事では、堅牢なシステムの実現に向けてどんな技術を選んだのかを記録しておく。 まだ検証フェーズというか、試し書きや検証を行っている段階なので、今後変わる可能性はある。 前提 現行のアプリは Rails アプリで、その上に Vue を載せて SPA を作っている。 フロントエンドのビルドは Webpacker 。別のプロダクトでは Webpacker を剥がしてしまったが、このプロダクトでは実現できていない。 ビュー関連の処理について、どこまでを Rails でやってどこか

実務未経験でプログラマとして入社して半年以上が経った。 コードレビューで指摘されたことを備忘録としてまとめておく。 自分なりにまとめたものなので、レビュアーが言いたかったこととニュアンスや解釈がずれている可能性はある。 初歩的な内容ばかりで我ながらうんざりする。 せっかく優秀な同僚ばかりなのだからもっと高度なことを学びたいが、こういう初歩的なことが出来ないのが俺の現状なのだから、仕方ない。 そもそもPullRequestを送ったこともなかったわけだし。入社初日は、一人でPullRequestの出し方を練習していた。 それを考えればまあ、こんなものだろうか。 当たり前のことをちゃんと当たり前に出来るようになって、早く、次のステージに進みたい。 PullRequest(PR) PRのタイトルは分かりやすいものに。必要に応じてチケットの番号なども入れる。 コミットやPRは出来るだけ粒度を細かくす