React.memoを適用すれば、コンポーネントの不要な ReRender を防ぐことができます。しかしながら、Provider 設計・バケツリレーの見直しを行うことで、React.memoを使わずとも、ReRender の抑止は可能です。 最適な Context Provider 設計とすることで、React.memo使用によるオーバーヘッド削減が期待できます。そして「過剰な Provider 分割も場合によっては不要」ということを解説していきます。 3つのパターン サンプルリポジトリを用意しました。(Next.jsで作っていますが、特に意味はありません)「+1」押下でカウントアップし「input text」入力で、入力内容が更新される簡単なサンプルです。 こちらでは、以下3つのパターンが用意されています。ReRender されている様子は console.log 出力のほか、React
こんにちは、フロントエンド技術顧問の @koba04 です。 今回は React v17 での変更に対して気になった部分や、RC からリリースまでにあった修正の中で個人的に興味深いと思った話を紹介したいと思います。 v17 自体の変更点については下記で紹介している公式ブログで確認することをオススメします。 React v17.0 (日本語ブログ) React v17.0 Release Candidate: No New Features (日本語ブログ) SmartHR では毎週フロントエンド MTG を行っており、今回紹介するような内容はこの MTG で取り上げています。 SmartHR での フロントエンド MTG のようなプロダクト開発以外の活動に興味のある方は下記のブログ記事を参照ください。 tech.smarthr.jp Changes to Event Delegation
はじめに 「Typescriptの次はRustかもしれない」という記事がバズってるのを見かけました。 なかなか面白くて、PAとしてのWASMとRustを比較している記事です。ちょうど最近「レガシーおじさん、SPAを始めてみた。そして限界を知る」でも書いた通り最近SPAに手を出してみたのですが、いろいろやろうとするとSSRのためのBackend for Frontend (BFF)等が必要になるとわかり「これJSでやる必要なくない?」とも感じていたのでちょうど良かったです。 こういうのを見るとRIAやGWTのように似たアプローチで廃れた技術や、登場が早すぎたMeteor、今も頑張ってるMSのBlazorなど色々頭をよぎります。といわけで歴史を俯瞰する意味でHTML + JavaScriptとそれ以外の技術のせめぎ合いの歴史やMSのBlazorやRustのyewなどWebassemblyを使う
現在私は barista という OpenID Connect と OAuth2.0 に準拠したID製品の実装を行っています。 また、私の所属する事業開発部では prismatix というEC、CRM の API 製品の開発を行っていますが、この prismatix の認可サーバーとして barista を利用しています。 barista チームの増員や、prismatix の認可についての理解を促進するため OAuth 2.0 をある程度しっかりと理解しているメンバーを増やしたかったので、勉強会を開催しました。 勉強会の内容 概要 雰囲気でOAuth2.0を使っているエンジニアがOAuth2.0を整理して、手を動かしながら学べる本を全員で輪読 OIDC 編はこのあとやる予定 攻撃編もやりたい RFC 読んだりもしたい 参加者全員が以下を満たすことが目標 OAuth 2.0 の意図を理解
この記事は新野淳一氏のブログ「Publickey」に掲載された「Docker Hub、6カ月使われていないコンテナイメージの削除計画を保留に。従量課金ベースの料金プランを検討へ」(2020年10月29日掲載)を、ITmedia NEWS編集部で一部編集し、転載したものです。 米Dockerはこのほど、8月に発表していた、Docker Hubの無料プランで6カ月以上使われていないコンテナイメージを削除する計画を保留すると発表しました。計画では11月1日から、該当するコンテナイメージの削除を行う予定でした。 Dockerコンテナのコンテナイメージを保存できるパブリックなレジストリ「Docker Hub」は、無料プランのユーザーであっても期限なくコンテナイメージの保存が可能でした。 しかし今年8月、DockerはDocker Hubが保存しているコンテナイメージの容量が15ペタバイトに達している
Linux 5.11 To Land Optimization That Helps IO_uring Performance Written by Michael Larabel in Linux Kernel on 30 October 2020 at 12:05 AM EDT. 16 Comments At the start of October we mentioned a kernel optimization that can help IO_uring performance. Now as we approach the end of the month, Linux 5.11 is poised to land the optimization that especially helps out with threaded workloads. The change t
「コンテナーがいっぱい」と聞くと、なんだか港の風景を思い出してしまうが、Windowsにもコンテナーが複数ある。コンテナーとは、アプリケーションの独立した実行環境とそこで動作するソフトウェアや設定などをファイル化して実行させるもの。あらかじめコンテナーを作っておけば、あとはそれを組み合わせてシステムを構築できるわけだ。 仮想マシン環境に似ているが、コンテナー自体にはOSは含まれないし、必ずしも仮想マシン支援機能を前提としているためでもない。そもそもコンテナーが普及した1つの理由は、仮想マシンにつきもののオーバーヘッドや長い起動時間、大量のメモリー消費といった問題がないため。コンテナーは、特定のハードウェアに縛られることなく実行でき、システムを複数のコンテナーで構築することも可能であり、このとき仮想マシンに比べて実行オーバーヘッドの低いコンテナーは魅力的だったのだ Windows 10Xには
CloudFormation Guard を使うことで、CloudFormation をデプロイ前にコンプライアンスチェックでき、より安全なデプロイをできるようになります。 CloudFormation テンプレート(以下、CFn テンプレート)が、ポリシーガイドラインに準拠しているか確認できるコマンドラインツールとして、CloudFormation Guard (以下、CFn Guard)が公開されました。 CFn Guard は、2020年10月1日から一般提供されています。 これまで、Security Hub のセキュリティ標準や Config 適合パックを用いて、AWS環境がコンプライアンスに準拠しているか調べられます。 CFn Guard では、CFnテンプレートが定義したルールを満たしているかをチェックでき、デプロイする前にコンプライアンスに準拠しているかチェックできます。 デ
みなさん,研究プロジェクトをどう管理していますか? データ解析のコードをどう管理していますか? わたしは生物統計家として,さまざまな研究プロジェクトに関わらせていただいてます. 以前はプロジェクトごとに,その場その場でドキュメントやコードを管理していて,分からなくなることもよくありました.このような経験から,少しずつプロジェクト管理の標準化を図ってきました. 最近落ち着いた気もするので,まとめようと思います.(あくまで,医学研究の,かつデータ解析に特化した管理方法です) プロジェクトフォルダ構成 研究プロジェクトごとに,フォルダの構成がバラバラだと,後で振り返った時に昔の自分を罵りたくなりますね.そうならないために,今の私のフォルダは次のようになっています. Documentフォルダ Projectに関連する資料はここに格納します.論文関係ならば「papers」というようなサブフォルダを作
React コンポーネントのDOM構造を自動テスティングをするとしたら、スナップショットテストするのが一般的です。 スナップショットテストは、構造に変化があれば警告するという仕組みであり、その中身はあまり意識しません。 ところが、特定の事情により、どうしてもDOM構造そのものを保証しなければいけない事例のときには、DOM構造をユニットテストしたくなるんですが、そういうことをやってる事例を見つけられなかったので、記事にしました。 スナップショットテスト さて、本題のテストを記述する前に React コンポーネントのスナップショットテストのおさらいです。 import React from 'react' import { create } from 'react-test-renderer' test('hoge-', () => { const tree = create(<div>ほげー
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く