Components (experimental) | Playwright
test('event should work', async ({ mount }) => { let clicked = false; // Mount a component. Returns locator pointing to the component. const component = await mount( <Button title="Submit" onClick={() => { clicked = true }}></Button> ); // As with any Playwright test, assert locator text. await expect(component).toContainText('Submit'); // Perform locator click. This will trigger the event. await
Reactで実装したフォームのパフォーマンスが問題になるのはなぜか
RelayHub合同会社の久保田光則です。 Reactでフォームを効率よく実装するためのライブラリとして、React Hook FormやReact Final Form、TanStack Formなどがあります。これらのライブラリは、フォームを効率よく実装できる枠組みを提供してくれるだけではなく、高速なフォームを実装するための方法も提供してくれます。 で、この記事ではReact Hook Formとかそういうライブラリの使い方というよりかは、そもそもなぜReactで実装したフォームのパフォーマンスが問題になりやすいのか、その辺りの事情について解説します。 Reactのレンダリングの仕組み Reactでは皆さんご存知のとおり、仮想DOMと呼ばれるDOMに似た構造のオブジェクトを生成してレンダリングを行います。Reactのコンポーネントはレンダリングするたびにそのコンポーネントに対応する仮想
[Twitter] React ユーザーが Vue を選ばない理由
概要 本記事は、 Vue.js コアチームメンバーである @antfu7 氏の以下ツイートに対する回答を個人的にまとめたものです。 React ユーザーの皆さん、 好奇心で聞くのですが、Vue を使ったり試したりするのを妨げているブロッカーや欠点は何ですか？ 注意事項 対立煽りっぽいタイトルにはなっていますが、個人的な好奇心がモチベーションとなっており、特定の技術を贔屓、批判する意図はありません。 私自身は長らく Vue を愛用しており、業務でも大規模 Vue アプリのメンテに携わっている一方で、React は小規模プロジェクトや個人開発でしか利用していません。そのため、理解度に差がある状態であるため、改めて Vue と React の対比やそれぞれの良さを実感したいと思い、一通りのツイートに目を通した次第です。 また、 Vue.js の生みの親である Evan You氏が以下のようにツイ
![[Twitter] React ユーザーが Vue を選ばない理由](https://cdn-ak-scissors.b.st-hatena.com/image/square/050cb810e4b79fc48a4bc3fe8753540d585f1720/height=288;version=1;width=512/https%3A%2F%2Fres.cloudinary.com%2Fzenn%2Fimage%2Fupload%2Fs--QTloU7Jr--%2Fc_fit%252Cg_north_west%252Cl_text%3Anotosansjp-medium.otf_55%3A%25255BTwitter%25255D%252520React%252520%2525E3%252583%2525A6%2525E3%252583%2525BC%2525E3%252582%2525B6%2525E3%252583%2525BC%2525E3%252581%25258C%252520Vue%252520%2525E3%252582%252592%2525E9%252581%2525B8%2525E3%252581%2525B0%2525E3%252581%2525AA%2525E3%252581%252584%2525E7%252590%252586%2525E7%252594%2525B1%252Cw_1010%252Cx_90%252Cy_100%2Fg_south_west%252Cl_text%3Anotosansjp-medium.otf_37%3Ashingo.sasaki%252Cx_203%252Cy_121%2Fg_south_west%252Ch_90%252Cl_fetch%3AaHR0cHM6Ly9zdG9yYWdlLmdvb2dsZWFwaXMuY29tL3plbm4tdXNlci11cGxvYWQvYXZhdGFyLzg0NWZhNzViYTguanBlZw%3D%3D%252Cr_max%252Cw_90%252Cx_87%252Cy_95%2Fv1627283836%2Fdefault%2Fog-base-w1200-v2.png)
You Might Not Need an Effect – React
Effects are an escape hatch from the React paradigm. They let you “step outside” of React and synchronize your components with some external system like a non-React widget, network, or the browser DOM. If there is no external system involved (for example, if you want to update a component’s state when some props or state change), you shouldn’t need an Effect. Removing unnecessary Effects will make
丁寧なDeno+JSX - laiso
*1 サーバーレスFunctionsぐらいの気軽さでサーバーアリのWebアプリをデプロイしたいという時がある。主に自分たちだけが使うようなツール系のやつ。 その時に今までのようにSPA+APIアーキテクチャではなく、モノリシックなサーバーサイドアーキテクチャにしつつもフロントエンド開発と同じツールチェインを使いたい、と前から思っていた。 これは単にReactメタフレームワークでも一気通貫に時短で作れそうだけど、個人の楽しみのための活動なので、一旦世間のトレンドからは離れて自分が本当に必要だと思った要素技術のみを最小限に使って理解しながら試行錯誤したい。 ※ただ第三者に提供するシステムとかは安全に作られた既存フレームワークに乗るのがいいというのもある しばらく考えてみたところ、私にとっては「TypeScriptでJSXをテンプレートエンジンに使ってHTMLを書けるだけでよい」という所に落ち着
React、過剰に複雑な代物。 - Qiita
はいさい！ちゅらデータぬオースティンやいびーん！ 今回の記事は筆者に珍しく、技術紹介ではなく、僕の個人的な意見を書きます。あくまでも、自説です。 React自体は画期的で、プログラミング界に貢献したプロジェクトだと思っていますし、完全に否定したいわけではありません。 Reactに対する違和感＝芽生えては大きく育った種 筆者はReactがとても好きでした。JavaScriptが好きになったきっかけもReactでした。何から何までもReactで書き直して、Custom Hooksを作って、refを子部品に渡したり、バリバリ満喫していました。 Vueも仕事の関係で習得せざるを得なくなったのですが、Vueは最高に大嫌いでした。これならReactで書き直してやるぅ！と思ったりも。 Reactについて社内でも導入を推進したり、React入門の勉強会を開いたりもしています。 しかし、そんな筆者は、最近に
ReactのコンポーネントからStorybookのファイルを自動生成してみた
はじめに フロントエンドのプロジェクトでは、UIコンポーネントのカタログとしてStorybookが用いられるケースがあると思います。 StorybookはコンポーネントベースのUI開発の助けとなるツールで、Reactのコンポーネントを独立して視覚的に確認できます。 しかしながら繁忙時や規模の大きいプロジェクトになると、メンバーの増減や開発工数等でStorybookの開発コストが高く感じられる状況があると思います。 そこで本記事では、なるべくStorybookの開発コストを軽減して、Storybookのファイルを自動生成する仕組みを考案してみました。 Storybookとは Storybookは、UIコンポーネントを独立して開発・表示するためのツールです。 React, Vue, Angularなど、様々なフレームワークに対応しており、各コンポーネントの異なる状態やバリエーションを一覧で見る
styled-components: API Reference
CSS for the <Component> AgeStyling your way with speed, strong typing, and flexibility. const Button = styled.a<{ $primary?: boolean; }>` --accent-color: white; /* This renders the buttons above... Edit me! */ background: transparent; border-radius: 3px; border: 1px solid var(--accent-color); color: var(--accent-color); display: inline-block; margin: 0.5rem 1rem; padding: 0.5rem 0; transition: all
最小限のコードで動く最も汚いコードから始める
最小限のコードで動く最も汚いコードから始める 2023.09.02 コードを書く際の重要な要点は、読みやすく他人に理解される「良いコード」を書くことです。しかし、完璧を目指して最初から書こうとすると行き詰まります。代わりに、荒削りながらも動くコードを作成し、徐々にリファクタリングして完成度を高めます。型エラーやリントエラーを無視しても構わないので、まずは動くものを作成しましょう。それからリファクタリングして「良いコード」を作成できます。 コードを書くときに最も大切なことってなんだろう？聡明な読者諸君ならご存知だろうが、コードは書く時間よりも読む時間のほうが長い。だから他人に読まれることを意識して、読みやすい「良いコード」を書かなくっちゃならない。コンポーネントは適切な粒度で分割されていて、適切な名前がつけられている。型システムに安全性だって守られてるし、最新のなんとかアーキテクチャにも準拠
日経電子版での自作 SSR フレームワーク基盤について — HACK The Nikkei
こんにちは、Web チームの井手です。今日は私たち Web チームが作っている SSR フレームワーク(以下 FW)にについて紹介します。 記事を書くモチベーション 私たちのメインプロダクトである日経電子版においては k2 という自作 SSR 基盤を 2020 年から運用しています。SSR FW といえば多くの方が Next.js を想起すると思いますが、私たちは自作しています。一方で最近は Next.js の進化が凄まじく、自作 SSR 勢としても意識せざるを得なくなっています。もしかしたら「あぁ Next.js で作っておけばよかった」と思う時が来るかもしれません。特に k2 を保守する際には Next.js では実現できない機能を実現するために様々な手法や工夫を編み出していましたが、Next.js の進化に伴ってその必要性はだんだん減ってきているのを実感しています。そのためいつか N
フロントエンドをViteからNext.jsに書き換えた話 〜パフォーマンス編〜 - 株式会社ヘンリー エンジニアブログ
こんにちは。4月にヘンリーに入社したSWE / アーキテクト / SETのsumirenです。 弊社ではレセコン一体型クラウド電子カルテの Henry を開発・提供しています。 今回、HenryのフロントエンドをReact + ViteからNext.jsに書き換えました。 この記事では、最初にNext.jsへの切り替えによってもたらされたユーザー体験の向上について説明します。次に、このユーザー体験の向上がどうして生じたのか、その背後にある技術的な要素をエンジニア向けに詳細に解説します。最後に、フロントエンドアーキテクチャに対する我々の長期的なビジョンについて述べます。 対象読者 Next.js導入によるユーザー体験向上 デモ 定量的なパフォーマンス比較 ユーザー体験がどう向上したか FCP高速化の技術的な仕組み Next.jsとViteの基本的なアーキテクチャの違い 補足：工夫しているポイ
ブラウザー上でReactやTypeScriptのコードをコンパイルして動かすツールを作った
通常、ReactやTypeScriptを使って開発する場合は、ローカル環境で開発して、ビルドして、ブラウザーで表示するという流れになります。 ただ、昨今のブラウザーの性能はかなり高くなっており、ES Modulesをうまく使うことで、ノーバンドルでReactやTypeScriptをリアルタイムにブラウザー上で反映させることができるのではないかと考えました。 この案をもとに、何番煎じかわかりませんが、ブラウザー上でリアルタイムにReactやTypeScriptをバンドルするライブラリを作成しました。 以下のようにコードを書くだけで、ブラウザーで実行可能なJavaScriptコードが生成されます。 import { browserBundle } from "browser-bundler"; const code = ` import React from "react"; import R
Reactベストプラクティスの宝庫！「bulletproof-react」が勉強になりすぎる件
Reactアプリケーションのアーキテクチャの一例として公開されているGitHubリポジトリ「bulletproof-react」が大変勉強になるので、私自身の見解を交えつつシェアします。 ※2022年11月追記 記事リリースから1年ほど経過して、新しく出てきた情報や考え方を盛り込んだ続編記事を書いていただいているので、こちらも併せて読んでいただければと想います（@t_keshiさんありがとうございます！）。 ディレクトリ構造が勉強になる まずはプロジェクトごとにバラつきがちなディレクトリ構造について。 ソースコードはsrc以下に入れる bulletproof-reactでは、Reactに関するソースコードはsrcディレクトリ以下に格納されています。逆に言えば、ルートディレクトリにcomponentsやutilsといったディレクトリはありません。 たとえばCreate Next Appで作成
その処理、 setInterval じゃなくてブラウザが暇な時にやっちゃえば？
こんにちは。ぬこすけです。 setInterval などで定期的にブラウザで実行させている処理があったりするでしょう。 例えば、定期的にアクセストークンが有効かチェックし、無効だったら新しいトークンを取得するなど。 ブラウザはページのコンテンツを表示するために JavaScript の実行や UI の更新で忙しいです。 もし定期実行している処理がコンテンツ表示にかかわらない優先度の低い処理なのであれば、 できるだけブラウザの重要なタスクに影響を与えないようにしたい ものです。 この記事では できるだけブラウザの重要なタスクに影響を与えずに定期的に処理を実行させる方法を、アクセストークンのローテーションを例に紹介 します。 実装する機能 この記事で実装する機能は次の通りです。 React の hooks を使って実装します。 ブラウザのアイドル中(暇なとき)にアクセストークンを有効かチェック
りあクト！ TypeScriptで始めるつらくないReact開発 第4版【① 言語・環境編】 - くるみ割り書房 ft. React - BOOTH
💡 3.1版から 4版への変更点については以下の記事をご参照ください https://klemiwary.com/blog/riakuto-4ed-release ―――― シリーズ累計 2.5 万部を突破、BOOTH 技術書カテゴリで上位独占中の『りあクト！ TypeScriptで始めるつらくないReact開発』の最新 4 版。今版は全 3 巻構成となっており、本書はその第 1 巻「言語・環境編」です。 最新のフロントエンド環境構築ツール Vite の使い方に始まり、JavaScript（ES2022）、関数型プログラミング、TypeScript までをカバー。JS のパワーをフル活用する React を使いこなすための基礎力を固めます。 「フロントエンドの開発になぜ Node.js が必要なの？」「使っている各種のツールは何をしてくれてるの？」「import はどうやってファイルを読
【React】「困難は分割せよ」―― 複雑な画面は小さな機能に分けて実装しよう。 - Qiita
「Divide and Conquer / 分割統治法」 という解法（アルゴリズムの話でよく出てきますね）は、「困難は分割せよ」 として知られる、デカルトが『方法序説』で提唱した思考法が元になっています1。 第二は、わたしが検討する難問の一つ一つを、できるだけ多くの、しかも問題をよりよく解くために必要なだけの小部分に分割すること。 ―― 岩波文庫 『方法序説』 デカルト著 谷川多佳子訳 同様に、React で多機能で複雑な画面を作りたい時、それを小さな機能の集まりと捉えて、それぞれをコンポーネントにすることで、開発がラクになることがあります。 フロントエンドの複雑さや、デザインのための Atomic Design という考え方の影響、または /scripts のように分ける習慣の名残なのか、フロントエンド開発者には、《再利用のためにコンポーネントを作る》という思い込みがあります。（もしくは
microCMSのWebフロントエンドにクリーンアーキテクチャを採用した話【後編】
はじめに こんにちは、森茂です。 先日公開したmicroCMSのWebフロントエンドにクリーンアーキテクチャを採用した話【前編】に引き続き、今回は後編として前編で紹介させていただいた構成にあわせて、実際にどのような実装とチームへの浸透を行っていったかについて紹介いたします。 なお、記事内に記載している仕様、ソースコードは説明用として省略や変更、部分的な引用を行っています、実際のサービスとは異なる箇所もある点をあらかじめご了承ください。 前編より 前編ではmicroCMSのフロントエンドアーキテクチャをどういった背景、構成で採用したかを紹介しました。実装の段階に進むにあたっては、その中でもとくに責務（関心）の分離と負担なく開発を進めことができるかを意識することにしました。 また、前編でも紹介の通り、クリーンアーキテクチャという概念に振り回されないことも重要と考えています。完璧な設計を求めるこ
OSSライセンスについて
皆さんは開発される際に、外部ライブラリを使われることはありませんか？ 世の中にはたくさんの便利なライブラリがあり、使うことでコーディングは楽になり、見た目もきれいになったりして、いいことずくめですよね。 ですが、ちょっと待ってください。 そのライブラリのライセンス、ちゃんと理解して使っていますか？ きちんと理解しないまま使うと、思わぬところで訴訟問題に発展することもあります。 この記事では、そういったリスクを避けるための正しいライセンスの守り方について説明します。 まずは、コードと著作権の関係からみていきましょう。 世の中にある「コード」は法律上「著作物」と扱われるため、「著作権法」が適用されます。 したがって、他の人の著作物を無断に利用した場合は、著作権法違反（著作権侵害）になってしまいます。 それを避けるためには、しっかりとライセンス（利用許諾）を守って利用しましょう。 万が一ライセン
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
React
React
