React脳によるUIライブラリ書きやすさランキング - Qiita
前回のおさらい 前回の記事では、Reactに有利なベンチマークでUIライブラリに競ってもらいました。 こういうベンチマークに対しては、「実務では〜」みたいな反応が一定数出てくるのが自然の摂理です。 書きやすさランキング そこで、シリーズのまとめとして、より実務に近い指標として「書きやすさ」で競ってもらおうと思います。ただし、今回は筆者の独断と偏見によるランキングとなります。せっかく6つのライブラリで同じアプリケーションを書いたので、感想を記事にして残しておきたいという意図です。筆者と同じくReact脳の方にとっては参考になるかもしれません。 なお、前の記事を読んだ方はお分かりの通り、今回書いたアプリケーションはコンポーネントが何個かのものであり、React以外の知識は公式ドキュメントを一通り読んだ程度です。したがって、今回のランキングはコンポーネントの書きやすさに着目しています。大規模開発
Reactに有利なベンチマークを作ってみた - Qiita
皆さんこんにちは。現在、フロントエンドでは宣言的UIが大流行しており、そのためのライブラリもReactを筆頭に複数存在しています。 ライブラリが複数存在するところには当然のように比較や論争が起こるものですが、UIライブラリの場合はパフォーマンスがよく焦点となります。 筆者はReactの信者ですが、Reactは古株ということもあってか、最近の議論ではReactは他のライブラリと比較されるかませ犬のような役割を担うのがよく見られます。「仮想DOMは必要ない」といった類のものです。 しかし、筆者の考えではReactは今でも、もっとも真剣にパフォーマンスに取り組んでいるUIライブラリです。特に、Reactはパフォーマンスを高いユーザーエクスペリエンスのための手段として捉えており、ドキュメントにもユーザーエクスペリエンスという言葉が多く出てきます。 そこで、今回はReactが最も有利になるようなベン
敗北者のTypeScript - Qiita
TypeScriptはJavaScriptに静的型を導入したプログラミング言語で、登場から現在までその人気を増し続けています。 動的型付き言語であるJavaScriptに静的型の安全性（コンパイル時にバグ・間違いを発見することができる能力）を与えることで、TypeScriptはJavaScriptによる開発の効率を上げてくれます。 裏にJavaScriptがあるという特性もあり、TypeScriptは「部分的に静的型チェックをする」というような挙動をサポートしています1。詳しくは後述しますが、これによりJavaScriptからTypeScriptへの移行が可能となっています。TypeScriptは@ts-check（あるいは@ts-ignore）などを通じてこのようなユースケースも手厚くサポートしています。 このことの裏返しとして、TypeScriptを利用するときは注意すべき点があります
import * as 構文とパフォーマンス最適化 - Qiita
JavaScriptには、import * as という構文があります。これは、インポート先のモジュールの中身全部をオブジェクト（モジュール名前空間オブジェクト）として取得できる構文です。 import * as mod from "./some-module"; console.log(mod.foo, mod.bar); たまに、「この構文を使うとTree Shakingが効かなくなる」といった説明が見られることがありますが、必ずしもそうではありません。そこで、この記事ではimport * as構文とパフォーマンス最適化に関連する正しい知識と、その背景をご紹介します。 webpackで検証してみよう Tree shakingを行うのはモジュールバンドラであることが知られています。そこで、webpackを使って色々と構文を検証してみましょう。今回は次のような設定を用います。これは最適化を
useRefでステートを管理するのはReact18でアンチパターンになるからやめよう - Qiita
こんにちは。最近、Reactでのステート管理において「useStateの中にステートを置くのではなく、useRefで得たrefオブジェクトの中にステートを置いてuseState（またはuseReducer）をコンポーネントの再レンダリングを発生させるためだけに使う」というやり方を複数の記事で見かけました。このパターンは、今（React 17以前）は動くけどReact 18でアンチパターンに変貌するやり方なので、啓蒙するためにこの記事を用意しました。 ステート（コンポーネントのレンダリングに使用される値）は、useRefではなくuseState（またはuseReducer）をちゃんと使って管理するようにすれば、React 18以降も安泰です。 useRefをステート管理に使うパターンとは こういうやつです。 // 普通のやり方 const Counter1: React.VFC = () =
そこのお前！ 余計なuseMemo1個に含まれるオーバーヘッドは余計なdiv 0.57個分だぜ！ - Qiita
※効果には個人差があります。 useMemoのオーバーヘッドについて ReactのuseMemoは、パフォーマンス最適化に使われるAPIです。コンポーネント内で計算やオブジェクトの生成を行う際に、以前の計算結果をキャッシュして使い回すことで再レンダリング時の計算を削減したり、新しいオブジェクトの生成を防ぐことができます。 useMemoに関しては、あくまで最適化のためのものであるから「無駄に使うべきではない」という言説がよく見られます。その理由は、useMemoのコストもゼロではなく、余計な使用はそれだけパフォーマンスの低下に繋がってしまうからです。 しかし、筆者はuseMemoのコストは微々たるものであり、本当に一目見て明らかに無駄でない限りは積極的に使うべきだと思っています。 そこで、筆者はuseMemoのオーバーヘッドがどれくらいかを調べるためのベンチマークを作成しました。この記事で
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するということ自体に焦点
JavaScriptの関数名の全て - Qiita
JavaScriptに限った話ではありませんが、関数というのは名前を持っていたり持っていなかったりします。関数名は普通はプログラムの読みやすさくらいにしか影響しませんが、JavaScriptでは必ずしもそうではありません。 例えばReactで関数コンポーネントを使う場合は関数名がコンポーネント名となり、React用開発者ツールなどで見ることができデバッグに役立ちます。また、Gulp v4もエクスポートした関数名がタスク名となります。 関数名は、関数オブジェクトのnameプロパティで取得できます。 function foo() { console.log('foo!'); } console.log(foo.name); // "foo"
JavaScriptの等値比較を全部理解する - Qiita
皆さんこんにちは。今回の記事ではJavaScriptの等値比較について見ていこうと思います。 「どうせ==と===の違いとかだろ？ 今さらそんな記事書くなよバーカｗ」と思った人はぜひ期待せずに読み進めてみてください。 「じゃあObject.isでしょ？ 知ってる知ってる、使ったことないけど」と思った人はまあ読まなくても大丈夫です。 さて、等値比較というのは、2つの値が等しいかどうか判定することです。JavaScriptにおいて等値比較はどのように行うのか、そしてどのような場面で等値比較が発生するのかをこの記事では余すことなく紹介します。 以降、この記事で仕様書という場合はECMAScript® 2018 Language Specificationを指すものとします。 ==と=== とはいえ、まずは==と===の話をしないことには始まりません。==はJavaScript初心者がとりあえず習
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
