ReactのuseEffectは、フックの中でも使い方が難しいものの一つです。そこで、この記事では筆者が考えるuseEffectの望ましい使い方を皆さんに伝授します。 基本原則 技術やその要素の使い方を考えるにあたって、筆者が好んでいるのは基本原則を置いてそれに基づいて判断することです。ということで、この記事ではまず筆者が考えるReactの基本原則を紹介します。 筆者がもっとも重要視する原則は、ReactはUIライブラリであるということです。つまり、ReactにはUIの管理をさせるべきであって、その他のことはReactの役目ではないということです。Reactが難しいと思う人がいる場合、何でもかんでもReactにやらせようとするから余計に難しくなっているのだと思います。 例えばアプリケーションのロジックの管理やそれに付随するステートの管理はReactの役目ではないので、Reactの外部で処理
皆さんこんにちは。筆者は先日、TypeScript向けライブラリのts-array-lengthを公開しました。 この記事ではこのライブラリを宣伝するとともに、ライブラリの実装がどのようになっているのか解説します。 ts-array-lengthの機能 ts-array-lengthは3つの関数を提供しており、これらを使うことでなんと配列の要素数をチェックできます。 例えばhasLengthを使うと、配列の要素がちょうど2個かどうか調べることができます。 if (hasLength(arr, 2)) { // arrは2要素の配列！ const [first, last] = arr; }
TypeScript でプログラミングをしていると、existential type （存在型）が欲しくなることがあります。そのような課題が発生した際は anyやasを使って何とかしてしまいがちですが、実はある種のカプセル化を行うことでこれらの危険な機能を使わずに解決することができます。 Existential Type が欲しくなる例 簡単な例として、こんなプログラムを書きたい場合を考えてみましょう。ここではまだ型は書いていません。 function useNumber(num: number) { console.log(num); } function useString(str: string) { console.log(str); } const thunks = [ [3, useNumber], ["foo", useString], [10, useNumber], ];
昨今のフロントエンド開発では、データをイミュータブルなオブジェクトとして扱うのが主流です。すなはち、データが変わるときはオブジェクトを書き換えるのではなく、新しいデータを持った新しいオブジェクトを作ります。最近ではオブジェクトがデータとしてプログラムのあちこちで取り回されることが増えて、一度余所に渡されたデータの中身が後から変更されるのは混乱をきたし設計が困難になるというのが主な理由です。 データを変更するたびに新しいオブジェクトを作るのは、特にデータが複雑になったりネストしたりしていると面倒だしプログラムの見通しが悪くなります。そこで使われるのが、データをイミュータブルに扱うためのライブラリであるImmutable.jsとImmerです。 データをイミュータブルなものとして扱うという目的はどちらのライブラリでも達成することができますが、現在では Immer のほうが開発が活発であり、独自
今日発表された公式ブログの記事によれば、React17では新しいJSXの変換がサポートされます。これはどういうことなのか、我々にどういう影響があるのかをまとめました。 JSXの変換とは ほとんどの人は、Reactを使う際に以下のようなJSX記法を使っているはずです。具体的には次のようなもので、<div>のようなHTMLに近い記法がJSXです。 const Foo = () => { return <div> <p id="a">I am foo</p> <p key="b">I am foo2</p>> </div>; } これらは純粋なJavaScriptではないため、そのままでは実行できません。そのため、何らかの方法でただのJavaScriptに変換する必要があります。現代では、それを担うのはBabelやTypeScriptです。これらによって、上記のJSXを含むコードは次のように変換
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く