React 18に備えるにはどうすればいいの？ 5分で理解する - Qiita
React 18はReactの次期メジャーバージョンで、2021年の6月にalpha版が、11月にbeta版が出ました。また、Next.js 12でもReact 18のサポートが実験的機能として追加されました。React 18の足音がだんだんと我々に近づき、アーリーアダプターではない皆さんの視界にもいよいよReact 18が入ってきたところです。 特に、React 18ではServer-Side Rendering (SSR) のストリーミングサポートが追加されます。現在ReactでSSRを行いたい人の強い味方としてNext.jsが存在しているわけですが、Next.js 12でもReact 18を通してストリーミングの恩恵を受けることができます（Next.jsではSSR Streamingと呼んでいるようです）。また、厳密にはReact 18とは別ですが、React Server Comp
Promiseをthrowするのはなぜ天才的デザインなのか - Qiita
ReactのConcurrent Modeが最初に発表されたのはもう1年近くも前のことです（記事執筆時点1）。Concurrent Modeはたいへん奥深い機能で正式版がたいへん待ち遠しいですが、Concurrent Modeの代名詞として多くのReactユーザーに知られているのはPromiseをthrowするというAPIデザインです。Concurrent Modeでは、コンポーネントがレンダリング時にPromiseをthrowすることで、レンダリングをサスペンドした（Promiseが解決されるまでレンダリングできない）ことを表します。 Concurrent Modeに関しては筆者の既存記事Concurrent Mode時代のReact設計論 (1) Concurrent Modeにおける非同期処理などをご参照いただきたいのですが、ここではPromiseをthrowするということ自体に焦点
色々書き比べた結果Tailwind CSSにしたという話 - Qiita
Twitterでこういう発言を見かけまして Tailwind CSSはデザインに凝ってるサイトでは使えない こだわりが無い場合に向いている は？何いってんの？ って思ったので、自分がいろいろ試した結果、Tailwind CSSを選んだ話を書きます。 はじめに 以前、Tailwind CSSは結構いいぞって話を書いたんですが、この記事の立ち位置的にはその続きみたいなものなので、以下の記事を始めにご参照いただけるとより分かりやすいかもしれないです。 この記事では、前回記事を書いた後、個人仕事でWebサイトをGatsbyで作り、その中で、どうやってCSSを書くのが良いのか模索した結果、自分はこれを選んだっていうのを、同じUIを色々な方法で書き比べたコードを並べつつ、どうのこうの筆者の考えを述べていきます。 その仕事はほとんど筆者が「まかせてくださいよーいい感じに作りますよー。デザインそろってない
Concurrent Mode時代のReact設計論 (1) Concurrent Modeにおける非同期処理 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Concurrent Modeは、現在（2020年3月）実験的機能として公開されているReactの新しいバージョンです。Reactの次のメジャーバージョン（17.x）で正式リリースされるのではないかと思っていますが、確証はありません。なお、React公式からもすでに結構詳細なドキュメントが出ています。 並列モードの導入（実験的機能） Concurrent Modeに適応したアプリケーションを作るためには、従来とは異なる新しい設計が必要となります。筆者はConcurrent Modeを使ったアプリケーションをひとつ試作してみました。この記
styled-components（CSS in JS）をやめた理由と、不完全なCSS Modulesを愛する方法 - Qiita
styled-components 画像は styled-components ツライっていう顔です。 Angularのようにスタイリングまで面倒を見てくれるUIフレームワークならまだしも、Reactの場合はコンポーネントのスタイリング方法も自身で選択しなければいけません。CSSのスタイリング方法/設計はいくつか存在しますが、どれも一長一短で、やはり銀の弾丸は存在しません。スタイリング方法を選択可能なUIフレームワークは、この混沌とした選択肢の中から価値を見出す必要があるわけです。 僕はBEMによる人力CSS管理（Sass/Less/Stylus）から、 { fontSize: 14 } のようなJSオブジェクト形式のCSS in JS、 styled-components のようなTemplate Stringsを利用したCSS in JS、そしてCSS Modulesまで幅広く公私とも
Reactを使って本気でアンケートシステムをつくった - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事は エムスリー Advent Calendar 2017 の25日目の記事です。 普段はDB・サーバサイド・クライアントサイドまでの設計・実装・運用を扱っていますが、この記事ではReactを使って開発したシステムについてを紹介しようと思います。 作ったもの アンケートシステム(survey-designer-js)を作り、社内で使っていました。またOSSとしてレポジトリに公開もしています。 GitHub DEMO なお公開しているのはクライアントサイドのみで、サーバサイドの実装は公開していません。なお、エムスリー社内で使用してい
Adobe製デザインシステム「React Spectrum」がすごいので紹介したい - Qiita
React Spectrum 🚀 Super excited to announce: ♿️ React Aria — Accessible UI primitives for your design system. 👑 React Stately — State and core logic for your design system. 🌈 React Spectrum — Adobe’s design system. Learn more: https://t.co/ucVguh3rqp Github: https://t.co/e8aOfLgCVK — Devon Govett (@devongovett) July 15, 2020 7月15日にAdobeのデザインシステム react-spectrum がリリースされました。 デザイン製も優れていますが、他の部分でのクォリ
Reactで管理画面をつくるときに便利だったライブラリ集と所感 - Qiita
主に未来の自分用 material-ui Material DesignをReactでコンポーネント化したもの UIパーツになっているのでパパっと使えるし、あとでカスタマイズするときもけっこう融通が効く 現在1.0.0がbetaでアップデートが激しく破壊的変更も多いので、場面に合わせてStableとどちらを採用するか決めるのがよい。 v1がStableになった react-admin REST API（やGraphQL）を叩くクライアントとして最適化された感じの管理画面コンポーネント集 インデックスがあって、閲覧ページがあって、登録ページがあって、みたいなよくある画面が素早くつくれる Material UIを内部で使っていて、さらに管理画面用に高レベルなコンポーネント（テーブルとか新規作成フォームとか）が実装されている カスタマイズ性もまぁまぁ高い。CRUDではないエンドポイントでも拡張可
Redux不要論と、グローバル状態管理ライブラリReactNの紹介 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Redux不要論 若干強めのタイトルです。あらゆるケースでReduxが不要と主張するつもりはありません。 しかし、Reduxが不要と思われるケースでもReduxが使われることを避けるため、「Reduxは必ず採用しなければならないものではない」ということを意識していただきたく、刺激的なタイトルで始めました。 （個人的にはむしろ、積極的に採用すべき理由がなければ採用しない方が良いくらいに思っています） （MobXとか他のライブラリについては一旦置いておきます） Reduxのメリット Redux's motivation 曰く、SPAに於ける
TypeScript で書く React コンポーネントを基礎から理解する - Qiita
この記事は Recruit Engineers Advent Calendar 2019 の 23日目の記事です。 TypeScript のプロジェクトで React コンポーネントを書いていると、コンパイラに怒られることがたびたびあります。ネット上にあるサンプルコンポーネントが JavaScript で書かれていると、プロジェクトにもってきたときにコンパイルできないということはよくあるんじゃないでしょうか。any でコンパイラを黙らせることもできますが、せっかく TypeScript を使っているので、安全に解決したいよねってことでこのような記事を書きました。 型定義は @types/react@16.9.17 にしたがっています。目次をみて、この程度のことはもう知っているよという方は react-typescript-cheatsheet をみてください。React + TypeScr
Redux の記述量多すぎなので、 Redux の公式ツールでとことん楽をする。 ( Redux Toolkit) - Qiita
2019/11/20 追記 当記事でメインに取り扱っていたライブラリ名が変更されました。Redux Starter Kit -> Redux Toolkit それに合わせて、本記事もアップデートしています。 追記終わり はじめに Redux Hooks がリリースされたおかげで、Redux の store とコンポーネントのつなぎ込みが簡単になりました。 今回は Redux チームが公式にリリースしている Redux Toolkit を利用すると、Action、Reducer 部分もかなり簡潔に記述できるというお話です。 Redux Hooks については以下の記事を参照してください。 Redux Hooks によるラクラク dispatch & states Redux Toolkit とは？ Redux チームが公式にリリースしているReduxを簡潔に記述するためのライブラリです。 ほ
Reduxのmiddlewareを積極的に使っていく - Qiita
最初はちょっととっつきにくいけど、責務がはっきり分かれていて比較的コードがごちゃごちゃになりにくい（と思っている）Reduxですが、やはり実戦投入するとどうにも扱いにくい部分が出てきます。 特にそう感じるのは通信系の処理、ユーザーとのインタラクションです。これってつまるところ非同期処理なんですが、処理を依頼する側、つまりActionを投げる側としては「あとのことはまかせた！」と言いたい。Actionを投げる部分ってのはだいたい何かのイベントハンドラだったりしますが、そういう場所に通信やインタラクションの処理をダラダラと書きたくない。 本稿ではそれらの面倒な部分を責務が分離されたメンテナンスのしやすいコードになるようにmiddlewareを活用する例をいくつか紹介します。 その前にmiddlewareについて Reduxの公式ドキュメントではログ出力を例に取り、アプリケーション本体から分離し
小さいReactアプリケーションのためのライブラリ書いた - Qiita
EventEmitterバケツリレースタイル/フレームワークなしで小さくFluxする - Qiita これ見て最近は大体自分も同じような感じのことをしているので共通化できる最小限のコードをライブラリにしてみた。 元記事でも言ってるようにやることはとても少ないのでライブラリ使わないでもいいんだけどそのへんは好み。 Usage まず普通のステートレスなReactコンポーネントを作る。dispatchというpropsを受け取ってそれを通してイベントを発火するというのが唯一の規約。 import React from 'react'; // Stateless component export default class Counter extends React.Component { render() { return ( <div> <div>{this.props.count}</div>
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
react-problems.md