匠の相駕籠

ソフトウェア開発者の日常 - メメントモリ公式ブログ『匠の相駕籠(たくみのあいかご)』

最近勉強していること

 この記事はプログラミングについて、すこし専門的な内容を含んでいます。

 

  最近、仕事の関係で 、ずっとフロントエンドに関係する技術を勉強している。React と Redux とそれに関連する技術なのだけど、とにかく難しくて、理解するのに時間がかかる。サンプルのソースなどを動かしながら、ドキュメントを読み込んでいる。

 

 まだ使いはじめの技術なので、学習時間が長い。仕事の成果になかなか結びつかないため、仕事の進捗は悪い。とはいってもお客さんも、新しい技術に取り組むことは了承してくださっているし、進捗が悪いといっても、はじめてから2週間くらいのものだから、正直こんなものだろう。

 

 さて苦労しながらも、なんとなく React と Redux の使い方が見えてきた。と同時にそのツラさも...。

 

 

 React というのは UI を構築するためのライブラリという位置づけで、アプリケーションを構築するアーキテクチャを含んでいない。アーキテクチャが含まれているものは、なんとなく私たちはフレームワークと呼ぶことが多い気がする。例えば Ruby on Rails はアーキテクチャを含んでいるので、これはフレームワークだろう。

 

 React に適したアーキテクチャが必要だということで、Flux というアーキテクチャが提唱されている。Redux というのは、Flux アーキテクチャを実装に落とし込んで、そして Redux 流のインスパイアを吹き込まれたようなライブラリ。

 React と Redux をセットで使うことで、わりとフレームワークっぽくなる。

 

 わたしにとって問題だったのは Redux のほうで、これが理解が難しかったのだけど、ようやく使い方が見えてきた。

 

 Redux はとにかく state と呼ばれるシングルトンのデータツリーがいちばん大切なもの。その他については、どうやって state の状態を変更するか、変更された state をどういうふうに見た目(View)に反映するかをフォローしているだけに過ぎないのだと理解した。

 

 とにかく大切なのは state 。たぶん React & Redux においては、最初にやるべきことは state の設計なのだと思う。

 

 わたしのこれまでの経験から目新しく感じたのは、Redux がデータの流れ(データフロー)に注目していることだと思う。state を変更する場合も、state を見た目に反映する場合も、データの流れがあり、そのデータの流れを Redux が一つのやり方しか許さないように設計されている。

f:id:kosuke-komiya:20180616040209g:plain

画像の引用元:Modern Web Development with React and Redux (by Mark Erikson)

 

 React & Redux を使おうとすると、関連するライブラリがゴロゴロとでてくる。API 通信ライブラリ、非同期処理ライブラリなど、いくつか選択肢があって、自分が必要なものを組み合わせて、開発環境を整えていかなければならない。

 これがけっこうたいへん。

 

 あと実装をしながら思ったことは、ちょっとしたことをやるにもコードの変更量が多い。これは React & Redux のせいであるとは言えない。そもそも JavaScript でフロントエンド開発をしていると、いつもちょっとしたことがすごく大変だったり、変更の影響範囲がひろすぎて収集がつかなくなったりする。

 

 フロントエンド開発ってつらいなぁって以前から思っていたけど、React & Redux もこれに対してはまだ決定打になっていないような気がする。ということは、これからもまだまだ激しい変化にさらされるのではないかなと思っている。フロントエンドって。