00:06
はい、4月16日、日曜日ですね。
時刻は昨日10分になりました。
なんか昨日は大雨だったんですけど、
今日はなんか晴れそうな感じですが、
途中で雨も降るらしいですね。
今日も健康に気をつけていきましょう。
はい、おはようございます。
夢見のkeethことくわはらです。
ではでは、本日も朝活始めていきたいと思います。
今日はですね、朝のTwitterを見てですね、
タイムラインにめちゃくちゃ面白そうな記事が見つかったので、
衝動的に今日はこれを読んでいこうかなと思っています。
はい、書いてあります。
9インタビュークエスチョンズ、
Every Senior React Developer Should Knowということで、
まあ、リアクトのシニアエンジニア、
ディベロッパーの人が知っておくべきでしょう、みたいなことですね。
こと、まあ、べきなのかわからないけど、
知っているでしょう、みたいなことの、
9個の質問を読んでいこうかなと思っています。
5つの質問で、
なんですか、絞れるんですかね。
わかんないけど。
っぽいことをおっしゃってますので、
それを読んでいこうかなと思っています。
はい。
では、さっそくいきましょう。
リアクト開発者であれば、
いずれは上級職への大きな一歩を踏み出したい、
という衝動に駆られることでしょう。
多くの人は経験を重ねても、
ジュニアやミッドレベルの開発者から抜け出せないままでいます。
もちろん経験には時間がかかりますが、
上級開発者としての心構えはあっても、
必要なトピックを勉強していない方もいらっしゃるでしょう。
このブログでは、中途であればなく、
どのような回答をすればよいか、
創造ラインしていきます。
ここではリアクト開発者としての
上級職の面接で聞かれる可能性のある、
非常に一般的な面接質問を紹介してみようと思います。
はい。
一般的とおっしゃっていますけど、
どういうベースなんですか、
総数はどこにあるのかなという気はしますけど、
多分どこから出てくると思うので。
では、さっそく質問1個1個入っていきたいと思いますが、
まず質問1ですね。
質問1は、
リアクトアプリケーションのパフォーマンスを
向上させるために、
最適化しなければならない状況を説明できますでしょうか。
どのようにこの作業を行ったんですかということですね。
ははー、なるほどね。
さっそくパフォーマンス分割から入ってくるんですね。
シニアだって言っているからそうなんでしょうけど。
はい。
シニアリアクト開発者のポジションの候補者として、
あなたはより良いパフォーマンスのために、
リアクトアプリを最適化する方法を知っていることを
期待される時があります。
そうね。
リアクトのライフサイクルと
フックを理解することはその一助となります。
リアクトアプリのパフォーマンスを
最適化する方法には、
次のようなものがあります。
合計4つありますね。
1つ目。
不要な再レンダリングをとりあえず回避します。
2つ目。
リストレンダリング時に
UIDを使用すること。
3つ目。
ユーズメモやユーズコールパックのフックを使って
もろもろの関数をとりあえずメモ化します。
マウンティングチェックが必要になるということですね。
4つ目にマウンティングチェックが必要です。
合計4つでした。
これがパフォーマンス周りの改善策だと言っています。
03:00
詳しく他のものとかには
リアクト、リレンダリングを防ぐために
マウンティングチェックすることに関するブログとかも書いていますので
このブログも見てくださいと言いました。
このご本人のブログの別の記事でリンクがあるんですけど
リレンダリングをとりあえず防ぐための
マウンティングチェックに関する記事を
別途書いているところでした。
今のが1つ目ですけど
よくある話ではあるんですけど
よくあるものをちゃんと当たり前にできますかというのを
この人は質問1で問うているわけですね。
あとは復活のメモ化だったりとか
その復活のレンダリングタイミングだったりとか
その辺をどこまで深く理解しているかっていうのは
シニアかどうかっていうのの一つの基準になるかもしれないですね。
僕もそんなに詳しく理解しないので
この辺、質問されたらちょっと痛いなってところですので
僕は多分シニアじゃないんだろうなって感じです。
さっそく2つ目ですね。
質問2ですけど
大規模なリアクトアプリケーションで
状態管理をどのように扱うでしょうか?
ちょっと今日噛み噛みやな。
リアクトには2種類のステートがあります。
ローカライズされた状態とグローバルな状態になります。
ローカライズされたステートというのは
リアクトコンポーネントのスコープに配達であります。
グローバルステートはどのコンポーネントからもアクセスできます。
大規模なリアクトアプリケーションで
状態を管理するための一般的なライブラリにはいかのようなものがあります。
ライブラリ的には
リダックス、リコイル、状態、リマッチですね。
僕ちょっとリマッチだけ触ったことないですね。
一応名前だけは存じ上げていてですね。
存じ上げていて。人じゃないけど。
まあいいや。存じていて。
これがどんなステートの仕方をするかというのは
実は全然触ったことないので
これどっかで触りたいと思います。
リダックスがちょっと重かったというのはありますよね。
昔リダックス、何でもかんでもリダックスが良くないという話が一回あって
とりあえずストアライブラリとして
リダックスを入れるみたいな時代はあったんですけどね。
リダックスのための周辺ライブラリができるくらいちょっと重かったんですよね。
大きかったりするというのもあって。
現代では新しいアプリを作るときにリダックスを買いますかというと
そういうケースは結構少なくなったんじゃないかと勝手に思ってますけどね。
それとは別にやっぱりATOMSレベルとか
小さい単位で分割したりとか統合できたりもできますし
フックスとして提供できたりするものがあるというので
リコイルとか上体が最近は人気なんじゃないかなと勝手に思ってます。
上体がどれだけ人気なのかちょっと分からなくて
リコイルの方が一律の長があるんじゃないかなと思ったりはしましたね。
先に出たよというのも正直ありますので。
またショッピングカードのようにユーザーがページを更新したり離脱したりしても
ショッピングカードの中の商品を追跡するような例もあったりします。
もしデータがグローバル変数からアプリケーションのコンポーネントに渡されるだけなのであれば
ユーズコンテキストフックを実装することも可能です。
これはアプリケーションのUIをテーマ化したり認証プログラマー
やっぱりプロバイダーを実装したりする際にはとても有効です。
これについては投稿の後半で詳しく説明しますということで。
ではそのまま続いて読んでいきましょう。
続いては常の質問ですけれどもいきましょう。
リアクトアプリケーションで複雑なデータ構造を扱わなければならなかったときのことを説明できますでしょうか。
06:03
どのように対処したのでしょうかということですね。
データ構造複雑化した場合ですね。
どんなふうに管理をしましたかということですけれども
やっぱりなんだかんだ状態とかデータ周りのところが
シニアの人のチェックポイントの大きな一つなんだということがこれでわかりますね。
はいいきましょう。
リアクトアプリケーションで複雑なデータ構造を扱うには
ネストしたデータをマッピングする最適的なコンポーネントを使用して
複数レベルのネストを持つデータをレンダリングするリアクト.メモみたいな技術で
パフォーマンスを最適化するといったテクニックが必要になる場合があります。
複雑なデータ構造を操作変換するために
ローダッシュなどのユーティリティライブラリを使うこともまあまあ有効です。
高価なAPIリクエストの呼び出しを減らすために
ローダッシュライブラリのリバウンス関数を使ったこともあったりします。
この人はそういう感じなんですね。
僕はリバウンス関数をほぼほぼ使ったことがないですね。
ローダッシュはちょいちょい使えますね。
やっぱ便利ですからねローダッシュは本当に。
リアクトで複雑なデータ構造を扱うには明らかに多くの方法があります。
ここではデータ処理としてプレゼンテーションをより
慎重に扱わなければならない可能性のあるシナリオをいくつか紹介します。
というわけで4つ紹介されてますね。
1つ目、ツリーやグラフだなどネストされたデータ構造の場合ですね。
2つ目、テーブルやリストビューで表示し操作される必要がある大規模なデータセットです。
3つ目、オブジェクトや配列が何重にも入れ子になっているJSONオブジェクトなど。
入れ子のレベルが多いデータ構造ですね。
4つ目、ライブフィードやウェブソケット接続からのリアルタイムデータなど
常に変化するデータ構造だと。
これらは大体複雑化しますし大変ですよね扱いが。
特にしょっちゅう更新されるとか本当に大変ですよね。
データ自体が変わるって言うんだったらいいけど
データ構造まで変化するっていうのは結構面倒くさいですね。
では4つ目の質問ですね。
リアクターアプリケーションのテストはどのように取り組むのでしょうか?
リアクターアプリケーションが安定して正しく動作しているということを確認するために
優れたテスト戦略を持つことが重要です。
これにはユニットテスト、統合テスト、エンドツーエンドテストの組み合わせのほか
スナップショットテストやTDD、テスト駆動開発などのテクニックも以上含まれます。
いっぱいありますよねテストって言うて。
テストそのものの流度の話もありますし
それに応じたテスト、何をテストするかみたいなツールの話もありますし
何を使ってテストするかか
何を確認するかっていうところもあったりしますし
手法ですね。
テスト駆動開発をどこまでやるかっていうのは怪しいところでありますけど
僕はちなみにテスト駆動開発をちゃんと案件でやったことはないんですが
やってみたいっていう思いもなくはないか
どんだけベロシティー出るかっていうのはちょっと怪しいなと思ってます。
余談でした。
いろんな手法とかがあるんですけど
それらはちょっとざっとラレ通されてますね。
09:01
1、2、3、4、5、6、7、8個あります。
1個1個いきますけども
1つ目
リアクトテスティングライブラリやエンズイムなどの
リアクトに内蔵されているテストユーティリティを使用して
コンポーネントレンダリングと動作をテストするというのがまず1つ目です。
2つ目
個々のリアクトコンポーネントに対して単体テストを記述し
それらが分離して正しく動作しているということを確認します。
いわゆるこの辺はユニットテストと言われるものかな。
続いて3つ目
複数のコンポーネント間の相互作用というのをテストし
それらが正しく連携して動作しているということを確認するために
統合テストというのを記述します。
インテグレーションテストですね。
続いて4つ目
ジェストのようなテストフレームワークを使用して
テストを実行し整理します。
いわゆるそういうフレームワークとかツールを使っていきますとかですね。
5つ目
スナップショットテストを使用して
コンポーネントのレンダリングが予期せず変更されないということを確認します。
正しくレンダリングされているよりも
予期しないものがちゃんとないよということを確認する
というのがスナップショットテストですね。
こういう書き方をするといいですね。
続いて6つ目
テスト駆動開発TDDを使用して
機能の実装コードを書く前にテストを書きます。
そういう手法もあるよということですね。
7つ目
Synon.jsのようなモッキングライブラリを使用して
テストの中で依存関係をモックします。
これはでもジェストを使っていることが
リアクトの人たちはほぼほぼなので
ジェスト自体にモック機能があるから
それを使うことが多いんじゃないかな。
昔はSynon.jsを結構僕も使ってましたけどね。
はい、ラスト8つ目ですね。
エンドとエンドのテストを書いて
アプリケーション全体をテストし
実際のブラウザでのユーザーインタラクションを
シミュレートします。
はい、というところでした。
この辺はよくある手法で
ほぼほぼ確立していると言ってもいいかもしれないですね。
皆さんこの辺は使うでしょうみたいなところだと思います。
スナップショットテストですけど
エンジンを使うのもいいですけど
最近はストーリーブックを使うことも結構あるんじゃないかと思いますね。
あれでスナップショットキャプチャーが取れるんで
それをベースにテストをするというところも
全然あると思いますし。
はい、というところですね。
では続いていきましょう。
5つ目です。
質問5はですけども
リアクトアプリケーションで非同期アクションを扱うには
どうしたらいいでしょうか?
というところですね。
5つ目に非同期というピンポイントな質問をするんですね。
1つの方法として
asyncとawaitキーワードを使うことで
非同期なコードを同期に見えるスタイルで書くことができます。
asyncとawaitを使って非同期APIコードを行うコンポーネントの例を紹介しますので
一応ソースコードがペッと貼られてますね。
ちょっとざっと音読していきますので申し訳ないですけど
わかりづらいかもしれません。
とりあえず最初にimportリアクトですね。
import fromリアクトで
リアクト本体とuseStateとuseEffectを
直接インポートしています。
で、function myComponentという関数コンポーネントをとりあえず定義します。
今回は別にtsを使っていなくて
普通にこれ多分jsですね。
しかもアロー関数とかでの関数コンポーネント定義ではなくて
普通に従来というか
昔ながらのfunctionでの名前定義でのコンポーネントですね。
12:02
で、とりあえずfunction myComponentを括弧で
並み括弧で閉じていて
初っ端にconstであれですね
useStateを使っています。
初期値0ですね。
で、dataとsetDataという2つで受け取っています。
で、useEffectですね。
初期レンダリングのときに何かを実行するということですけど
第2引数は空配列なので
本当に1回だけですよということですね。
で、async、functionのfetchDataというメソッドを定義しています。
まず定義だけですね。
constのresponseイコール、await、fetchでなんかほげほげみたいなので
とりあえずデータを受け取ってfetchします。
ちゃんとawaitで非同期的なところを制御しています。
で、responseで変数で受け取って
そのresponseの値をawaitでまた
response.json、jsonメソッドですね。
使ってちゃんとデータ構造を
僕らが分かるオブジェクト形式に変換をすると。
で、受け取ったデータをsetDataですね。
先ほどのuseStateのところの初期の
あれですね、setter関数を使って
setDataで受け取ったデータをセットします。
っていうのを定義しておいて
定義した直後にfetchDataメソッドを実行すると。
これをuseEffect内で行う。
初期レンダリングのときに1回だけfetchを行って
それをsetDataで使ってuseStateの中で保存しておくと。
で、returnでjsxですね。
一番外側はdivタグだけ1個置いておいて
まずデータがあるかどうかというところを中身で見てますね。
あるんであればdivタグのdata.messageっていうので
メッセージを表示しておきます。
なければloadingっていう固定の文字列ですね。
表示しておくみたいな感じですね。
ちょっと音読で分かりづらかったですね。
すごくシンプルで分かりやすい。
典型的な、初期でデータを取ってきて
そのデータごとに表示するものを変えるっていうコンポーネントです。
続いていきますが、
リアクトで非同期関数を扱うもう一つの方法は
Axiosとかfetchのようなライブラリを使って
APIコールをすることです。
Axiosでもいいんですけど、fetcherはたくさんありますからね。
いろんなfetcherを使っていいと思いますけどね。
SWRとかあったりしますし。
あいつをfetcherかっていうと、fetcherではあるんですけど。
以下はAxiosを使った例です。
先ほどのソースコード例とほぼ一緒ですけど
インポートのAxios、fromAxiosという
Axiosライブラリというやつを使っていて
さっきのawaitで、
オリジナルのfetchメソッドではなくて
fetchメソッドではなくて
Axiosの.getを使って
値を受け取って取得をするみたいな使い方ですね。
ほぼほぼ一緒です。fetchを単純にAxios.getに変えただけです。
みたいな感じでデータのfetchをすることもできます。
こうやって非同期の処理をすることができるので
非同期処理の扱いどうやってやりますかって言うんですけど
単純にこれデータフェッチングの話っぽいですね。
この人のおっしゃっている意味では。
その時の受け取り方で結局async、awaitを使って
非同期処理をちゃんと制御すると。
15:00
コールバックの関数のデスト地獄をすることではないよってことですね。
これはでもどっちかというと
もはやシニアとかではなくて
アソシエイトでもみなさんできると思うので
この辺は見ていくのがいいと思います。
リアクトにおけるアプリケーショナルコンポーネントと
コンテナコンポーネントの違いについて説明してください。
リアクトではプレゼンテーショナルコンポーネントは
見た目に関係してコンテナコンポーネントは
動作に関係する。ざっくりとそういう感じですね。
対別すればということですね。
結構グラデーションがかかっている話もあったりします。
実際に実装していくとリウドとか境界線が曖昧になってくるものも
出てきたりはしますけど、一応対別とするとそういう感じですね。
プレゼンテーショナルコンポーネントというのは
通常UI要素を画面にレンダリングする役割を担っていて
データやコールバックをプロップとして受け取る機能的なコンポーネントとなる
傾向があります。
JSXのレンダリングに注力し、アプリの状態や
アクションを意識することはあまりないということですね。
プレゼンテーショナルコンポーネントは本当に単純にデータだけを出して
ペッと表示するだけみたいな、来たものを表示するだけに
過ぎないので割とシンプルな話ですね。
ここに一つプレゼンテーショナルコンポーネントの例が示されていますけど
import reactですね。from reactから行って
ファンクションボタンみたいなですね。
プロップスを受け取って、プロップス.labelみたいなのでボタンタグを
探してJSXでレンダリングするみたいな感じですね。
とてもシンプルなやつですね。
例えばこんな感じのものですよと言っています。
それとは対照的に、コンテナコンポーネントというのは
通常ステートとアクションの管理を担当し
データのフェッチングとかユーザー入力の処理とか
その他のタスクを実行するためのロジックを含む
クラスベースのコンポーネントとなる傾向というのがありますと
コンテナコンポーネントはアプリの状態とアクションを認識し
データとコールバックをプロップスとしてプレゼンテーショナルコンポーネントに
とりあえず渡します。ここに1つコンテナコンポーネントの例も
一応表示していますよと。
先ほどとは全然違って、import reactですね。
from react なんですけど、あとコンポーネントですね。
メソッドというのをそのまま、メソッドじゃないです。これはあれか。
定義か。というのを直接名前を指定して受け取っていますと。
あとはインポートボタンですね。先ほどのプレゼンテーショナルコンポーネントですね。
ボタンコンポーネントをインポートしておきますと。
クラスフォームなので、久しぶりにクラスコンポーネントですね。
見ましたけど、extendsのコンポーネントです。
react の方のコンポーネントをextendsしておいて
state イコール、ネームコロン、空文字列というところで
初期のステートだけセットしておきますと。
ハンドルチェンジメソッドイコール、イベントというのを受け取って
this.setstateですね。setstateを使って
先ほどのevent.target.valueですね。
値をネームコロン、その値を使ってオブジェクトとしてセットしておきます。
あとはハンドルサブミットですね。
こちらもメソッドで、イベントというのを引数に受け取って
event.preventdefaultをやっておきます。
あとサブミットザフォームで何か処理をすると。
18:02
最後レンダーですね。レンダーメソッドでJSXなんですけど
レンダーの中のリターンのところでJSXを定義しておいて
フォームタグのonSubmitイコール
先ほどのthis.handleSubmitというのを実行するようにしています。
ラベルのネームコロンのインプットタイプテキストでバーっとやっています。
valueはthis.state.nameですね。
onChangeで先ほど定義したthis.handleChangeというのをセットします。
ラベルタグ閉じといて、ラベルイコールサブミットというボタンタグを
セットしておきますという感じですね。
これまたすごくシンプルなコンポーネントですね。
こうやってプレゼンテーショナルコンポーネントとコンテナコンポーネントを分けるという書き方ですね。
僕が見る限りこれは昔のクラスコンポーネントを定義しているので
ちょっと書き方というか流儀として古い気がしますけどもね。
こういう書き方でももちろん昔の人は全然知っていたし
こういうところで設計をしていたというので
こういう質問をしてこういうのが返ってくるのであれば
確かにシニアエンジニアとしては全然いけるんじゃないかなと思ったりしました。
続いてプレゼンテーショナルコンポーネントとコンテナコンポーネントを分離することで
見た目と動作の懸念とか関心を分離して
コードの理解とかテスト保守性というのを容易にすることができますよというので
こういう質問を投げかけますよと言ってました。
では続いていきましょう。
続いて質問7ですね。
質問7はリアクトアプリケーションでPagination機能を実装する方法というのを説明してみてくださいと。
これはリアクトとか関係なしにフロントエンジニアとして
Paginationどうなのというのを投げかけるのはすごく良い話だなと僕は感じました。
リアクトアプリでPagination機能というのを実装する方法の一つというのを紹介していきます。
データ量と1ページあたりの表示項目数から必要な総ページ数を決定します。
現在のページを追跡するためにコンポーネントにページの状態変位数というのを追加しておきますと。
特定のページのデータというのを取得して
新しいデータでコンポーネント状態を更新する関数というのを流通しますと。
Pagination UIをレンダリングします。
このUIには次のページと前のページに移動するためのボタンと
特定のページを選択するためのドロップダウンというのを含めることもできます。
続いてPagination UI要素にイベントハンドラというのを追加しておいて
適切なページ番号でフェッチ関数を呼び出しますと。
またですね、マテリアルUIなどのUIライブラリを使用することで
もちろんPagination機能というのを構築するための基礎的なコンポーネントを提供して
開発を加速させるよということもできなくはもちろんないです。
そういうUIライブラリに頼ることももちろんできますけど
自前実装するときはさっきの5つのステップというのを
踏んでいけばいいんじゃないのということですね。
それを手続き的に説明してみましょうということですけど。
やっぱPagination機能はですね、割と考えることとか
注意すべきことっていっぱいあったりするんで
これを投げるって確かにいいかもしれないですね。
これちょっと僕も今後の面接の質問項目にちょっと含めてみたくなりました。
では続いて8つ目ですね。
リアクトアプリでのクライアントサイドのルーティングを処理する方法は?
21:00
っていうのが8つ目の質問ですね。
8つ目の質問ですね。
リアクトアプリでのクライアントサイドのルーティング処理する方法は?
っていうところですね。
先ほどがデータフェッチングやったりとかPaginationやったんですが
次はルーティング周りっていうのを聞くんですね。
なるほど。
ということはやっぱCNNエンジニアとしてルーティング周りっていうのは
やっぱり落とし穴があったりするんで
しっかりそこは注意しましょうってことなのかな。
ちょっと本文入ります。
リアクトアプリでのクライアントサイドのルーティング処理をするには
いくつかの方法があります。
ルーティング処理するためのルーターコンポーネントとか
アプリのルートを定義するためのルートコンポーネントの
セットを提供しますと。
そっか。
これはあれですね。
Nextを使わないで
リアクト本体の方だけでいくっていう質問の
内容なのかなと思いますね。
リアクトアプリでのクライアントサイドのルーティング処理するための
リアクトルーターDOMっていうのを使用する例を紹介しておきます。
とりあえずnpmインストールで
リアクトルーターDOMってのを入れておいて
インポートルーター&ルートコンポーネントの
fromリアクトルーターDOMから
とりあえずインポートしておくと。
使うときにルーターっていうタグで
Appコンポーネントをラッピングしておきますと。
使い方はその通りですよね。
こういう書き方するのも
久しく書いてない気がするんであれですけど
確かに昔リアクトだけで書いてるとき
ルーターコンポーネントとルートコンポーネント
書きましたなっていうのが
しみじみ思い出してます。
使い方いくとルートコンポーネントですね。
ルーターではなくルートコンポーネントを使って
ルートを定義していきますと。
そのルートコンポーネントっていうのはルートのパスを指定する
パスプロップとルートがマッチしたときの
レンダリングコンポーネントを指定する
コンポーネントプロップっていうのを
一応受け取っておきますと。
昨今こんな書き方は多分しないと思うし
基本多分皆さんネクストで書くんじゃないかな
と思うんですよね。
大規模なアプリケーションであればあれほど
すごい小さなアプリケーションだったりするんだったら
別にネクストはオーバースペックだったりするので
単純なリアクトだけでやるんだったらそうですけど
ルーティングまで含めるんだったら
もうネクストを入れていいんじゃない
って思ったりはしますけどね。
あとはルートコンポーネントっていうのは
現在のURLがルートのパスと一致する場合に
指定されたコンポーネントと表示しますと。
Exactプロップを使用すると
パスが現在のURLと完全に一致するときだけ
ルートを表示するように指定もできますよと。
またリアクトルータードームの
リンクコンポーネントを使って
アプリ内のルート感を
ナビゲートするリンクを作成することもできます。
ではラスト9個目の質問ですね。
ラスト9個目は
リアクトコンテキストAPIを使用する
メリットについて教えてください。
これもいい問いですね。確かに。
コンテキストAPIっていうのを使うメリット
メリットもついでに喋ってくれたら
嬉しいんですけどね。
リアクトコンテキストAPIっていうのは
親コンポーネントからプロップを使用せずに
今すぐデータを出すための素晴らしい代替手段です。
特に深くネストしたコンポーネント構造を
持っている場合や
ツリーの何階層も下にあるコンポーネントに
データを渡したい場合にももちろん有利です。
リアクトコンテキストAPIを使用する
メリットとしてはいかがでのものがありますので
OK、4つぐらい書かれてますね。
ちょっと1個1個読んでいきましょうか。
1つ目ですね。
1つ目はプロップの穴あけ加工を簡略化と
言い訳されましたね。
24:00
Simplifies Prop Drillingですね。
バケツ入れみたいな話か。
コンテキストAPIを使用すると
複数のレベルのコンポーネントに
プロップを渡す必要がなくなり
コードが読みにくくなったりメンテナンスが
しにくくなったりすることがあります。
というのが1つ目です。
2つ目はコンポーネント間の状態
共有を容易にします。
複数のコンポーネント間で
共有する状態がある場合
コンテキストAPIを使えば
状態を共通の疎線まで
持ち上げなくても簡単に共有することもできます。
こんな感じですね。
ただコンポーネント間の状態を
それぞれのコンポーネント間で
個別にばんばん書き出すと
どうせ状態がカオスになるので
そこまで行くと多分ストアライブラリー
入れる気がしますけどね。
3つ目。パフォーマンスを向上させる。
コンテキストAPIは
コンポーネント間のデータの受け渡しを
リアクトバーチャルドームに依存しないために
プロップを使用するよりも
効率的な処理を行うことができます。
これは大量のデータを渡したり
頻繁に再レンダリングするような場合に特に有効です。
ネストが増えていったりすると
それぞれのコンポーネント間の
レンダリングの計算処理も
一個一個増えていくので
それはそうだよねって感じです。
ラスト4つ目。
コードの再利用率を高める。
同じデータにアクセスする必要がある
コンポーネントがある場合
コンテキストAPIを使用して
そのデータを利用できるようにすることで
アプリの異なる部分でそれらのコンポーネントを
簡単に再利用することができるようになります。
これはもうコンテキストAPIとか
関係なしにそもそものリアクトというか
コンポーネント思想の根本原理が際しますね。
最後結論。
これらの質問によって
採用担当者はあなたのリアクトの経験や
複雑な問題を解決する能力について
よく理解できるはずです。
また採用担当者、CTOその他の
技術幹部はあなたのコミュニケーション能力だったり
問題解決能力、開発に対する
全体的なアプローチも評価することを
忘れてはいけませんよ。
レベルアップコーディングとして
以下のようなリソースがありますので
その辺は見てみてください。
この記事が締められておりました。
ざっくり
9個の質問見ていきましたけど
確かにシニアエンジニアならこの辺は知っておいて
欲しいよねっていうものばかりだったので
いいんですけど
昨今の弊社の新卒エンジニアでも
この辺の質問がバンバンに答えてくる
気がするので、そういう意味でいくとやっぱり
うちのエンジニアでレベル高いんじゃないか
って思ったりしますけどね。
やっぱり真っ先に聞かれた質問が
個人的には面白かったですね。
パフォーマンスから入るっていうところがやっぱりそうだったんだ
っていうので
リアクトを使うメリットの大きな一つとして
やっぱりパフォーマンス周りっていうのが大きいんだろうな
と思いました。そこをやっぱり細かく制御できたり
コントローラブルにかけるっていうのが
リアクトの本当の強みなんだろうなっていうので
やっぱり職人
芸というか
リアクト職人を作りたいというわけでは
もちろんないんですけどやっぱりちゃんと
エンジニアとして腕を
フルに使えるっていう意味でも
リアクトはそこに耐えうるっていう
特徴を教えるんだろうなっていうのはすごく感じましたね。
あとはやっぱり
パフォーマンスの次に段々と来たのが
やっぱり状態管理どうしてますかっていう質問が
27:00
確か2つ連続で来たので
ここの途中2つの質問にやっぱり状態管理周り
っていうところを問うのが
やっぱり
ウェブアプリケーションとか
システムってそうなんですけどやっぱりデータとか
状態をどう管理してどう表示するか
っていうアルゴリズムですね。データと
アルゴリズムっていう2点がやっぱり
エンジニアとしての本質なんだろうな
っていうのはすごく感じましたね。
あとはテストを使うのはどうしますかとか
非同期処理はどうしますかとか
この辺はわりと具体的なところに
どんどん入っていくので
この辺はリアクト書いていれば皆さんこの辺できるよね
っていう感じはするので
だからそれは改めて問うてるんですけど
この辺をシニアかどうかっていうのはちょっと難しい気がしましたね。
回答レベルによってはシニアだな
っていう評価になるかもしれないですけど
1つ質問事項として
こんな質問してますよっていうのは
すごく参考になったので
ぜひ見てみてください。
自分の今後のキャリアアップであったりとか
今の自分がどれくらいリアクトを書けるエンジニアとして
レベルがどの段階にあるかっていうのを
評価する。自己評価のための質問として
使うのも全然いいのかなと思いますので
とても参考だったと思うので
ぜひぜひ見ていただければと思います。
長くなりましたけど
今日の朝活はこちらで以上にしたいと思います。
改めまして今日はアレンさんですね
ご参加いただきありがとうございました。
また明日もゆるゆると記事を読んでいきたいと思いますので
ご参加いただけば幸いです。
じゃあ日曜日ですね。
今日もゆっくり休んでいただければなと思います。
終了します。お疲れ様でした。
