UIコンポーネントの大きさは外から制御しよう - Qiita
昨今のフロントエンド向けUIライブラリでは、コンポーネントの設計が重要です。この記事では、コンポーネントのスタイリング、その中でもとくにコンポーネントの大きさに関わるコンポーネント設計について考えます。 私の考える結論は、むやみに大きさを指定できるpropを生やさずに、CSSで外から大きさを制御できるようにしたほうがいいです。 コンポーネントの大きさを制御したい UIの一部分を再利用可能なコンポーネントとする場合、同じコンポーネントがさまざまな場面で使えるのが望ましいでしょう。コンポーネントが提供する機能にもよりますが、場面に応じてさまざまな大きさでコンポーネントを使用できたほうがよいこともあります。 具体例として、このようなコンポーネントを考えてみましょう。例はReactで示しますが、この記事の内容はReactとは関係ありません。 const Card: React.FC<React.P
Reactに有利なベンチマークを作ってみた - Qiita
皆さんこんにちは。現在、フロントエンドでは宣言的UIが大流行しており、そのためのライブラリもReactを筆頭に複数存在しています。 ライブラリが複数存在するところには当然のように比較や論争が起こるものですが、UIライブラリの場合はパフォーマンスがよく焦点となります。 筆者はReactの信者ですが、Reactは古株ということもあってか、最近の議論ではReactは他のライブラリと比較されるかませ犬のような役割を担うのがよく見られます。「仮想DOMは必要ない」といった類のものです。 しかし、筆者の考えではReactは今でも、もっとも真剣にパフォーマンスに取り組んでいるUIライブラリです。特に、Reactはパフォーマンスを高いユーザーエクスペリエンスのための手段として捉えており、ドキュメントにもユーザーエクスペリエンスという言葉が多く出てきます。 そこで、今回はReactが最も有利になるようなベン
結局useMemoはいつ使えばいいの？ 僕の決定版 - Qiita
皆さんこんにちは。筆者の以前の記事では、ReactのuseMemoを無駄に使うことによるレンダリング速度のオーバーヘッドがどれくらいかをベンチマークによって示しました。 それによれば、スマートフォンを想定したとしても、useMemoだけで描画に目に見える影響を与える（16msくらいの遅延を発生させる）には万のオーダーのuseMemoが必要なことが分かります。 速度ではなくuseMemoを使うことによるメモリ消費量の増加を気にする声も聞かれましたが、すみませんが筆者はそこまでメモリクリティカルなアプリをReactで書いたことがなく知見に乏しいため、今回はこの記事の対象外となります。 この結果が出たことでuseMemoをいつ使うのかなどという議論には終止符が打たれたかと思いきや、上記の記事の感想などを見ているとまだ喧々囂々です。 そこで、この記事では筆者の考えを皆さんに共有し、いよいよもってこ
そこのお前！ 余計なuseMemo1個に含まれるオーバーヘッドは余計なdiv 0.57個分だぜ！ - Qiita
※効果には個人差があります。 useMemoのオーバーヘッドについて ReactのuseMemoは、パフォーマンス最適化に使われるAPIです。コンポーネント内で計算やオブジェクトの生成を行う際に、以前の計算結果をキャッシュして使い回すことで再レンダリング時の計算を削減したり、新しいオブジェクトの生成を防ぐことができます。 useMemoに関しては、あくまで最適化のためのものであるから「無駄に使うべきではない」という言説がよく見られます。その理由は、useMemoのコストもゼロではなく、余計な使用はそれだけパフォーマンスの低下に繋がってしまうからです。 しかし、筆者はuseMemoのコストは微々たるものであり、本当に一目見て明らかに無駄でない限りは積極的に使うべきだと思っています。 そこで、筆者はuseMemoのオーバーヘッドがどれくらいかを調べるためのベンチマークを作成しました。この記事で
アンサー： なぜTypeScriptの型定義に凝るのか - Qiita
この記事は、昨日公開された以下の記事に対するアンサー記事です。TypeScriptで型定義に凝る派筆頭（自称）として、このお題に対して別の視点から光を当ててあげるためにこの記事を用意しました。 TypeScript の型定義に凝りすぎじゃね？ まず最初に、この記事（以下では元記事と呼びます）の著者を攻撃したり、元記事の内容を否定する意図はないことをご理解ください。結局のところ、考え方が異なり、前提が異なるから異なる結論になっているだけなのです。TypeScriptを使う皆さんがいろいろな観点から見た情報を取得し、自分の状況に応じた適切な考え方・判断をできるようにすることがこの記事の目的です。 要約 大きなコードを小さく分解しても本質的な難しさが消えるわけではないよ？ 型はドキュメントなんだから正確に書こうぜ！ 外界との接続も妥協せずに型システムで解決しようぜ！ 機械にできる仕事を人間がする
Let's Encryptを使用しているウェブページをブロックするプロキシサーバー - Qiita
Let's Encryptはドメイン認証証明書を無料で発行してくれるたいへん素晴らしいサービスです。ウェブサイトをHTTPSで提供するためには証明書が必要ですが、Let's Encryptの登場以前は認証局から有料で証明書を発行してもらうのが主流でした。それを無料で発行してもらえるのは大変ありがたいことです。また、発行プロセスは自動化されておりとても簡単です。筆者も個人のウェブサイトは全てLet's Encryptで証明書を取得しています。 ところが、Let's Encryptが発行する無料の証明書なんて信頼できないという教義を信奉するタイプの人々も存在するようです。筆者は最近Twitterで見かけました。ということで、そのような思想を持つ方も安心してインターネットを利用できるように、Let's Encryptによって発行された証明書を使用しているウェブサイトのみブロックするプロキシサーバ
JavaScriptでデッドロックを作ってみた
いきなりですが、皆さんは排他制御をご存知でしょうか。排他制御は並列コンピューティングにおける概念であり、複数のプロセスが資源を共有して使用する際に、複数のプロセスが同時に資源を使用している状況（競合）が発生しないように制御する手法です。（この分野にはあまり詳しくないのでまさかり等は歓迎します）。 排他制御の一手法としてロックが知られています。この手法では、ある資源を使用するためにはまずその資源のロックを取得する必要があります。そして、資源を使い終わったらロックを解放します。あるプロセスがロックを取得している間は、別のプロセスは同じロックを取得することができません。よって、ロックを取得できたときのみ資源を使用するようにプログラムを書くことによって、資源に対する競合を防ぐことができます。 典型的には、使用したい資源が他のプロセスに使用されている場合、その資源のロックが解放されるまで待つことにな
まだXMLHttpRequestを使ってるの？ fetchのすすめ
JavaScriptでWeb的なプログラムを書いたことがある人は、XMLHttpRequestを使った経験もあるのではないかと思います。XMLHttpRequest，略してXHRは、JavaScript（+DOM）でサーバーとHTTP通信をするための唯一の方法としての地位を長らく保ってきましたが1、ここ3〜4年でより新しいAPIであるfetch APIが登場しました。fetch APIが出たばかりの頃は何だこのおもちゃはと正直思いましたが、いつの間にか仕様が充実していい感じになっていました。 皆さんは、この新しいAPIであるfetchをちゃんと使っているでしょうか。それとも、古いXHRを未だに使っているのでしょうか。この記事では、未だにfetchを使っていない人を主な対象としてfetchの使い方を解説します。（XHRと比較しながら解説するので$.ajaxとかaxiosとかしか使ったことがな
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
JavaScriptの関数名の全て - Qiita