UIコンポーネントの大きさは外から制御しよう - Qiita
昨今のフロントエンド向けUIライブラリでは、コンポーネントの設計が重要です。この記事では、コンポーネントのスタイリング、その中でもとくにコンポーネントの大きさに関わるコンポーネント設計について考えます。 私の考える結論は、むやみに大きさを指定できるpropを生やさずに、CSSで外から大きさを制御できるようにしたほうがいいです。 コンポーネントの大きさを制御したい UIの一部分を再利用可能なコンポーネントとする場合、同じコンポーネントがさまざまな場面で使えるのが望ましいでしょう。コンポーネントが提供する機能にもよりますが、場面に応じてさまざまな大きさでコンポーネントを使用できたほうがよいこともあります。 具体例として、このようなコンポーネントを考えてみましょう。例はReactで示しますが、この記事の内容はReactとは関係ありません。 const Card: React.FC<React.P
React脳によるUIライブラリ書きやすさランキング - Qiita
前回のおさらい 前回の記事では、Reactに有利なベンチマークでUIライブラリに競ってもらいました。 こういうベンチマークに対しては、「実務では〜」みたいな反応が一定数出てくるのが自然の摂理です。 書きやすさランキング そこで、シリーズのまとめとして、より実務に近い指標として「書きやすさ」で競ってもらおうと思います。ただし、今回は筆者の独断と偏見によるランキングとなります。せっかく6つのライブラリで同じアプリケーションを書いたので、感想を記事にして残しておきたいという意図です。筆者と同じくReact脳の方にとっては参考になるかもしれません。 なお、前の記事を読んだ方はお分かりの通り、今回書いたアプリケーションはコンポーネントが何個かのものであり、React以外の知識は公式ドキュメントを一通り読んだ程度です。したがって、今回のランキングはコンポーネントの書きやすさに着目しています。大規模開発
TypeScriptのmoduleSuffixesについて考えて納得した - Qiita
みなさんこんにちは。今日は、TypeScriptの新しいコンパイラオプション（おそらく4.7で導入）であるmoduleSuffixesについての話題がTwitterで見られました。 moduleSuffixesについて詳しくはこちらをご参照ください。 これについては、「モジュール解決がさらに複雑化する」などいくつかの方向性から否定的な意見が見られました。しかし、筆者が考えてみたところ、正当性のある機能追加だと納得できたので考えをご紹介します。 3行でまとめると これまで通りランタイムの挙動に影響しないから大丈夫だよ pathsが怖くないならmoduleSuffixesも怖くないよ TypeScriptはJavaScript環境に追随するよ moduleSuffixesとは では、moduleSuffixesはどんなコンパイラオプションなのかという解説をまず少しします。これはTypeScri
結局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を使う皆さんがいろいろな観点から見た情報を取得し、自分の状況に応じた適切な考え方・判断をできるようにすることがこの記事の目的です。 要約 大きなコードを小さく分解しても本質的な難しさが消えるわけではないよ？ 型はドキュメントなんだから正確に書こうぜ！ 外界との接続も妥協せずに型システムで解決しようぜ！ 機械にできる仕事を人間がする
2021年のTypeScript環境構築で絶対入れるべき「better-typescript-lib」の紹介 - Qiita
こんにちは。この記事は筆者が開発した「better-typescript-lib」を宣伝する記事です。これは、導入するだけでTypeScriptプログラムがより型安全になるという素晴らしいライブラリです。あくまで型定義なので、導入してもランタイムの挙動は何も変わらず、バンドルサイズなどへの影響もありません。 better-typescript-libの導入法 ここに記載されているのはv1 (TypeScript 4.0 〜 4.4向け）のインストール方法です。v2 （TypeScript 4.5〜）ではインストール方法が変わり、最初のnpm installのみで良くなります。詳しくは次の記事をご覧ください。
TypeScriptでMapped Typesを使ってきれいなインターフェースを作る話 - Qiita
みなさんこんにちは。この記事はTypeScript Advent Calendar 2020の5日目の記事です。 TypeScriptにはintersection typeという機能があります。これはT & Uのような構文をもつ型であり、意味としては「TでもありUでもある型」です。 構造的部分型とIntersection Type 「TでもありUでもある」という説明の仕方をされるとIntersection Typeが何の役に立つのかピンと来ないという方がいるかもしれません。実際のところ、Intersection Typeはオブジェクト型を合体するという役割によく使われます。 例えば、Tが{ foo: string }型でUが{ bar: number }型だった場合、T & Uは実質上{ foo: string; bar: number }型となります。 type T = { foo: s
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するということ自体に焦点
TypeScriptのunion型はorです 〜union型、構造的部分型、余剰プロパティチェックの話〜 - Qiita
TypeScriptのunion型はorです 〜union型、構造的部分型、余剰プロパティチェックの話〜TypeScript 先日、「TypeScriptのunion型はorではない」とする以下の記事が公開されました。 TypeScript の共用体型（Union Types）は or ではない 残念ながら筆者はこの主張に同意できないので、この記事では上記の記事に含まれる問題点を指摘しつつ、正しい結論を導きます。 この記事の目的はあくまで正しい情報を皆さまに届けることであり、上記の記事（以下では「元記事」と呼びます）の筆者を攻撃する意図は無いことをご理解ください。 では、元記事からコードを引用しながら何がまずいのかを見ていきましょう。 元記事の主張 元記事の最初のコードを引用します。
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くらい読むと「まとめ」があり、残りはおまけで
useReducerの本質：良いパフォーマンスのためのロジックとコンポーネント設計 - Qiita
React Hooksの正式リリース（2019年2月）からそろそろ一年が経とうとしています。Hooksの登場によってReactのコンポーネントは関数コンポーネントが一気に主流になり、クラスコンポーネントが新規に作られる機会は激減しました。 また、React 17.x系ではConcurrent Modeの導入とともにさらに2種類の新フックが追加される見込みであり、いよいよ関数コンポーネントの能力がクラスコンポーネントを真に上回る時代が来ることになります。 この記事では、フックの一種であるuseReducerに焦点を当てて、どのようなときにuseReducerが適しているのかを説明します。究極的には、useReducerによって達成できるパフォーマンス改善があり、ときにはそれがコンポーネント設計にまで影響を与えることを指摘します。 useStateの影に隠れたり、なぜかReduxと比較されたり
そろそろJavaScriptに採用されそうなOptional Chainingを今さら徹底解説 - Qiita
みなさん、Optional Chaining使ってますか？ 私は先日出たTypeScript 3.7 Betaを小さいプロジェクトに導入して使ってみました。これはとても快適ですね。 例によって、Optional ChainingはECMAScriptに対するプロポーザルの一つです。つまり、もうすぐ入りそうなJavaScriptの新機能です。プロポーザルはたくさんの種類がありますが、その中でもOptional Chainingはその高い有用性からこれまで多くの注目を集めてきました。Optional Chainingは2019年6月のTC39ミーティングでStage 3に上昇し、いよいよ正式採用が近く期待も高まってきたところです。TypeScript 3.7にも導入されたため、TypeScriptユーザーの方々は11月上旬に正式リリースが予定されているTypeScript 3.7を今か今かと待
全部言えたらDOMマスター！ HTML+DOMでノードを挿入する方法大全 - Qiita
DOMはHTMLの木構造(あとXMLも）やイベント等をプログラムから操作するためのAPIです。DOMの実装者として有力なのがウェブブラウザであり、ブラウザが提供するDOMのAPIを用いてJavaScriptプログラムからウェブページを制御するというのがDOMの極めてメジャーな使い道です。 近年知名度を増してきたReactやVueなどのライブラリも、もちろんこのDOMを用いて実装されています（Reactだとreact-domというあからさまな名前のパッケージがDOMを扱う部分を担当しています）。 この記事では、DOMで提供されるAPIを用いて木構造にノードを挿入する方法全38種類を列挙します。 ノードの挿入とは DOMにおいて基本的な操作のひとつがノードの挿入です。ノードというのは木構造の最小構成単位であり、要素ノードやテキストノードなどの種類があります。例えば<u>は</u>というのはu要
JavaScriptの関数名の全て - Qiita
JavaScriptに限った話ではありませんが、関数というのは名前を持っていたり持っていなかったりします。関数名は普通はプログラムの読みやすさくらいにしか影響しませんが、JavaScriptでは必ずしもそうではありません。 例えばReactで関数コンポーネントを使う場合は関数名がコンポーネント名となり、React用開発者ツールなどで見ることができデバッグに役立ちます。また、Gulp v4もエクスポートした関数名がタスク名となります。 関数名は、関数オブジェクトのnameプロパティで取得できます。 function foo() { console.log('foo!'); } console.log(foo.name); // "foo"
TypeScriptの型入門 - Qiita
TypeScriptは型がついたJavaScriptです。プログラミングにおいて型があることの恩恵は大きく、近頃AltJSの代表格として人気を集めています。TypeScriptはもともと型のないJavaScriptで書かれるコードに型を付けることを使命としていることもあり、たまに変な型が追加されます。例えばTypeScript2.8で追加されたconditional typesはずいぶん注目を集めました。これによってTypeScriptの型システムの表現力が広がりましたが、一方でTypeScriptを書いている人の中には、よく分からない型が増えてついて行けない、一部の人たちが長くてよく分からない型定義を書いて喜んでいるだけと思っている方もいるのではないでしょうか。実際、健全にJavaScriptを書いていれば、自分でそのような変な型を書くことはあまり多くありません。 そこで、この記事ではT
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
あなたの知っている正規表現はもう古い！ 正規表現の新常識（ES2018編） - Qiita
2018年1月23日から25日にかけて、TC39の第62回ミーティングが行われました。TC39のミーティングでは、提案されているECMAScriptの新機能 (proposal) について審議し、各proposalのステージの移動を決定します。 今回のミーティングでは正規表現に関する幾つかのproposalがStage 4になりました。Stage 4になったproposalはES2018に組み込まれ、JavaScript (ECMAScript) に正式採用ということになります。 この記事では、JavaScriptに追加された正規表現の4つの新機能を紹介します。 s (dotAll) flag for regular expressions Proposal: https://github.com/tc39/proposal-regexp-dotall-flag 正規表現の新たなフラグとし
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
