並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 40 件 / 44件

新着順 人気順

uhyoの検索結果1 - 40 件 / 44件

タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。

uhyoに関するエントリは44件あります。 TypeScriptjavascriptreact などが関連タグです。 人気エントリには 『React ステート管理 比較考察 - uhyo/blog』などがあります。
  • React ステート管理 比較考察 - uhyo/blog

    こんにちは。Reactの話題の中でもかなりの部分を占めるのがステート管理、さらに言えば各種のステート管理ライブラリです。今さらながら、Reactにおけるステート管理の手法やいくつかのステート管理ライブラリを比較考察して記事にまとめました。 useState + バケツリレーReactにおける基本的なステート管理はuseStateです。ひとつのコンポーネント内で完結するようなステートならばuseStateは非常に適しており、他の選択肢はほぼ無いと言っても構わないでしょう。 ステートをアプリケーションの広範囲で使いたい場合が問題です。次の画像に例示されるように、分岐したコンポーネントツリーの末端のコンポーネント(使用者)で同じステートを参照したい場合を考えます。 useStateと組み合わせる場合、もっとも原始的な方法はpropsのバケツリレーによるものです。propsは親コンポーネントから子

      React ステート管理 比較考察 - uhyo/blog
    • Facebook製の新しいステート管理ライブラリ「Recoil」を最速で理解する - uhyo/blog

      昨日、Facebook製のReact用ステート管理ライブラリRecoilが発表されました。Facebook製といってもReact公式のステート管理ライブラリとかそういう位置付けではないようですが、それでも大きな注目を集めているのは間違いありません。 そこで、筆者がRecoilに対して思ったことや、筆者の視点から見たRecoilの特徴を記事にまとめました。 なお、この記事の執筆時点では副作用の扱いなどの点はいまいち情報が揃っていません。この記事では速報性を重視し、コアのステート管理部分に絞って考えています。また、まだexperimentalなライブラリなので、今後この記事の内容からRecoilのAPIが変化したとしても悪しからずご了承ください。 この記事を書くときに筆者が色々試していたCodeSandboxはこちらです。 https://codesandbox.io/s/recoil-san

        Facebook製の新しいステート管理ライブラリ「Recoil」を最速で理解する - uhyo/blog
      • 積極的な技術選定と消極的な技術選定 - uhyo/blog

        この記事は、筆者が技術選定について思うところをまとめた記事です。Twitterに同じ話を何回か書いているので、文章にまとまっていたほうがよいと思い用意しました。 やや過激な思想で愚痴も含んでいるので、共感いただけると嬉しいものの、みなさんを説得しようというつもりはありません。こいつはこういう考え方なんだなという心持ちでお読みください。 積極的な技術選定と消極的な技術選定ITエンジニアの方々の中には、技術選定をする立場の方も多いでしょう。技術選定にあたってはさまざまな事情を勘案しなければならない難しいもので、それだけに多くの人が技術選定に関する各々の考えを述べています。 筆者は、技術選定における意思決定のプロセスは、積極的な技術選定と消極的な技術選定の2種類があるのではないかと思っています。 積極的な技術選定は、選定される(あるいはされない)技術そのものが原因となる意思決定です。 一方、消極

          積極的な技術選定と消極的な技術選定 - uhyo/blog
        • 書評『TypeScriptとReact/Next.jsでつくる 実践Webアプリケーション開発』 - uhyo/blog

          皆さんこんにちは。今回は、2022年7月25発売の『TypeScriptとReact/Next.jsでつくる 実践Webアプリケーション開発』を読み終わったので、書評という形で感想と紹介を述べたいと思います。筆者はもともと技術書を読まず「ネットでいいやん」派だったのですが、このたびTypeScript入門書を出版したこともあり、それを過去の話として葬り去るべく技術書を読んでいくことにしました。せっかくなので、読んだ技術書の感想等を紹介します。 おことわり: この記事では、「筆者」とはこの書評を書いた人を指し、『TypeScriptとReact/Next.jsでつくる 実践Webアプリケーション開発』を書いた人たちのことは「著者ら」と呼びます。また、この記事の内容はすべて筆者の個人的な見解であり、本の内容や本を読んで得られる知識について何らかの保証をするものではありません。 筆者について筆者

            書評『TypeScriptとReact/Next.jsでつくる 実践Webアプリケーション開発』 - uhyo/blog
          • 書評『HTML解体新書』 - uhyo/blog

            皆さんこんにちは。今回は、2022年4月19日発売の『HTML解体新書』を読み終わったので、書評という形で感想と紹介を述べたいと思います。筆者はもともと技術書を読まず「ネットでいいやん」派だったのですが、このたびTypeScript入門書を出版したこともあり、それを過去の話として葬り去るべく技術書を読んでいくことにしました。せっかくなので、読んだ技術書の感想等を紹介します。 おことわり: この記事では、「筆者」とはuhyoのことを指し、『HTML解体新書』の筆者たちのことは「著者ら」と呼びます。また、この記事の内容はすべて筆者の個人的な見解であり、本の内容や本を読んで得られる知識について何らかの保証をするものではありません。 筆者について筆者はTypeScriptとReactを専門とするフロントエンドエンジニアで、HTML歴は17年です。物心ついたときのHTMLバージョンはHTML4.01

              書評『HTML解体新書』 - uhyo/blog
            • どのようにTypeScriptを使うのか - uhyo/blog

              現在、TypeScriptの重要性は、フロントエンド開発を中心としてますます増すばかりであります。それだけに、TypeScriptをどのように使うべきかという問題については多様な意見が見られます。 これまで筆者はTypeScriptの使い方に、特にコンパイラオプションの使い方について意見を散発的に発信してきましたが、このたび記事にまとめました。この記事では、特に次のような意見に対しての反対意見を述べます。 厳しいコンパイラオプションは型パズル愛好者のためのものであり、普通の人は細かいことを気にせず緩い設定でよい。熟練のJavaScript使いにはTypeScriptは必要ない。例え話最近はTypeScriptを補助輪に例えたりするのが流行っていますので、この記事でも例え話をしてみます。筆者の考えでは、TypeScriptというのは例えるならば料理人が使う包丁のようなものです。コンパイラオプ

                どのようにTypeScriptを使うのか - uhyo/blog
              • 書評『良いコード/悪いコードで学ぶ設計入門』 - uhyo/blog

                皆さんこんにちは。今回は、2022年4月30発売の『良いコード/悪いコードで学ぶ設計入門』を読み終わったので、書評という形で感想と紹介を述べたいと思います。筆者はもともと技術書を読まず「ネットでいいやん」派だったのですが、このたびTypeScript入門書を出版したこともあり、それを過去の話として葬り去るべく技術書を読んでいくことにしました。せっかくなので、読んだ技術書の感想等を紹介します。 おことわり: この記事では、「筆者」とはこの書評を書いた人を指し、『良いコード/悪いコードで学ぶ設計入門』を書いた人のことは「著者」と呼びます。また、この記事の内容はすべて筆者の個人的な見解であり、本の内容や本を読んで得られる知識について何らかの保証をするものではありません。 筆者について筆者はフロントエンドエンジニアで、TypeScriptとReactを専門としています。業務では何だかんだで設計の番

                  書評『良いコード/悪いコードで学ぶ設計入門』 - uhyo/blog
                • こわくないTypeScript〜Mapped TypeもConditional Typeも使いこなせ〜 - uhyo/blog

                  TypeScriptの型システムは、ユニオン型を始めとする様々な機能を持っているのが特徴的です。 その中でも、mapped typesとconditional typesは高度な機能として知られています。 ところが、その機能の膨大さゆえ、全てを使いこなす必要はない、TypeScriptの複雑な機能を無闇に使うべきではないという言説はたびたび現れます。 そのときに槍玉に上がりやすいのがmapped typesとconditional typesなのです。 筆者は、これらの機能は使えるだけ使い倒すべきであるという考えを持っています。 主張の根幹には、高度な型を使えばより正確にインターフェースを記述することができること、そして正確なインターフェースは使いやすさや正確な型推論結果に貢献することがあります。 正確なインターフェースや型推論結果は、コードの理解速度や開発効率を促進します。 これらは型シ

                    こわくないTypeScript〜Mapped TypeもConditional Typeも使いこなせ〜 - uhyo/blog
                  • CSSとコンポーネント設計に対する考察 - uhyo/blog

                    近年のフロントエンド開発にはコンポーネントという概念が付いて回ります。React・Vue・AngularといったViewライブラリでは、コンポーネントを定義してそれを組み合わせてアプリを作ります。また、いわゆるWeb Componentsとして知られる仕様群により、ライブラリに依存せずに“コンポーネント”を作ることもできるようになってきています。 コンポーネントは、何らかの機能(あるいは責務)を持った部品です。また、コンポーネントによっては再利用される(アプリ内の複数の箇所から利用される)ことを意図しているものや、そもそもライブラリとして配布されているようなものもあります。アプリの機能の一部分を抜き出したものという見方をすれば、コンポーネントというのは関数にとても類似した概念であることが分かります。 コンポーネント設計によって、言い換えればアプリがどのような機能を持ったコンポーネントたちに

                      CSSとコンポーネント設計に対する考察 - uhyo/blog
                    • useCallbackはとにかく使え! 特にカスタムフックでは - uhyo/blog

                      Reactには、パフォーマンス最適化のためのAPIがいくつかあります。具体的にはReact.memo、useMemo、そしてuseCallbackです。 React.memoで囲まれた関数コンポーネントは、propsが以前と変わっていない場合に再レンダリングが抑制されます。 また、useMemoやuseCallbackは、関数コンポーネント内での値の再計算を抑制する効果を持ちます。 これらは最適化のためのツールなので、「過度な最適化」を避けるように啓蒙する言説がよく見られます。 すなわち、ちゃんと本当に最適化のために必要なところにだけこれらを使おうということです。 特に、React.memoはpropsが以前と変わっているかどうかを判定するためのオーバーヘッドがあるし、useMemoやuseCallbackもフック呼び出しのオーバーヘッドがあります。 意味がないところでReact.memo

                        useCallbackはとにかく使え! 特にカスタムフックでは - uhyo/blog
                      • Tailwind考 - uhyo/blog

                        皆さんこんにちは。最近とある事情でTailwind CSSにわりと真剣に向き合わないといけなくなった筆者です。 Tailwind CSSの話題は、Twitterのフロントエンド界隈では定番のトークテーマのひとつです。しかし、筆者の考えを文章にまとめたことは無かったので、このたびブログ記事にすることにしました。 結論筆者が一番みなさんに伝えたいことは、Tailwind CSSは考え無しに採用してよい技術ではなく、採用するには熟慮が必要だということです。とくに、フロントエンドのスターターキット的なプロジェクトの中にTailwind CSSが混ざっていることがありますが、あれはけっこうな罠です。気軽に採用すべきものではありません。 筆者の考えでは、Tailwind CSSの採用を考慮に入れてよいのは次の2つの場合です。 デザインにこだわりがなく、最低限整っていればいい場合。デザイナー不在のプロジ

                          Tailwind考 - uhyo/blog
                        • まとまったCSSを別のコンポーネントに分けないでほしい話 - uhyo/blog

                          この記事は、ReactでCSSを書くときに関連したCSSを別々のコンポーネントに分けるのをやめようという記事です。主な理由は、スタイリングという機能が複数コンポーネントに分散するのを防ぐためです。これには修正時に複数コンポーネントにまたがって修正が必要になるのを防ぐという意味もあります。 Flexboxの例関連したCSSが複数の要素に分かれることはよくあります。その代表例がdisplay: flexです。例えばこんなレイアウトを考えてみましょう。左側のボックスの幅が決まっていて右側の幅が可変の2カラムレイアウトです。 左のカラム (100px)右のカラムこのレイアウトはおおよそ次のように実現できます。 /* 親要素 */ display: flex; /* 子要素(左) */ flex: 100px 0 0; /* 子要素(右) */ flex: auto 1 0;では、Reactではどの

                            まとまったCSSを別のコンポーネントに分けないでほしい話 - uhyo/blog
                          • 空のdiv要素について - uhyo/blog

                            昨日はこちらの記事に端を発する形で、空のdiv要素やspan要素は妥当なのかといった話題が見られました。 中身のない空の div 要素や空の span 要素は HTML 仕様として妥当なのか? - dskdこの記事は空のdiv要素やspan要素が妥当かどうかという疑問にHTML仕様の観点から考察を加える大変面白い記事です。記事の結論としては、“僕の結論としては「否」である。”としています。 しかし、いくらHTML仕様を読んだといっても、こういった議論には解釈が入りがちです(こちらの記事でも結論の前に“ここからは完全に僕の解釈として書く。”と明記されています)。 仕様なのに解釈を入れる必要があるのはどうなのと思いつつ、実はこの記事でこれから紹介するように、HTML仕様もなかなか曖昧に書かれており解釈が必要なのは仕方のないことです。 筆者はどちらかというと空のdivを肯定する考えを持っていたの

                              空のdiv要素について - uhyo/blog
                            • ████を退職します - uhyo/blog

                              この記事はuhy.oooでも読むことができます。 ████を退職します皆さんこんにちは。この度、████を退職することになりましたのでご報告します。 筆者は2019年に新卒で████に入社して、今年が4年目でした。今回が初めての転職となります。転職先は███という会社です。 ████はどうだったか一言で言えば、良いところでした。特に、チームメンバーと上司に恵まれ、快適かつとても自由な環境で働くことができました。 快適というのはいくつかの側面があります。自分としては、大きい会社ならではの整った社内制度・社内システムは魅力的でした。これにより、事務的な作業はなるべく事務的かつ簡潔に済ませられるようになっていて業務に集中できます。他には、プロジェクトメンバーとのコミュニケーションにおいてストレスを感じることもあまり無く(██████████████████████)、これだけ良い人ばかり集まって

                                ████を退職します - uhyo/blog
                              • ████に入社して1年が経ちました - uhyo/blog

                                およそ2年前、新卒としての就活が終了したことを報告する記事をはてなブログに書きました(████に入社します)。ちゃんと2019年4月から████に入社して今まで働いていたのですが、そういえば入社したタイミングでは特に記事を出したりしていませんでしたね。2019年4月の入社から1年と少しが経ちましたので、このタイミングでここまでの道のりを少し振り返ってみることにしました。 今何をしているのか新卒として████に入社して、██日程度の研修ののちに████████████に配属されました。そのチームでおよそ1年ほど██████のフロントエンド開発に携わっています。██████は████の中でも比較的███な████を取っており、いくつかの████████が████████████████████████。その中でも自分は████████という████において██████にあり、新卒███████

                                  ████に入社して1年が経ちました - uhyo/blog
                                • アンサー: named exportは有害なのか - uhyo/blog

                                  こんにちは。ここ数日は、以下の記事が話題になりました。 named exportは有害だと考えられます「named exportは有害」という主張はこれまで常識と思われていたこととは異なるため、界隈のエンジニアからは否定的・懐疑的な意見が見られます。実際、筆者もnamed exportが有害であるとは1ミリグラムも思っていません。 しかし、自分と異なる意見は当然に下等・幼稚なものであるというのは筆者が最も嫌う考え方ですから、このような異なる意見を分析・理解する必要があると思い、アンサー記事という形でまとめました。具体的には、異なる意見に達する理由としては前提が異なることと論理が異なることが主に挙げられます。前提が異なることが分かれば、自分と異なる意見に至った理由を理解でき、場合によっては取り入れることもできます。論理が違うのであれば、それは瑕疵であり指摘しなければいけません。 なお、そもそ

                                    アンサー: named exportは有害なのか - uhyo/blog
                                  • Twitterアカウントが凍結された - uhyo/blog

                                    こんにちは。先日からTwitterアカウント@uhyo_が🈚️になっており、皆さまにご心配をおかけしています。 「なぜ」「TypeScript界隈が衰退した」など数十件もの心温まる反応に励まされております。また、凍結中に技術記事「TypeScript 4.5でますます便利に! better-typescript-lib v2」を公開しましたが、皆さまの拡散などのご協力もあり普段と遜色ない反響を得ています。本当にありがとうございます。 この記事はアカウント凍結に関する公式見解をお届けします。 追記: 記事公開翌日の15時に凍結が解除されました。拡散などのご協力並びに異議申し立てへの対応ありがとうございました。凍結解除の理由については「システムによる誤検知」と説明されました。 TL;DR事実無根の理由で凍結された異議申し立てしたが音沙汰無し(記事公開時現在7営業日)激おこ凍結時期と理由アカウ

                                      Twitterアカウントが凍結された - uhyo/blog
                                    • JavaScriptのthisは結局何種類あるのか - uhyo/blog

                                      JavaScriptのややこしい機能としてよく槍玉に挙げられるのがthisです。その特徴のひとつは状況によって意味(thisの値)が違うことであり、これを指して「JavaScriptのthisは4種類」とする説も見られます。 そこで、この記事ではthisが何種類あるのか、ECMAScript仕様書を頼りに調べます。ECMAScript仕様書とはJavaScriptという言語を定義する文書であり、JavaScriptのthisがどのような挙動をするのかも当然定義されています。今回は仕様書の2020年5月26日版ドラフトを参照します。 https://tc39.es/ecma262/結論としては、最も大ざっぱに分けると3種類、最も細かく分けると157種類です。この記事では全種類漏れなくサンプルコード付きで説明します(似たようなやつはまとめて説明します。また、一部観測不能なものがあります)。 ス

                                        JavaScriptのthisは結局何種類あるのか - uhyo/blog
                                      • ユーザー定義型ガード、asで書くかanyで書くか - uhyo/blog

                                        TypeScriptでユーザー定義型ガードを定義する場合、引数をany型にして中を自由に書く方法と引数をunknown型にして中でasを駆使して書く方法があります。この記事では両者を比較考察します。結論としては、unknownとasを使うのが型安全性の面からおすすめです。また、うまく関数を分割することでasを消すことも可能で、これも有効です。 ユーザー定義型ガードとはTypeScriptのユーザー定義型ガードとは、型の絞り込み (type narrowing) に使うことができる関数です。ユーザー定義型ガードは返り値が引数名 is 型のような形の型述語 (type predicate) になっています1。このような関数は真偽値を返り値として返し、trueを返すならば引数名が型であることを表します。 例えば、与えられた値がstring | number型かどうか調べるユーザー定義型ガードは次

                                          ユーザー定義型ガード、asで書くかanyで書くか - uhyo/blog
                                        • 究極のReact向けルーターライブラリ「Rocon」を作った - uhyo/blog

                                          こんにちは。先月くらいからReact向けのルーターライブラリ「Rocon」を作っていて、この度alphaリリースという形で公開まで漕ぎ着けたので宣伝します。 現在のところ、以下のURLでチュートリアルを読むことができます。 このチュートリアルサイトはRoconを用いて作られています。 Roconチュートリアル: https://rocon.uhyohyo.net/Roconの特徴は非常に型安全であることです。 何よりも型安全性・型周りの快適性を優先してAPIが設計されています。 当然、TypeScriptと一緒に使うことが前提です。 また、Roconはreact-router-domの代替となることを意図しています。 そのため、Roconを使うべきとき・使うべきでないときをまとめると以下のようになります。 Roconを使うべきとき: 今react-router-dom等を使ってSPAを作っ

                                            究極のReact向けルーターライブラリ「Rocon」を作った - uhyo/blog
                                          • react-wc: Web ComponentsとReactで実現するCSS in JSの形 - uhyo/blog

                                            CSS in JSはJavaScriptのコードの中にCSSを書く手法の総称で、CSS Modulesやstyled-componentsなどがよく利用されています。 この記事では、筆者がCSS in JSについて考えてたどり着いた一つの解を紹介します。 また、そのために作ったライブラリreact-wcを紹介します。 Shadow DOMを活用する筆者がたどり着いた考えは、Web Componentsをそのまま使えばいいじゃんというものです。Web ComponentsはいくつかのWeb標準の総称で、特にここで重要なのはShadow DOMです。 CSS in JSが達成すべき目標の一つはスタイルのローカル化(書いたCSSを特定のコンポーネントに対してのみ適用し、他に影響を与えないこと)ですが、Shadow DOMはこの機能を備えたWeb標準ですから、これを利用することでスタイルのローカル

                                              react-wc: Web ComponentsとReactで実現するCSS in JSの形 - uhyo/blog
                                            • 新卒2年目フロントエンドエンジニアの技術スタック2020 - uhyo/blog

                                              いつもブログをご覧になってくださっている皆さん、こんにちは。そうでない方は初めまして。 2020年もあと1ヶ月となりましたので、この記事では筆者が今年扱った技術について振り返ってみます。 なお、筆者は2019年に新卒で████社に入社し、██████のフロントエンドを担当しています。新卒2年目のフロントエンドエンジニアのみなさんはぜひ参考にしてみてください。 プログラミング言語業務・趣味ともにほぼ全てTypeScriptを使っています。一応、たまに書き捨てのものをJavaScriptで書くことがありますが、一定以上の規模のものを作りたい場合や一定期間以上メンテナンスしたい場合はTypeScriptを使います。また、ASTを扱うときや新しいライブラリを触るときなど、型情報による補完の恩恵が大きい場合もTypeScriptを積極的に使用します。どれにも当てはまらないのでJavaScriptを使

                                                新卒2年目フロントエンドエンジニアの技術スタック2020 - uhyo/blog
                                              • ついに来る! TypeScript 5.0の新機能を全紹介 @uhyo

                                                本記事は、TechFeed Experts Night#11 〜 JavaScript/TypeScript最前線のセッション書き起こし記事になります。 イベントページのタイムテーブルから、その他のセッションに関する記事もお読み頂けますので、一度アクセスしてみてください。 本セッションの登壇者 セッション動画 皆さまこんにちは、株式会社バベルにてプリンシパルエンジニアをしておりますuhyoです。まもなくリリースされる予定のTypeScript 5.0の新機能が、この発表ですべてわかるように用意しましたのでぜひお聞きください。 TypeScriptのリリースサイクル まずはTypeScriptのリリースサイクルをおさらいしておきましょう。TypeScriptは3カ月に1回のリリースサイクルを採用しており、TypeScript 5.0もそのサイクルに則り、2023年3月に公開される予定です(3

                                                  ついに来る! TypeScript 5.0の新機能を全紹介 @uhyo
                                                • import文で画像やCSSを読み込むのはECMAScript仕様違反か - uhyo/blog

                                                  近頃のJavaScript開発は、モジュールとして書かれた複数のJavaScriptファイルをimport文やexport文を通じて連携させるのが基本です。また、それらのファイルはWebpackに代表されるバンドラによって事前に処理され、import文の解決・ファイルの結合といった前処理を施されるのが普通です。まったく、各ファイルが他に影響を与えないように(function(){ ... })()で囲んで文字列連結していた時代が懐かしいですね。 さて、import文の解決を担当するバンドラは、大抵JavaScriptプログラム以外のものを読み込む機能を備えています。Webpackならばloaderと呼ばれるものですね。例えば、style-loaderやcss-loaderが持つCSS Modulesの機能を使うと次のようなプログラムを書くことができます(Reactの例)。 import s

                                                    import文で画像やCSSを読み込むのはECMAScript仕様違反か - uhyo/blog
                                                  • TypeScriptのユニオン型で「あるかもしれない」プロパティを表現するときのTips - uhyo/blog

                                                    TypeScriptのユニオン型はとても強力な機能で、TypeScriptのコードベースでは広く利用されています。 例えば、次のようにすると「fooプロパティを持つオブジェクトまたはbarプロパティを持つオブジェクト」という型を表現できます。 type FooObj = { foo: string }; type BarObj = { bar: number }; type FooOrBar = FooObj | BarObj; const fooObj: FooOrBar = { foo: "uhyohyo" }; const barObj: FooOrBar = { bar: 1234 };無いかもしれないプロパティ上のFooOrBar型を持つオブジェクトは、fooプロパティを持つ(FooObj)かもしれないし持たない(BarObj)かもしれません。 これはbarも同じで、つまり「ある

                                                      TypeScriptのユニオン型で「あるかもしれない」プロパティを表現するときのTips - uhyo/blog
                                                    • 作って理解するBabelマクロ - uhyo/blog

                                                      Babelは今どきのJavaScript開発には欠かせないパーツのひとつです。その主な使い道は、新しいJavaScriptの文法を古いJavaScriptに変換するトランスパイラとしてのものでしょう。しかし、Babelをより広範にマクロの機構として使おうという動きもあります。それを担うのがbabel-plugin-macrosというプラグインです。 ここで言うマクロとは、大ざっぱに言えばプログラムを生成するための機構であり、特にソースコード中に書かれるもののことです。例えばC言語などに見られる#defineは原始的なマクロであると言えます。最近の言語ではRustが強力なマクロの機構を持ち、Rustの文法を逸脱したトークン列をソースコード中に書くことができます。そのようなプログラムはマクロによってRustプログラムに変換されます。マクロを用いることで、通常の言語機能では不可能なメタプログラミ

                                                        作って理解するBabelマクロ - uhyo/blog
                                                      • 【宣伝】『プロを目指す人のためのTypeScript入門』4月22日発売! - uhyo/blog

                                                        皆さんこんにちは。先日、私が書いたTypeScriptの入門書『プロを目指す人のためのTypeScript入門』が発表されました。この本は4月22日発売で、すでにネット書店などでは予約受付中です。また、電子版も発売の予定があります。この記事ではこの本を宣伝します。 同出版社の『プロを目指す人のためのRuby入門』がチェリー本と呼ばれているのに合わせて、この本はブルーベリー本やベリー本と呼ばれているのを見かけました。そのような愛称がつくと嬉しいですね。 書影どんな本なの?タイトルにもある通り、TypeScriptの入門書です。 具体的な内容については、技術評論社のWebサイトで目次が公開されていますので、それを見ればおおよそ把握することができるでしょう。扱う範囲としては以下の通りです。 TypeScriptという言語そのものに注目し、周辺のエコシステム(フロントエンド開発、サーバーサイド開発

                                                          【宣伝】『プロを目指す人のためのTypeScript入門』4月22日発売! - uhyo/blog
                                                        • react-routerで現在のlocationを取得する2種類の方法の使い分け方 - uhyo/blog

                                                          SPAを作る際は、URLを変化させたり、URLの変化に反応して画面を変えたりする必要があります。このために使われるのがルーティングライブラリです。Reactにおいては、react-routerが代表格として知られています。 react-routerでルーティングが制御されている場合、その中のコンポーネントが現在のURLを表すオブジェクトであるlocationを得るための方法は大別して2つあります。一つはuseLocation、もう一つはuseHistoryです。なお、これらのフックはreact-routerのv5.1で追加されました。この記事ではこれ以前の方法は取り扱いません。 この2つの方法のどちらを使ってもlocationを得ることは可能ですが、どちらを使うべきかは場合によって明確に異なります。間違った方を使うと、パフォーマンスが低下したり期待通りに動かなかったりという問題が発生するこ

                                                            react-routerで現在のlocationを取得する2種類の方法の使い分け方 - uhyo/blog
                                                          • useEffectのdeps比較関数をカスタムしたくなったときにやること - uhyo/blog

                                                            Reactにおいて、useEffectなどいくつかのフックは第2引数として依存リストを取ります。 例えばuseEffectの場合、レンダリングの度に依存リストのいずれかの値が前回から変化したかどうかがチェックされ、変化していた場合はレンダリング後にコールバック関数が呼び出されます。 具体例としては、次のコンポーネントはcounterが変化するたびにconsole.logでそれを表示するでしょう。 const Conter = () => { const [counter, setCounter] = useState(0); useEffect(()=> { console.log(counter); }, [counter]); // ... }この場合、このuseEffectの依存リストはcounter一つということになります。 最初counterが0だった場合、次の再レンダリング時に

                                                              useEffectのdeps比較関数をカスタムしたくなったときにやること - uhyo/blog
                                                            • setTimeoutに大きい数値を与えるとどうなる? 仕様を読んで完全理解 - uhyo/blog

                                                              JavaScriptではsetTimeoutという関数を使うことができます。 しかし、実はこの関数は言語仕様(ECMAScript)に組み込まれているものではありません。 ブラウザ上で動くJavaScriptの場合、setTimeoutはHTMLの仕様によって定義されています。 このHTMLの仕様はHTMLとは名ばかりの巨大な仕様で、今時のブラウザの挙動をほぼ全て規定しているといっても過言ではありません。 さて、setTimeoutにとても大きな数値を渡したときの挙動に関するツイートをTwitterで見かけました。 曰く、setTimeoutに渡す数値は32ビット整数しかサポートされていないというのです。 試してみると、次のようなものは確かに一瞬でタイマーが呼ばれてしまい、想定した挙動とは違うように思えます。 setTimeout(() => { console.log(`${2 ** 5

                                                                setTimeoutに大きい数値を与えるとどうなる? 仕様を読んで完全理解 - uhyo/blog
                                                              • 【速報】うひょ氏 “(ぇ”の常用を停止 15年の歴史に幕 - uhyo/blog

                                                                2020年7月1日、うひょ氏はツイッターにおいて全ての文を“(ぇ”で終わらせる慣習を停止すると発表した。同氏によれは期限は7月末まで。その後も“(ぇ”の無いツイートを続けるかどうかは改めて決定するとした。 同氏によれば、インターネット上で“(ぇ”の使用を始めたのは約15年前。2010年にツイッターを開設した時点ですでに“(ぇ”を常用するスタイルが確立されていた。今回の変更により、初めてツイッター上で”(ぇ”の無い発言が披露されることとなる。 うひょ氏は取材に対し「“(ぇ”があるからフォローしない・ミュートしているという声を複数聞いておりさすがに心に刺さった。はてブの件が決定打だった」と語った。また、「“(ぇ”はこれまで15年にわたって自分のアイデンティティを支えてきたもはや自分の一部。今回の決定は決して決別ではなく、これからも共存の道を探っていく。相談した友人からは“(ぇ”を擁護する声も頂

                                                                  【速報】うひょ氏 “(ぇ”の常用を停止 15年の歴史に幕 - uhyo/blog
                                                                • GitHub - uhyo/better-typescript-lib: Better TypeScript standard library

                                                                  You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

                                                                    GitHub - uhyo/better-typescript-lib: Better TypeScript standard library
                                                                  • GitHub - uhyo/eslint-plugin-import-access

                                                                    You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

                                                                      GitHub - uhyo/eslint-plugin-import-access
                                                                    • uhyo様の「Tailwind考」に関する私なりの考え

                                                                      このサイトについて プライバシーポリシー プロフィール 投稿タグの一覧 amp.dev(外部リンク) 本サイトについて 趣味で開発したプログラムや開発メモを載せています。 ソースコードはGithubで公開しつつ、なるべく後から分かるように解説に努めてますので、 誰かのお役に立てれば嬉しいです。 プロフィール uhyo様の「Tailwind考」を拝見させていただいて、概ね賛成ですが 今までTailwind CSSのv1.0が公開されてから、業務や個人でTailwind CSSを使ってきた私なりの考えや感想、意見を特に私が異なると思った部分を中心に一部引用させていただきながら、まとめました。 内容がかなり長くなってしまい、Twitterやはてブのコメントでは収まらなくなったので大変恐縮ですが、個人ブログで公開します。 引用させていただいた、uhyo様のブログは「こちら」です。 「Tailwin

                                                                      • GitHub - uhyo/nitrogql: GraphQL + TypeScript toolchain

                                                                        You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

                                                                          GitHub - uhyo/nitrogql: GraphQL + TypeScript toolchain
                                                                        • 究極のReact向けルーターライブラリ「Rocon」正式リリース - uhyo/blog

                                                                          こんにちは。前回の記事でご説明したReact向けのルーターライブラリ「Rocon」をこの度正式リリース(1.0.0リリース)したのでご報告します。 Roconに関する詳しいことは前回の記事をご覧いただきたいのですが、簡単に説明するとRoconの特徴は非常に型安全であることです。 API面での特徴は、/:id/profileのように文字列を用いてルートを定義するのをやめて、代わりにルートを全てオブジェクトとして定義することです。 例えば、/:id/profileに相当するルート(:idの部分は任意の文字列を入れてアクセス可能という意味になります)はRoconでは次のように定義します。 const topLevel = Rocon.Path() .any("id"); const secondLevel = topLevel.anyRoute .attach(Rocon.Path()) .ro

                                                                            究極のReact向けルーターライブラリ「Rocon」正式リリース - uhyo/blog
                                                                          • 究極のReact向けルーターライブラリ「Rocon」を作った - uhyo/blog

                                                                            こんにちは。先月くらいからReact向けのルーターライブラリ「Rocon」を作っていて、この度alphaリリースという形で公開まで漕ぎ着けたので宣伝します。 現在のところ、以下のURLでチュートリアルを読むことができます。 このチュートリアルサイトはRoconを用いて作られています。 Roconチュートリアル: https://rocon.uhyohyo.net/Roconの特徴は非常に型安全であることです。 何よりも型安全性・型周りの快適性を優先してAPIが設計されています。 当然、TypeScriptと一緒に使うことが前提です。 また、Roconはreact-router-domの代替となることを意図しています。 そのため、Roconを使うべきとき・使うべきでないときをまとめると以下のようになります。 Roconを使うべきとき: 今react-router-dom等を使ってSPAを作っ

                                                                              究極のReact向けルーターライブラリ「Rocon」を作った - uhyo/blog
                                                                            • GitHub - uhyo/rocon: Router Library with Ultimate Type Safety

                                                                              You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

                                                                                GitHub - uhyo/rocon: Router Library with Ultimate Type Safety
                                                                              • uhyo/blog

                                                                                ███を退職します 皆さんこんにちは。この度、███を退職することになりましたのでご報告します。███には2022年1…

                                                                                  uhyo/blog
                                                                                • 個人ブログを作った - uhyo/blog

                                                                                  こんにちは。うひょです。誰という方はTwitterとかQiitaをご覧ください。この度、新たに個人ブログを立ち上げました。これはその最初の記事です。最近よく個人ブログという言葉を聞きますが、この言葉の正確な意味って何なんでしょうね。この界隈では「ブログサービスに頼らずに提供されるブログ」の意味で使われているような気がしますが、気のせいかもしれません。 これまではQiitaに技術記事を書いていましたが、今後はこのブログを主軸としつつ使い分けていきます。 Qiitaに比べるといいね (LGTM) 機能が無いのが最大の違いですね。Qiitaの非常にいいところは承認欲求が満たされやすいところだったので、このブログがその代替となってくれるように、Twitterなどでのシェアをこれまで以上に積極的にしていただけるととても幸いです。ただ同時に、Qiitaではなく個人ブログに移行したことでこれまでよりも幅

                                                                                    個人ブログを作った - uhyo/blog

                                                                                  新着記事