イベントハンドラの関数名についての雑記 - Qiita
今日のXでは、イベントハンドラの関数名についての話題を見ました。元の投稿はこちらです。要するに、次のhandleClickのようなhandleイベント名という命名は良くないということです。 const handleClick = () => { ... }; <button type="button" onClick={handleClick} /> これについて少し考えたので、せっかくなのでアウトプットしておくことにしました。 この記事の目的 考えたことを頭の中に残しておくのがもったいないので、文章の形にしておく。 色々な意見が出る問題であり、ベストな答えは無いので各々好きにすれば良いということを、読者に理解してもらう。 とはいえ、筆者の考えに納得して同じ考えの人が多いと嬉しいので、なるべく納得してもらう。 筆者の考え 自分の考えとしては、むしろhandleClickいいじゃん！ どんど
イベントハンドラの関数名についての雑記 - Qiita
今日のXでは、イベントハンドラの関数名についての話題を見ました。元の投稿はこちらです。要するに、次のhandleClickのようなhandleイベント名という命名は良くないということです。 const handleClick = () => { ... }; <button type="button" onClick={handleClick} /> これについて少し考えたので、せっかくなのでアウトプットしておくことにしました。 この記事の目的 考えたことを頭の中に残しておくのがもったいないので、文章の形にしておく。 色々な意見が出る問題であり、ベストな答えは無いので各々好きにすれば良いということを、読者に理解してもらう。 とはいえ、筆者の考えに納得して同じ考えの人が多いと嬉しいので、なるべく納得してもらう。 筆者の考え 自分の考えとしては、むしろhandleClickいいじゃん！ どんど
まだ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とかしか使ったことがな
React脳によるUIライブラリ書きやすさランキング - Qiita
前回のおさらい 前回の記事では、Reactに有利なベンチマークでUIライブラリに競ってもらいました。 こういうベンチマークに対しては、「実務では〜」みたいな反応が一定数出てくるのが自然の摂理です。 書きやすさランキング そこで、シリーズのまとめとして、より実務に近い指標として「書きやすさ」で競ってもらおうと思います。ただし、今回は筆者の独断と偏見によるランキングとなります。せっかく6つのライブラリで同じアプリケーションを書いたので、感想を記事にして残しておきたいという意図です。筆者と同じくReact脳の方にとっては参考になるかもしれません。 なお、前の記事を読んだ方はお分かりの通り、今回書いたアプリケーションはコンポーネントが何個かのものであり、React以外の知識は公式ドキュメントを一通り読んだ程度です。したがって、今回のランキングはコンポーネントの書きやすさに着目しています。大規模開発
Reactに有利なベンチマークを作ってみた - Qiita
皆さんこんにちは。現在、フロントエンドでは宣言的UIが大流行しており、そのためのライブラリもReactを筆頭に複数存在しています。 ライブラリが複数存在するところには当然のように比較や論争が起こるものですが、UIライブラリの場合はパフォーマンスがよく焦点となります。 筆者はReactの信者ですが、Reactは古株ということもあってか、最近の議論ではReactは他のライブラリと比較されるかませ犬のような役割を担うのがよく見られます。「仮想DOMは必要ない」といった類のものです。 しかし、筆者の考えではReactは今でも、もっとも真剣にパフォーマンスに取り組んでいるUIライブラリです。特に、Reactはパフォーマンスを高いユーザーエクスペリエンスのための手段として捉えており、ドキュメントにもユーザーエクスペリエンスという言葉が多く出てきます。 そこで、今回はReactが最も有利になるようなベン
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
top-level awaitがどのようにES Modulesに影響するのか完全に理解する - Qiita
先日、TypeScript 3.8 RCが公開されました。TypeScript 3.8はクラスのprivateフィールド（#nameみたいなやつ）を始めとして、ECMAScriptの新機能のサポートがいくつか追加されています。この記事で取り扱うtop-level awaitもその一つです。 この記事ではtop-level awaitに焦点を当てて、その意味や使い方について余すところなく解説します。top-level awaitは一見単純な機能に見えますが、実はモジュール (ES Modules) と深い関係があり、そこがtop-level awaitの特に難しい点です。そこで、この記事ではECMAScriptのモジュールについても詳しく解説します。この記事を読んでtop-level awaitを完全に理解して備えましょう。 ※ この記事は3分の1くらい読むと「まとめ」があり、残りはおまけで
アンサー： なぜTypeScriptの型定義に凝るのか - Qiita
この記事は、昨日公開された以下の記事に対するアンサー記事です。TypeScriptで型定義に凝る派筆頭（自称）として、このお題に対して別の視点から光を当ててあげるためにこの記事を用意しました。 TypeScript の型定義に凝りすぎじゃね？ まず最初に、この記事（以下では元記事と呼びます）の著者を攻撃したり、元記事の内容を否定する意図はないことをご理解ください。結局のところ、考え方が異なり、前提が異なるから異なる結論になっているだけなのです。TypeScriptを使う皆さんがいろいろな観点から見た情報を取得し、自分の状況に応じた適切な考え方・判断をできるようにすることがこの記事の目的です。 要約 大きなコードを小さく分解しても本質的な難しさが消えるわけではないよ？ 型はドキュメントなんだから正確に書こうぜ！ 外界との接続も妥協せずに型システムで解決しようぜ！ 機械にできる仕事を人間がする
JavaScriptの等値比較を全部理解する - Qiita
皆さんこんにちは。今回の記事ではJavaScriptの等値比較について見ていこうと思います。 「どうせ==と===の違いとかだろ？ 今さらそんな記事書くなよバーカｗ」と思った人はぜひ期待せずに読み進めてみてください。 「じゃあObject.isでしょ？ 知ってる知ってる、使ったことないけど」と思った人はまあ読まなくても大丈夫です。 さて、等値比較というのは、2つの値が等しいかどうか判定することです。JavaScriptにおいて等値比較はどのように行うのか、そしてどのような場面で等値比較が発生するのかをこの記事では余すことなく紹介します。 以降、この記事で仕様書という場合はECMAScript® 2018 Language Specificationを指すものとします。 ==と=== とはいえ、まずは==と===の話をしないことには始まりません。==はJavaScript初心者がとりあえず習
JavaScriptの { } を理解する - Qiita
結果はどうなったでしょうか。 自分が今使っているGoogle Chromeだとこうなりました。 結果は{a: 10}というオブジェクトです。まあ、これは当然ですね。3 + 5と入力すれば実行されて8が返ってくるのですから、{a: 10}というオブジェクトリテラルを書けば{a: 10}というオブジェクトが作られるのは当然です。 ……。 ここで、一部の人は「おいふざけんなよ」と思っているかもしれません。というのも、この例は環境によっては違う結果になるのです。具体的には、Chrome以外2のブラウザのREPL（FirefoxやEdgeなど）が該当します。あと、ts-nodeのREPLも該当するらしいです。これらの環境では、結果は{a: 10}ではなく次のようになります。 オブジェクトを作ったはずなのに結果が10とか意味不明ですね。そもそも、こんな簡単なプログラムで結果が全然違うとか、JavaSc
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
