フロントエンドについて学んだ2ヶ月

雑に文章を書きたかったので書いてみる。 fbもかえってきたし、自身の振り返りも兼ねて書いてみる。

気づけばエンジニアとして再びコードを書き始めてから2ヵ月ちょっとが経った。

7月にエンジニアに戻り、2ヵ月ほど引き継ぎをして、9月に正式にコードを書く人間になった。

9-11月はフロントもapiも書いていた。

どちらかといえばフロントのコードを書いていた時間が長いように思う。

その過程で得たフロントサイドの学びについて雑記してみる。

あと最近の気づきも。

理解したことをヴァッと書いてみる。

frontside覚えること多いですね

人材事業に入ってからreact(+redux)のコードを読み書きすることが多い。 先週今週の業務はほとんどreact+reduxのコードを読んでいた。

広告事業にいた時はphpでサーバーばっかり書いていた。主な担当は管理画面だったけど、フロントはサーバサイドレンダリングが多かったし、多少のvuejsを触った程度だった。

reactの導入に伴い勉強もしたけど、実際にコードを書くことはなかった。

だから、がっつりapiとclientに別れているコードを触るのは初めて。

プロダクト

今のプロダクトではUIで起きる状態管理に関して、プロダクト初期〜現在にかけて時間をかけて色んなアプローチを試している。

もちろんライブラリのupdateや新機能の追加による影響もある。

その結果、画面ごとに設計が異なっていたり、状態管理の単位が違っていたりする。

設計や状態管理の単位が変わるたびに脳内でコンテキストスイッチを切り替えるのは結構大変な作業である。

実際、componentや状態を変えるための経路が多くどのように動作しているのか頭のなかに置いておくのが難しい。

何度もなんども同じ箇所を読み返して理解していく。

難しい。今も難しい。

この記事を書く5分前まで眉間にシワを寄せていた。

学びが多いし、そもそも学ばないとコードが読めない。

そもそもの哲学を理解しないと無理

そもそも何をしたいのか、どんな思想のもと動いているのか理解しないと無理だ。

コードに頻発する action? reducer? store? state? なんだそれよくわからん。

2年エンジニアをしていて、まともにform 1つも作れなくてびっくりした。

reduxはfluxを基にしている。

fluxもreduxも状態管理を関心ごとにしている。

細かい部分はインターネッツに任せるとして、それらがやりたいことの本質は 「一方向の状態操作」 に尽きると思う。

それを知らないと何もできない。

ほとんどの状態変更が一方向の操作

「reduxはイベントドリブンの状態変更を一方向に限定したもの」と理解しているのだけどもきっとそれほど間違った説明でもないだろう。

一方向の状態変更が

初期状態を描画 -> 状態変化 ->  イベント(action) 生成 ->  actionを拾って新しい状態を生成(reducer) -> 描画

みたいなlife cycleを永遠繰り返す。

reduxが管理するstateだから redux state と呼ぶことにしよう。

パーツを切り分けて一つ一つが協調して動く

画面を構成するパーツはcomponentとして分けられる。 componentをいっぱい集めて一つの画面をつくる。

そもそもhtmlがelementの集合によってできているのだからそれと理屈は同じ。

ちょっとした違いはreactが仮想化したdomをレンダリングすることだ。 html elementをreactがラップしており、そいつらを固めたパーツにしておく。

そしてreactがパーツを実際のhtmlとしてレンダリングしていく。domdom。

componentが知りうるのは、dom構造とそのdomに入りうるデータ/型、そして起こしうるイベントを伝達するインタフェースである。

さながらグラスワインタワーに水を差し込むように、空のcomponentに命を吹き込むかのごとく、上からデータを引き渡していく。

propsとして渡されたデータを基にcomponentは自分が引き受けたdomのレンダリングやイベント発火、エラー表示を引き受ける。

パーツが協調して動く。

reduxとしてのstateとcomponentとしてのstate

基本的には一方向の状態変更が行われると書いた。

あれは嘘だ。いや嘘ではないんだけど、それ以外の状態変更も起きうる。

componentの中で状態を持ちたいケースがある。

componentの中で閉じていい状態(例えば入力制御用のフラグとか)はcomponent の中でもつstateで解決すればいい。

react hooksを使えば簡単にstateが持てるし指定した状態に関する副作用も検知できる。

僕の中での問題は その使い分けがいまいちまだわかっていない ことだ。

どこまでをredux stateに持つべきでどこからをcomponent stateに持てばいいのかまだわかっていない。

おおよその理解。

component stateでcomponentに閉じた短期的な状態を保持しておいて、actionをおこし、その値で持ってredux stateを置き換えに行く。

componentの初期状態となりうるstateはredux stateに持っておく。

そんな感じで使われるのが今の主流なのかな〜。これはチームメイトに聞く。

ここはもっとコードを読んで書いていくしかない。

型....

vgに入ってからずっとphpを書いてきたし、個人で何かを作る時はrubyを書いていた。 llばっかり書いているから型に関する耐性がないしどのように型を利用するのかいまいちまだ馴染みがない。

コードを書く以前の問題で型に関するプラクティスというか経験が足りなくてそこで詰まることも多い。

恥ずかしながらジェネリクス？なにそれ？からスタート。

使用言語がtype script, scalaと型に厳格だし、とても詰まる。

export type PiyoPiyoPayload = Partial<
    Pick<Fuga, Exclude<keyof Fuga, 'hoge'>> & {
        piyo: Partial<Piyo>;
    }
>;

こういうのを見たときにまだ身構える気持ちが抜けない。

人生、雰囲気でプログラムを書いてきてしまったのだなぁと能力不足を感じる。

大丈夫、上記のコードも30分ほど調べて読めるようになった。

大丈夫、人間は学ぶ。

何が言いたいかというと日々何かを学べることはいいってこと

ありがたいことに日々必ず新しい学びがある。フロントだけでなくてサーバも、もちろん仕事の進め方も。

だけど、何より大切なのは「慢心せずに学ぶこと」なのかなと。

正直、昨日の自分より1つでも強くなっていればいい。

楽器だって学びを与えてくれるのだろう

基本を丁寧に積み上げ、日々磨き続ける。言葉にすると陳腐だけど何事においても大切だよね。その姿勢は見習いたい。

ありがたいことに 同僚？上司に ドラムを褒めていただけた。

あんまりドラムを褒められることがない人生だったのでとても嬉しい。

---

楽器をやってきてよかったと思うことは 「クソ地道な基礎練習がお前を上手くする」 と学べたことだ。

クソ地道な基礎練習は誰も褒めてくれないし、誰もやれなんて言わない。

メトロノームに合わせて棒を振る

なんて地味な練習に最近は興奮すら覚えるので稀有な癖を持って生まれたな、と自身でも思う。

楽器はまさにそうだけど 地味さを面白がってやれない なら上手くならないし仕事も似たようなもの。

プログラミングも地道に知らないことを調べて潰していって、書いて間違えてを繰り返す作業だ。

楽器の練習してるのと実はそんなにやること変わらない。

プログラマやデザイナが楽器弾ける人多いのはそういう理由なのかも。

2ヶ月前よりドラムうまい自信があるし、2ヶ月前よりnextのコード書ける自信ある。

日々成長してるんだろう。

日々必ず前進できるようにやっていき :muscle: