logo
/
Reactの技術質問の想定
2022-10-06

一覧

これはReactに限ったことではないが定期的にReactの公式を見直して、Reactの思想からずれていないかを確認する。

Component設計はどのように意識していますか?

atomic designは実態を反映していないので自分では採用しない。
  • 分割境界が曖昧なこと
  • 再利用しないものまで無駄に細分化される
  • 人間が理解しにくい
    機能単位で分割している

CSSはなにを選定しますか?また好みはなんですか?

少し前は、NextJsのビルトインなのでCSS Modulesを推奨していた。
PureなSCSSと変わらないので足かせになりにくい。
最近はCSSとJSを分けることは技術的な分割に過ぎないと感じているので、コンポーネント内部に関心事をまとめられるCSSinJSを推奨している。その中でも癖がなくシェアも大きいのでEmotionを推奨する。

Jamstackとは何か説明してください

JavaScript, api, Markupからとっている由来
Next.jsのSGなどの機能を使って、JavaScriptとApiを使ってサーバーレスでフロントエンドに集中して実装することができる等がメリット
パフォーマンスとセキュリティの観点から見ても良い。
ブログ等のリアルタイム性が求められないプロダクトに向いている、チャット等のリアルタイムせいが必要なアプリケーションには向いていない

Next.jsを使うメリットとデメリットは?

メリット ... ルーターやwebpack等Next.jsがいい感じに行ってくれるので、その辺を考えずに実装できる。ssrやsgの実装が容易 デメリット ... サーバーサイド側も考慮しなければいけないので、Reactでは出ないエラーが出たり、Reactでは動くライブラリーがエラーになるようなこともある。(cookieとかlocalStorage周りとか)。React自体のバージョンが追随しないこともある。

ossのバグを見つけプルリクを投げたりした経験はありますか?

ちいさいやつですがあります。
最近はReactDocumentのレイアウトが崩れていたので修正しました。

React hooksのメリットについて説明してください

  • 関数コンポーネントで状態を管理できるようになったので、class componentの複雑な記述を減らせる。
  • カスタムフックを使用し、viewとロジックを分離しやすくなった
  • 機能に基づいて、1 つのコンポーネントを複数の小さな関数に分割できる

Recoilはどのようにstateを管理しているか説明してください

  • Atomとselectorという概念があり、Atomで状態を管理する。
  • component内からはどこからでもAtomにアクセスすることができるのでglobalに状態を管理できる。
  • SelectorはAtomを元に新たな状態を作ったりすることができる

Reduxはどのようにstateを管理しているか説明してください

  • ユーザーがイベントを発生させるとactionを作成する。
  • actionをdispatch(送信)しReducerが受け取ったactionと現在のstateの状態を見て、store内のstateを更新している

SSR, SGに関して使用したことはありますか?

ある。ブログやナレッジ形式のサイトは、headlessCMSや単純なMarkdownでコンテンツを管理して、ビルド時にページを作成している。
ある程度リアルテイム性が欲しいかつ、OGPが必要なものはSSRを使用している

TypeScriptを使用するにあたって意識していることはなんですか?

  • anyやts-ignoreなど逃げ道は使わない。
  • 型パズルをしそうになったら、データ設計自体を見直す。
  • 関数は型を書いてからロジックを実装する(ミニマムなTDD)

useContextに関してどのように考えていますか?

  • 依存ライブラリを増やしたくないときは特に使用して支障はないと思う。
  • 基本は状態管理ライブラリーを入れた方が楽に管理が出来ると感じる。
  • stateを単体で共有するという意味ではが、Recoilと近いが、Recoilはdispatcherのみコンポーネントに取り込めるので不要な再レンダリングを抑制できる。

useEffectを使う際に注意しなければいけないことをできるだけ多く教えてください

  • 依存配列に追加したstateを内部で更新して、無限ループが起きないようにする
  • 開発環境では発見しやすいが、クリーンアップの処理を忘れないようにする
  • useEffectはあくまでレンダリング後に実行される副作用なので、そもそもEffectを使う必要がある化考える
  • ビューコンポーネントには生のuseEffectはできるだけ登場しないようにする(カスタムフックに包む)

useRefの値をuseEffectの配列に入れるとどうなる?

RefObjectはImutableで、CurrentプロパティがMutableなので何も起きない。

アクセシビリティに関して意識していることはありますか?

  • まずは基本的な適切なタグを使う、スクリーンリーダを使うと見出しの部分は目次等にしてくれるものもあるのでそのあたりも意識する
  • divなどの汎用タグを使う場合は、roleやarealavelを使用する
  • 曖昧な表現だが驚きのあるUIは採用しない(基本に忠実に)
  • あとはESLintが指摘してくれる部分は無視せずしたがう

サイトの表示速度が遅いときどうしますか?

まずはボトルネックを探す
  • 不要なレンダリングが起きているのか?
  • SQLのパフォーマンスが悪いのか?
  • そもそもapi設計が悪いのか?
  • フロント側かバック側か

バックエンドの開発はできますか?

基本的なapiの実装はできます。
複雑なDB設計やインフラ、認証などを担うのは難しいです。

パフォーマンスの観点で気をつけていることはなんですか?

  • memoやuseCallback等のキャッシュを使用する
  • 無駄なfetchが行われていないか
  • そもそものapi設計部分
  • logを仕込んで再レンダリング等を確認

フロントエンド設計に関して意識していることはありますか?

  • ビューとロジックでも、ロジック内部でも責務を分割すること。
  • 構造をスタイリングで補おうとしないこと。
  • URL設計をおろそかにしないこと。
  • 状態をどこが持つかをしっかり決めること。

再レンダリングが起きる条件を教えてください

  • propsが更新されたとき
  • stateが更新されたとき
  • 親componentが再レンダリングされたとき

普段apiでデータを取得する際どのように取得していますか?

  • SWRやReact Queryでキャッシュを利用している
  • loadingなどstateを定義してuseEffectで実装することもある

参考