王道か邪道か？ タイムスタンプによるステート管理
Reactによるステート管理では、ある状態が変化したら付随して他の状態も変化してほしい場合があります。例えば、次のような場合を考えます。 チェックボックスが1つある。 チェックボックスの初期状態は、HTTP APIから取得したデータによって決まる。 ユーザーはチェックボックスを操作できる。 APIからデータを再取得する場合があり、その場合はチェックボックスの状態が再取得されたデータに従ってリセットされる。 皆さんは、このような要件をどのように実装するでしょうか。 やりがちな実装 まず、やりがちな実装を見てみましょう。 const apiData = useApiData(); const [isChecked, setIsChecked] = useState(false); useEffect(() => { setIsChecked(apiData.isChecked); }, [ap
React のカスタムフックの利点をオブジェクト指向の観点で考えてみる
こんにちは。ぶっちーです。 普段は kintone というプロダクトの新機能開発を行っており、最近は、フロントエンドの技術刷新に取り組んでいます。 この技術刷新では、Closure Tools から React への置き換えを行っています。詳しくは、以下の記事をご覧ください。 刷新をする中で、React を書いていくうちに React の設計、特に React Hooks に対する考え方が難しいと感じました。 そこで、React Hooks について学習し、気付いた点があったのでこの記事にまとめます。 命令的 UI と宣言的 UI 技術刷新前の Closure Tools は、class 構文を使用したオブジェクト指向をベースとして、命令的 UI を構築しています。 刷新をする中で、最終的にどのような UI を構築するのかを把握する必要があります。このときに、コードベースから理解をしようと
React / Remix への依存を最小にするフロントエンド設計 - 一休.com Developers Blog
CTO 室の恩田(@takashi_onda)です。 一休レストランのフロントエンドアーキテクトを担当しています。 Intro 一休レストランでは、以前ご紹介したようにフロントエンドで React / Remix を利用しています。 user-first.ikyu.co.jp 一方、設計方針としては、React / Remix への依存が最小になるように心掛けています。 今日は、そんな一見矛盾するような設計方針について、ご紹介したいと思います。 この記事を読んでいただき Remix に興味をもたれたら、明後日 2024/8/7(水) 19:00〜 のオンラインイベント offers-jp.connpass.com にもご参加いただけると嬉しいです。 この記事でご紹介している疎結合なフロントエンドアーキテクチャを実現する Remix の魅力についてお話します。 なぜ依存を最小にするのか？ R
ほぼJSなしで完璧なReactフォームをつくる
import { ChangeEvent, FormEvent } from "react"; export default function Form() { const showError = (message: string) => (e: FormEvent<HTMLInputElement>) => { if (e.currentTarget.validity.valueMissing) { e.currentTarget.setCustomValidity(message); } else if ( e.currentTarget.validity.patternMismatch && e.currentTarget.name === "postcode" ) { e.currentTarget.setCustomValidity("郵便番号正しく入力してね"); } else
SPA モードのRemixを GitHub Pages にデプロイする
SPA モードの Remix を GitHub Pages にデプロイする方法が Remix のアカウントでポストされていたので、ふとそのリポジトリを見てみると、GitHub Actions を使った GitHub Pages へのデプロイが簡単に行えるようになっていて驚いた。 このポストを見ると GitHub Actions から提供されている Action など知らなかったものがいくつかあったので、Remix SPA モードのデプロイ方法など含め、内容を紹介したい。 動作確認した環境 関連がありそうな依存を記す。 "dependencies": { "@remix-run/node": "^2.8.1", "@remix-run/react": "^2.8.1", "@remix-run/serve": "^2.8.1", "react": "^18.2.0", "react-dom"
Reactを学習できるサービスmosya Reactの技術的な紹介
2024年3月15日の一粒万倍日に、mosya ReactというReactを学習できるサービスをリリースしました。 こちら1年間の開発期間を経て、ようやくリリースできました！ mosyaの開発期間と合わせると約2年間の開発期間を経てのリリースとなります。 いやー、長かった！ 良かったら下のリンクから試してみてください！ どんなサービスか mosya ReactはReactをオンライン上で学習できるサービスです。 エディターに書いたコードがリアルタイムにプレビューできるようになっていて環境構築なしでReactを学習できます！ 採点機能が搭載されているのでReactを自学習したい方におすすめです！ このサービスの開発で特に頑張ったのが以下の特徴です！ 最新の技術にキャッチアップしている ライブラリの型がエディター上で確認できる Biomeを動かしていてリントエラーがエディター上で確認できる 最
Reactを使ってプロダクト開発している開発者だけでなく、マネージャにも読んでほしい「Fluent React」 - ROUTE06 Tech Blog
チームでReactを使って開発していると、コードレビューをする際に、「この書き方はしない方がいいが、それを説明するには800文字くらい必要。図も描きたい。でもそれらを準備する時間はない。」ということが度々ありました。 また、フレームワークやライブラリの技術選定をする際、マネージャに「どうして技術選定が必要なのか」を説明する必要がありました。ROUTE06のマネージャはエンジニアリングへの造詣が深い方が多いので、対立構造になることはありませんが、説明するためには1000文字くらい必要で、やはり図も描きたい。時間はない。と同じ気持ちになることがありました。 参考情報として紹介できる情報がないか探してみると、「とりあえずこうすればOK」というベストプラクティスについては検索エンジンやSNSですぐに見つかります。ただ、どうしてその方法がベストプラクティスなのか、仕組みや原理を説明している情報は少な
CSS から React コンポーネントを生成する MistCSS
CSS から React コンポーネントを生成する MistCSS 2024.03.23 MistCSS は CSS in JS になぞらえた JS from CSS というコンセプトで、CSS から React コンポーネントを生成するツールです。ピュアな CSS を記述できるので、学習コストが低い、パフォーマンスに影響がないといったメリットがあります。 昨今のフロントエンド開発では、CSS の手法が多様化しています。特に React での開発では以下のような手法があげられます。 グローバル CSS（エントリーポイントで 1 つの CSS ファイルを読み込む） CSS Modules CSS in JS Tailwind CSS CSS の手法に新たな選択肢が加わりました。それが MistCSS です。MistCSS は CSS in JS になぞらえた JS from CSS というコ
フロントエンドの真実
起源 まだフロントエンドという言葉が生まれる前。 古代のプログラマー達はサーバーで一画面ずつ丁寧にHTMLを構築していた。 ところがあるとき一人のプログラマーがブラウザ上で動的にHTMLを書き換えることに成功する。 これに多くのプログラマーが続いた。 次第に勢力を増していった彼らはサーバーを離れ、自らをフロントエンドエンジニアと名乗り、サーバーに残ったもの達をバックエンドエンジニアと呼ぶようになった。 きっかけ 先日こんな投稿がとある掲示板（ここではXと呼ぶことにしよう）に寄せられた。 たしかに、Server Actionsを使って書くReactと、いにしえのPHPは非常によく似ている。 ふと10年近く前の出来事を思い出した。 それは次のような同僚との会話だった。 👨🏻💻「React触ってみました。」 👨🏻💼「え、どんな感じやった？」 👨🏻💻「なんかPHPに近い感じ
（基礎編）jQuery使いのエンジニアがReactとNext.jsでWebサイト制作するために最低限押さえておきたいコード
なぜ書いたか 筆者もWebサイト制作をそこそこ長くやってきておりいまは業務でVueを書いたりちょっとReactを書いたりSvelteを書いたりしていますが、2年前くらいまではReactやES6の構文すら書いたことがありませんでした。 WordPressでのサイト制作が多く、機能が少ないサイト制作会社ではjQueryで充分なことも多く、恥ずかしながら業務時間外での学習や外部の情報を追うこともしていなかったため、開発系の技術スタックに慣れるのにかなり時間がかかりました。 まずはよく使うコードを見て解説しながら答えの一つを示し、よく出てくるコードをざっくり理解して書けるようにすることで、実務でReactを取り入れる取っ掛かりになればいいなぁという思いでこの記事を書いています。 続編は多分今月中に書きます。 こちらは基礎編です。 対象者 普段jQueryでWebサイトを制作している 生のJSはあん
Reactは悪い意味でも現在のjQueryだし、それを受け止めないと前に進めないということ
HTMXのCEOに就任したので[1]、記念に記事を書きたいと思います。 HTMXサイトのエッセイ[2]はどれも珠玉の出来で評判ですが、それらを読んでもわかるとおり、HTMXは「Webはこうあるべき」という主義主張のあるライブラリです。その主義主張のかなり初歩的な前提を書きたいと思います。 Reactはなぜだめか、という話です。 21日追記 ちょっと誤解が生じているために書き足しますが、Reactのパフォーマンス(及びそれ以外のこと)への批判というのはHTMX固有のものではありません。SvelteやSolidJSといった新興JSフレームワークやRails等の非JS WEBフレームワーク、SSG開発者たち、それからReact開発者たち自身といった多様なWEB開発者たちに共有されている見方です。この記事の最後の方でReact批判記事のリンク集を引用していますが、そういった多様なバックボーンの人た
useEffectはなぜ使う必要があるのか? document.title = 'title' をラップする理由
答え(結論): レンダリングとエフェクトを分離するため クリーンアップを設定するため useEffect でラップする意味ってなくない? 以下の2つのコードはどちらもレンダリングすると Hello world と表示され、ページタイトルが Hello world になります。 const App1 = () => { useEffect(() => { document.title = 'Hello world'; }); return <h1>Hello world</h1> }; 同じ動作をするのであれば、なぜ useEffect でラップする必要があるのでしょうか? 理由1: レンダリング時に react の内部動作を考慮しなくて済む useEffect を使っていない App2 は、react が DOM 更新している最中に document.title = 'Hello worl
ssig33: "最近最小限のReactアプリを作るのに使ってるもの についてとりあえずメモしとく。 ##..."
新人声優 +81-9014502501 mail@ssig33.com 0088-7709-7529 it/it. my opinion may be not my own. but my fate is my own. 最近最小限のReactアプリを作るのに使ってるもの についてとりあえずメモしとく。 前提: デカいフレームワークは使わない next.js, Astro, Remixは使わない。next.jsとAstroは大好きなのだが、社内向けとか個人用とか小さいアプリに使うにはあきらかに恐竜であると思う。Remixは大好きではない。 前提: SSRしない SSRもSSGもISGもしない。CSRでいい。SSRしたいならReactをそもそもぶん投げたほうが(個人レベルなら)いいと思ってる。それがほしいならPHPやRails でええ。今更RailsでView書きたくないとか思うかもしれない
React Server Componentsを理解する | POSTD
私も年を取ったと感じるのは、今年Reactが10年目を迎えたからです。 混乱していた開発コミュニティにReactが初めて紹介されてから10年、以来いくつもの進化を遂げてきました。Reactチームは、急進的な改革ということに関しては躊躇しませんでした。問題に対して、より良い解決策が見つかれば、それを実行してきました。 数か月前、Reactチームは最新のパラダイム・シフトであるReact Server Componentsを発表しました。史上初めて、Reactコンポーネントがサーバーでのみ実行できるようになったのです。 このことに関連してオンライン上では、きわめて大きな混乱が起きています。それが何なのか、どのように機能するのか、利点は何か、そしてSSR（Server Side Rendering）などとどのように連携するのか、多くの人が多くの疑問を抱いています。 私はReact Server
イベントハンドラの関数名についての雑記 - Qiita
今日のXでは、イベントハンドラの関数名についての話題を見ました。元の投稿はこちらです。要するに、次のhandleClickのようなhandleイベント名という命名は良くないということです。 const handleClick = () => { ... }; <button type="button" onClick={handleClick} /> これについて少し考えたので、せっかくなのでアウトプットしておくことにしました。 この記事の目的 考えたことを頭の中に残しておくのがもったいないので、文章の形にしておく。 色々な意見が出る問題であり、ベストな答えは無いので各々好きにすれば良いということを、読者に理解してもらう。 とはいえ、筆者の考えに納得して同じ考えの人が多いと嬉しいので、なるべく納得してもらう。 筆者の考え 自分の考えとしては、むしろhandleClickいいじゃん！ どんど
パフォーマンスを気にするならReact Hook Formが無難
React Hook Form は高速。 Formik は早くない。改善は可能。 React Final Form はある程度早い。 React Hook Form が無難ではあるものの、CPU 6× slowdown で 100ms は通常では許容できると考え Formik を採用するのもあり。 比較したライブラリ 計測の対象にしたライブラリは以下の 3 つです。 React Hook Form Formik React Final Form パフォーマンス以外の特徴にも触れておくと、 React Hook Form TypeScript 製 頻繁に更新されている UI とフォームライブラリが密結合になりやすい Formik TypeScript 製 ある程度更新されている UI とフォームライブラリを疎結合にしやすい React Final Form コードのほとんどが JavaScr
Next.jsを4年間使用してたどりついた、エンタープライズアプリケーションのフロントエンド開発・構築手法 | POSTD
はじめに 目まぐるしく進化するフロントエンド開発の世界では、常に最新の知識や技術をいち早く取り入れることが、エンタープライズアプリケーションの開発を成功させる上で欠かせません。Tailwind CSS、TypeScript、Turborepo、ESLint、React Queryなどを含む強力なツールキットとNext.jsを4年間使用してきた結果、開発に役立つさまざまな知見やベストプラクティスが得られました。この記事では、大企業向けフロントエンドアプリケーションのパフォーマンス、保守性、拡張性を最大限に高める設計・構築手法を紹介したいと思います。 注記：ここに記載する内容はあくまでも個人的な見解であり、筆者が推奨する手法が必ずしも適さない場合もあります。 効果的なエンタープライズ向けフロントエンドアーキテクチャの基本原則 エンタープライズ規模のアプリケーション向けにフロントエンドソリューシ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
React フレームワークの 動向と選定基準
【2024年】React, Tailwind CSSでメルカリクローンサイトを作ろう【入門】
SPAの歴史とRemix SPAモードという到達点 / the SPA's chronicle reaches to remix
