タグ

2022年5月26日のブックマーク (5件)

  • スコープとライフタイムで考えるReact State再考

    ReactはじめSPAのStateは大きく2種類、Local State・Global Stateの2種類でおおよそのStateの分類が可能であると考えていました。これに対し会社の先輩から意見をもらって、以下2点に気づきました。 Global Stateには大きく、Client StateとServer Stateの2つがある Stateにはライフタイム(生存期間)が存在し、Client Stateにはスコープ的Globalと時間的Globalの2つが含まれている これらを意識すると、自分はStateの実装を結構感覚的にやってしまっていたなと気づいたので、Stateの分類について改めてまとめてみようと思います。Reactで何かしらのStateを実装する時に、稿の分類が実装の参考になれば幸いです。 スコープによるStateの分類 まずこれまで自分が認識してたスコープにおけるStateの分類

    スコープとライフタイムで考えるReact State再考
  • a11yとテストを同時に改善する話

    これまで、a11y 改善・テスト拡充にあたり「どのように改善すべきか?どのように書くべきか?」という点がハードルだと感じていました。Chrome で a11y tree を確認するには、dev tools の隅の隅をつつく必要があり、あまり体験の良いものではなく、気に入ったエクステンションもありませんでした。 Testing Library は「誰もがアクセスできるクエリー」を優先的に使用することを推奨していますが、アプリケーションがはじめから a11y に考慮された作りになっているとは限りません。これらの背景から「data-testid」のような、テスト向け属性に頼るワークアラウンドで乗り切ることも少なくありませんでした。 Full page accessibility tree 今年 1 月にリリースされたChrome98 の新機能として「Full page accessibility

    a11yとテストを同時に改善する話
  • React テスト応用、テストに悩む人へ

    2022-05-06 更新 「React でコンポーネントテストを書くといいらしい、 React Testing Library や jest でサンプルを参考に書いてみたが 現実どうやってプロダクトコードに合わせていけばいいか分からない」 そういった方が対象となるを目指しています。 いろいろ調べて実践したものの下記のように感じた方に適しているかもしれません。 - 結局テストで何を担保しようとしているか分からない - React のテストでハマっているか、Jest でハマっているか分からない - モックとかスパイとかアプリケーションとは遠い出来事も多くてピンとこない 誤り・ご指摘あればフィードバックいただけると嬉しいです。 無料で配布していますが、気に入ったらサポートなどいただけると今後もこのをアップデートし拡張していく気持ちになれるのでよろしくお願いします。

    React テスト応用、テストに悩む人へ
  • 独自フックの作成 – React

    新しい React ドキュメントをお試しください。 以下の新しいドキュメントで最新の React の使い方がライブサンプル付きで学べます。 Reusing Logic with Custom Hooks まもなく新しいドキュメントがリリースされ、このページはアーカイブされる予定です。フィードバックを送る フック (hook) は React 16.8 で追加された新機能です。state などの React の機能を、クラスを書かずに使えるようになります。 自分独自のフックを作成することで、コンポーネントからロジックを抽出して再利用可能な関数を作ることが可能です。 以下のコンポーネントは副作用フックの使い方について学んだ際に見たチャットアプリのコンポーネントであり、フレンドがオンラインかオフラインかを示すメッセージを表示します。 import React, { useState, useEf

    独自フックの作成 – React
  • 消す前提で機能を作ろう

    どうも、株式会社プラハCEOの松原です 先日プラハチャレンジの参加者と雑談していた際に 消す前提で機能を作ると保守性が上がるかもしれない という内容に触れたので、思ったことを記事にまとめてみました。 企画には必ず切り戻し条件を明示する 少し話が脱線しますが、僕はエンジニアになる前はWEBサービスの新規事業企画を担当していて、当時所属していたチームではサービスに追加機能を立案するときは 何が起きたらこの機能を削除するのか という「切り戻し条件」がセットで求められていました。 例えば求人サイトの応募を増やしたいな〜と考えて新機能を立案するとしたら、こんな感じ: 機能概要:スマホ閲覧者にはフッターに応募ボタンを表示する 切り戻し条件:実験的に追加した画面の求人応募率が逆に5%低下したらフッターを削除する 機能を追加しているとき自分はサービスを改善しているように感じがちですが、正確には機能を追加す

    消す前提で機能を作ろう