ヘッドレスUIコンポーネントでいこう -- Radix UI + Stitches がいい感じ
こんにちは！ 株式会社ココナラの法律相談事業部でWebエンジニアをしている 原井 です。 ココナラ法律相談 と ココナラエージェント という2つのプロダクトのWebフロントエンド・バックエンド開発を担当しています。 この記事は、フロントエンド開発に使うUIコンポーネントライブラリの技術選定をするシーンでのお話です。 私たちが何を課題に感じていたのか、どう考えて Radix UI と Stitches の採用に至ったのか、採用してみてどうだったのかをご紹介します。 UIコンポーネントを開発していて思うこと 世の中にはUIコンポーネント集とでも呼ぶべき便利なライブラリがたくさん公開されています。 例えば以下のようなものがあり、他にも把握しきれないほどあると思います。 MUI (Material UI) Ant Design Chakra UI Vuetify これらのUIコンポーネントライブラ
過激派が教える！ useEffectの正しい使い方
ReactのuseEffectは、フックの中でも使い方が難しいものの一つです。そこで、この記事では筆者が考えるuseEffectの望ましい使い方を皆さんに伝授します。 基本原則 技術やその要素の使い方を考えるにあたって、筆者が好んでいるのは基本原則を置いてそれに基づいて判断することです。ということで、この記事ではまず筆者が考えるReactの基本原則を紹介します。 筆者がもっとも重要視する原則は、ReactはUIライブラリであるということです。つまり、ReactにはUIの管理をさせるべきであって、その他のことはReactの役目ではないということです。Reactが難しいと思う人がいる場合、何でもかんでもReactにやらせようとするから余計に難しくなっているのだと思います。 例えばアプリケーションのロジックの管理やそれに付随するステートの管理はReactの役目ではないので、Reactの外部で処理
CSS-in-JSのパラダイムシフト
2023年現在、Reactでは多種多様なスタイリング手法が用意されています。 代表どころで言うとCSS ModulesやTailwind、CSS-in-JSなどが有名です。筆者の個人的な好みでは、これらの選択肢の中でもCSS-in-JSを用いたスタイルが特に好きですが、CSS-in-JSライブラリ群の中にはランタイムでスタイリング処理がなされる為にパフォーマンス上の問題を抱えているとの指摘を受けているものもあり、最近は人気が下火になっているように感じています。 そこで本記事では、CSS-in-JSが生まれた背景から遡り、各ライブラリの内部実装を確認しながらそれぞれのライブラリの仕組み・メリット・問題点を明らかにし、CSS-in-JSのパラダイムシフトを追ってみたいと思います。 CSS-in-JSの登場 CSS-in-JSという言葉が最初に公の場で登場したのは、2014年にFacebookの
ReactとCSSの新しいUIフレームワークを作った
リンク 公式サイト デモサイト 概要 Camome UI は React または HTML + CSS で使用できる UI フレームワークです。 ソースは React + CSS Modules で書かれており、 それを React コードからインポートするか、静的なクラス名で出力された CSS ファイルを読み込むことで使用できます。 特徴 軽量なバンドルサイズ 例えば @mui/material@5.11.6 の Button は単体で16.9KBあり、それに Emotion や ThemeProvider も加わります。 それに対して Camome UI の Buttonは単体で 1.42KB(CSS 含む)、それにグローバル CSS の 4KB が加わります（計測方法）。 これらのフレームワークは言ってみれば「フルスタック」であり、どんなウェブサイト・アプリでも構築できる柔軟性と機能
SPA Componentの推しディレクトリ構成について語る
こんにちは、よしこです。 この記事は 2020年に立ち上げたWebフロントエンド構成の振り返り の「Componentのディレクトリ構成」項の詳細記事です。単体でも読めますが、よければ元記事もあわせてどうぞ！ この記事では、今わたしが 株式会社ナレッジワーク というスタートアップで開発・運用しているプロジェクトにおいてうまくいっていると感じているComponentのディレクトリ構成についてご紹介していきます。 ディレクトリ構成 Componentは src/components の中にまとめていて、その下に以下の4種類の分類ディレクトリを切っています。 src/components/page src/components/model src/components/ui src/components/functional 分類ディレクトリを考えるにあたって重視したポイントは以下。 新しくco
私の推しフロントエンドディレクトリ構成と気をつけたいポイント
どうも、sakitoです。 今回は私の推しフロントエンドディレクトリ構成と気をつけたいポイントを紹介します。ちぇけら！ 2023年5月29日 追記 この記事を読みにきていただきありがとうございます。 私が記事を書いた時期はまだNext.jsのApp Routerが発表されたばかりで、App Routerを使用したディレクトリ構成の考慮はされていません。 先日、App Routerがリリースされ、Next.jsのドキュメントにApp Routerのディレクトリ構成について記事が出ているので、Next.jsを使用されている場合は、まず参照することをオススメします。 はじめに 今回、私の紹介する推し構成は、機能単位で設計するパターンです。 Reactのディレクトリ構成のベストプラクティスを集めたBulletproof Reactで紹介されているパターンにかなり似ています。さらに詳細なプロダクト構
GitHub - alan2207/bulletproof-react: 🛡️ ⚛️ A simple, scalable, and powerful architecture for building production ready React applications.
React is an excellent tool for building front-end applications. It has a diverse ecosystem with hundreds of great libraries for literally anything you might need. However, being forced to make so many choices can be overwhelming. It is also very flexible, you can write React applications in any way you like, but that flexibility comes with a cost. Since there is no pre-defined architecture that de
モダンフロントエンドで始めるつらくないReactディレクトリ構成 - RAKUS Developers Blog | ラクス エンジニアブログ
はじめに こんにちは、ラクスフロントエンド開発課の斉藤です。 記事タイトルはReact開発者なら知る人ぞ知るりあクト！ TypeScriptで始めるつらくないReact開発のパロディです。とてもわかりやすい入門書なのでReact初学者の方には学びの第一歩として自信を持ってオススメできます！ さて今回は、モダンなフロントエンド技術を採用したうえで、極力シンプルで開発体験を損なわないようなディレクトリ構成を考えてみたので共有したく記事にしました。現在実際に運用しているのですが、今のところ大きな問題も無くチームからの不満も上がっていません。しかし、個人的に微妙な部分もあるのでそちらの紹介も行いたいと思います。 今回、構成を考えるにあたって重視したポイントは以下の3点です。 新しく参入するメンバーでもすぐに理解できるシンプルな構成にしたい テストやリファクタしやすい構成にしたい できればルールが厳
Dan氏によるCreate React Appの将来、およびReactとフレームワークの関係性についてのコメントの翻訳
Create React App(以下「CRA」という)の将来、およびReactとフレームワークの関係性についてDan氏がGitHubのIssueのコメントで語った内容の翻訳です。非常に長いコメントですが、Reactユーザーであれば一読に値する内容だと思ったので翻訳してみました。参考になれば幸いです。 原文 翻訳 みなさん、こんにちは。 CRAの現状については以前から痛いほどわかっており、それに対処するための提案に取り組んでいるところです。このプルリクエストは議論を始めることを目的にしていたので、私たちがCRAの将来について考えているいくつかの背景を説明する良い機会だと思います。私たちが考慮している理由とトレードオフについて明確にしたいので、いくつかのセクションからなる長いコメントになりそうです。もし全てを読む気になれないなら、最後のセクションまでスクロールして私たちが提案する今後の方法を
Popular React Folder Structures and Screaming Architecture
Screaming ArchitectureEvolution of a React folder structure and why to group by features right away React folder structures have been debated for years due to React's unopinionated approach, leading developers to ask, "Where should I put my files? How should I organize my code?" I've researched the most popular approaches to organizing React projects: Grouping by file type like components, context
なぜJestのmockライブラリに混乱してしまうのか？ - Qiita
はじめに JavaScriptのモックライブラリでは、 sinon などが有名であるが、テスティングフレームワークに Jest を使ってるならば Jest組み込みのモックライブラリで済ませたほうが学習コスト少なくて済むだろうと思える。 しかし、 sinon の感覚でJestのモックライブラリを使おうとすると違和感というのか、モックへの考え方の違いに気づかされる。 ということで今回は、Jestのモックライブラリの考え方と使い方を整理していきたいと思う。 モックの用語整理とJestモックライブラリの位置づけ モックと一言でいっても、それが指す内容は微妙に異なる。 ここでは、モックを 広義のMock Object と 狭義のMock Object と分けて整理してくれているテスト駆動開発を参考に用語を整理する。 テスト駆動開発では、モック用語を、下図のとおり、テストダブルとそのサブクラスとして
Next.js アプリケーションの共通コンポーネント開発 - クックパッド開発者ブログ
こんにちは。レシピサービス開発部のkaorun343です。クックパッドではスマートフォン向けページにおける開発者体験向上のために、レシピサービスのフロントエンドを Next.js と GraphQL のシステムに置き換えている話にて紹介したとおり、Next.jsとGraphQLを用いたモダンな環境へと移行を進めています。例えばモバイル端末からのアクセスでURLがトップページの / であれば Rails、レシピ詳細ページの /recipe/:id であれば Next.js アプリにルーティングされるようになっています。現在ではレシピ詳細ページだけではなく検索結果ページやつくれぽ詳細ページ、MYフォルダページなどもNext.jsアプリケーションに置き換わっています。今回はその移行により生じた課題と取り組み方、それから併せて実施したモノレポ環境整備について紹介します。 共通コンポーネントの導入背
フロントエンドのテストコードを書くときに大切にしていること - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、フロントエンドエキスパートチームの @mugi_unoです！ kintone では フロントエンドの刷新プロジェクト（通称フロリア）が進行中です。 blog.cybozu.io kintone の開発では E2E 主体の自動テストを整備していましたが、 フロントエンドの刷新に合わせて、新たにフロントエンド側でのテストコードを積極的に書いています。 テストを書くことに不慣れなメンバーもいるため、日々 Pull Request 上でのレビューやペア・モブ作業を通じて、知見の共有が行われています。今回はフロントエンド刷新のテストを書いてきた中から、筆者が有用だと感じた知見やノウハウを紹介したいと思います。 目次 💡「実はそれ最初からパスしてるかもしれない」 期待する操作で期待する結果になることを厳密に検証する 他のテストケースによって前提条件を担保する 💡「テストコード上のロジッ
コードジャンプ可能な CSS Modules を実現する happy-css-modules の紹介 - mizdra's blog
弊社では React で CSS を書くための手法として CSS Modules を全面的に採用しています。そこで CSS Modules を使った開発をより快適にするために、「happy-css-modules」というツールを作りました。 happy-css-modules のデモ。 この記事ではこのツールが必要になった背景、導入方法、そしてツールの技術的な仕組みについて紹介します。 CSS Modules の問題点と、typed-css-modules による解決 CSS Modules では、デフォルトでは存在しないクラス名を使用しても、(プロジェクトの設定次第ですが) TypeScript のコンパイルエラーが出ることはありません。 import styles from './Button.module.css'; function Button() { return ( <but
【React】1度だけ変更されるstateにはuseStateよりuseReducerを使う方が最適
useStateでしょ！ という声が聞こえてきますね。 おっしゃる通りなんですが、それよりも実はそういう時はuseReducerの方がより適しているという話です。 はじめましてスペースマーケットでフロントエンドエンジニア兼リーダーをしています。 はじめに useState / useReducerがなんぞや？という方は公式のリファレンスをご確認ください。 1度だけ変更されるstateでいうと下記のようなイメージでしょうか？ const Hoge: FC = () => { const [finished, setFinished] = useState(false) const onClick = () => { setFinished(true) } if (finished) return <div>送信しました！</div> return ( <div> <button onClic
500点出す！ - ゆーすけべー日記
「Web Speed Hackathon 2022」という「非常に重たいWebアプリをチューニングして、いかに高速にするかを競う競技」があります。 リモート参加で11月1日から27日まで開催されています。 ここで言う「高速」とはCore Web Vitalsのスコアが高いことを言い、Lighthouseのスコアをベースにした500点満点の争いです。 ISUCONのフロントエンド版ですね。 以前にも同じ課題で「学生向け」と「社内（サイバーエージェント）向け」が行われたらしく、まだ500点を出した人はいません。 そこで僕は「満点を出したい」と思い、初日から、いやむしろフライングしていたからその前から頑張ってきました。 そして、先日（17日）、ついに500点満点を出しました！ たぶん、レギュレーションはクリアしている、はずです（もし違反してたらすいません…）。 自動で行われる「Visual Re
最速攻略！ Reactの `use` RFC
皆さんこんにちは。最近のReact界隈で話題になっているのは次のRFCです。 そこで、この記事ではさっそくRFCを理解することを目指します。 ただし、このRFCはSuspenseに深く関わるものです。SuspenseはReact 18でもう正式リリースされていますから、この記事ではSuspenseは前提知識とします。もしまだSuspenseをよく知らないのであれば、ぜひ次の記事で学習してください。 また、RFCはあくまでReactの新機能のアイデアを公開するものであり、これが必ず実装されるとは限らない点にご注意ください。例えば、過去にはuseEventというRFCが注目を集めていましたが、意見が集まった結果としてそのRFCは実装されずにクローズされました（RFCが無駄だったというわけではなく、再度検討してよりアイデアがブラッシュアップされることになります）。 新しい use API このR
Signalって何？jotai-signalからのjotai-uncontrolled、これすごいです
導入 Reactive ProgrammingではSignalという概念があるらしいですが（実はもっと古くからある概念）、SolidJSが導入してReact Hooksとの差が明確になったのかと思います。 「Signal」は Solid のリアクティビティの基礎となるものです。これらには、時間とともに変化する値が含まれており、Signal の値を変更すると、それを使用しているすべてのものが自動的に更新されます。 とのことです。ObservableとかStreamとかも似たようなものですかね。 SolidJSのポイントはSignalを使ってfine-grained reactivityを実現しているところだと思います。ReactのようにVirtual DOM（とはもう呼ばないらしい、DOMじゃないので。でも、以下VDOM）を使わずに局所的にDOMを直接更新するのでパフォーマンスが良いとのこと
🏏 素振り: React Hook Form - memo_md
あーはいはい、React Hook Formね、知ってる知ってる（知らない） そんな状態なので素振りしておく。 React Hook Form https://react-hook-form.com/get-started React Hook Form の重要なコンセプトの一つは、非制御コンポーネント (Uncontrolled Components) をフックに登録（register) し、フォームフィールドの値を検証と収集できるようにすることです。 DOMベースに値を持つコンポーネントを主体に、いい感じにフォーム管理ができるものという理解をした。 自分がReactを書くときは今のところ制御コンポーネントを使うケースが多いので、React Hook Form 向けに脳をスイッチしないといけなさそう。 useForm と register 特に重要なのは useForm と regist
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Mantine
