2024-11-16 TSKaigi Kansai 2024
はじめに 私は初めてDependency Injection(依存性注入)という概念に出会ったのは、NestJSのドキュメントを読んでいるときでした。その時、providerや@Injectable()は何なのか?といった素朴な疑問を感じましたが、ドキュメントを読んでもすぐには理解できず、そのまま一度放置しました。 最近、業務で触れているAPIサービスではNestJSではなく、InversifyJSというライブラリを使用してDependency Injectionを実装しています。これを機に、DIについてもう一度学び直すことにしました。そして、自分が調べて理解したことをまとめて共有したいと思います。 この記事では、以下のような疑問に答える形で情報をまとめています: Dependency Injectionは何?なぜ使うのか? Dependency Injectionはどのように実装されてい
ワークスペースを利用している TypeScript プロジェクトの開発をしているとき、共通パッケージの依存解決の方法には 素直に build 成果物を参照する exports フィールドで build 前の TypeScript ファイルを直接参照する 等いくつかの選択肢があります。 このエントリでは、それぞれのやり方での制約や、開発体験の良し悪し等を比較して状況に応じてどういうアプローチを採用するのが良いか考えてみます。 補足資料 上記のスクラップで調べたことがベースになっています。 課題の整理 典型的な Full-Stack TypeScript なモノレポ構成を考えてみます: my-project/ ├── apps/ │ ├── frontend/ # フロントエンド │ ├── backend/ # バックエンド ├── packages/ │ └── shared/ # 共通パ
技術記事は 個人ブログ へお引越ししました。 興味を持ってくださった方はZennではなくこちらをご購読いただければと思います🙏 type-challengesは型システムの仕組みをより深く理解し、独自のユーティリティを記述したり、あるいは単に型パズルを楽しんだりできるOSSプロジェクトです。 とはいえ、いきなりtype-challengesに挑むと挫折します。少なくとも私がそうでした。 なので、この記事ではまず最初にtype-challengesを解くために必要なTypeScriptの知識を解説します。 その後、実際にtype-challengesの問題を解いてみることで、座学→実践という形式でTypeScriptの型システムを学ぶことを目指します。 この記事は「一度はTypeScriptの公式ドキュメントやサバイバルTypeScriptを通して読んだけど、実際にコードを書こうとすると手
Lodash is dead. Long live Radash. 記事は上記記事を意訳したものです。 ※当ブログでの翻訳記事は元サイト様に許可を得て掲載しています。 Lodashの何が問題なのか? 関数の詳細分析 Lodashの_.get関数 Lodashの_.filter関数 Lodashの_.map関数 コード品質 でも、そのコミュニティは... では、どうするか? try関数 parallel関数 retry関数 counting関数 range関数 list関数 Lodashの何が問題なのか? JavaScriptの動的な能力が欠点ではなく特徴として捉えられていた時代に、Lodashは異なる入力に対して異なる振る舞いをする関数を提供することで、できる限り役立つように作られました。現在では、私たちはより良い方法を知っています。純粋関数、決定論的な振る舞い、関数合成といった関数型のコ
TypeScriptは強力な型システムが魅力です。 しかし、複雑な型定義は理解が難しいです。特にライブラリの型定義などはジェネリクスや交差型などがネストしていることも多く、すぐに把握するのが難しい場合があります。 Visual Studio Code(以下VSCode)でTypeScriptの開発をしている際、型にカーソルをホバーすると型情報が表示されます。 しかし、深いネストや複雑な型の場合、展開される情報が不十分で、定義を追う必要があります。 そんな時に役立つVSCodeの拡張機能がないかな〜と探していたら「Prettify TypeScript」というぴったりの拡張機能を発見しました!この拡張機能を使うと、ホバーした時に型が展開された状態で表示されるため、型情報を把握しやすくなります。 Prettify TypeScriptの概要 Prettify TypeScriptを使用すること
はじめに あくまで一個人の意見なので絶対的な解ではないというのと、どっちをデフォルトに選んでも普通にアプリケーション開発してて困ることはほぼほぼないと思うので、そこまで気を揉むことでもない、ということだけ最初に述べておいて意見をしたためます。 TL;DR アプリケーション開発では基本的に type でおk Declaration merging したい時だけ interface ライブラリ開発のような使う側で拡張したい(Declaration merging したい)時は interface とりあえずチームでどっちをデフォルトにするかは統一しといた方が気持ちいい type と interface の違い 機能的にはそんなに大きな違いはなく、個人的に判断に関わるのは次の3つかなと思います。 interface では Declaration merging がされる。type ではされない
カリー化と部分適用 先日同僚にカリー化を説明する機会がありました。その際に、簡潔に説明に適した自分用の資料があるといいなと思いましたので、こちらの記事を書くことにしました。 この記事ではカリー化と部分適用について解説します。歴史等には触れずにただその内容について述べます。 混同しやすいという情報があるのですが、割と違うレイヤの話なのでなぜなのかは不明ですが、関連性に関する私見も末尾に書いておきます。 カリー化 カリー化 (Currying)[1]とは 複数の引数を取る関数を、単一の引数を取る関数に翻訳する手法 のことです。 簡単な例を見ます。以下のような2つの引数を持つ関数を考えます。 const add = (a: number, b: number) => a + b; console.log(add(1, 3)); // 4 関数を値のように返す関数のことを高階関数と呼びます。 カリ
去る2024年4月25日にTypeScript 5.5 ベータ版リリースの情報が発表されました。 どうやら今回の目玉機能は、『推論されたtype predicate』ということです。 この記事では、これまでとこれからでtype predicateがどのように変わるのかをお話ししたいと思います。 環境の用意 これまでの動作を確認するための環境は、既に用意していた別プロジェクトのランタイムを利用しました。バージョンは5.1.6です。 ベータ版環境は新たに用意します。公式のリリースノートにもありますが、以下のコマンドを実行するだけです。 これでベータ版の実行環境ができたのですが、VSCodeさんが最新版の仕様で型推論を行なってくれません。 ので、調教強制的にいうことを聞かせます。 やり方は、適当なtsファイル開いてshift + cmd + p → typescript:Select Types
こんにちは。ナレッジワークの torii です。 最近、プロジェクトで使用している TypeScript の型検査にかかる時間を 3 割ほど短縮することに成功しました。 参考までにどのようにボトルネックを調査して改善に繋げたのかを書いてみます! きっかけ 改善のきっかけは、たまたまネットを徘徊していて見つけた Zenn 記事でした。 (素晴らしい記事をありがとうございます!) これを読んで「自社のプロダクトでも型検査にかかる時間を短縮できるのでは?」と思い立ち、試してみたところ実際に改善に役立てることができた、というのがこの記事の概要になります。 改善対象 改善対象は、弊社のメインプロダクトであるナレッジワークのフロントエンドです。現在マルチプロダクト化に向けたコード分割に取り組んでいる最中ですが、執筆時点はモノリシックな構成となっています。 改善前の TypeScript ファイルは自動
紹介すること TypeScriptの型を厳密に定義し、ドメインモデリングを行います。 ソースコードがドキュメントとして機能することを目指します。具体的には、Branded Typeやタグ付きユニオンなどの技法を扱います。 この記事は、TypeScriptをこれから使いこなしてみたい方向けの内容です。 紹介しないこと ドメイン駆動開発や関数型プログラミングの概念については、深くは触れません。 Make Illegal States Unrepresentable あり得る型だけを定義するという考え方です。 詳細は以下を御覧ください。 この考え方は、ほとんどのTypeScript開発に適用できると思います。 例1 仕様: すべてのユーザは、id、nameを持っている 認証されるとisVerifiedがtrueになり、verifiedDateが付与される 認証前はisVerifiedがfalse
はじめに 型駆動開発とはどんなもので実践すると何が嬉しいのかを自分なりに理解するためにこの記事を書きます。 2021年8月時点では「型駆動開発」でググっても意図した内容がヒットせず、「Type-Driven Development」と検索して英語の記事が何件かヒットする程度です。 自分の「型駆動開発」に対しての理解・認識が世間一般のそれと相違がある場合もありますので、何か思うところがあればご指摘いただければ大変嬉しく思います。 また、この記事ではTypeScriptとVue.jsでフロントエンドのコードを書いていきます。TypeScriptは必須の前提ですがReactでも同じような考え方を活かせるのではないかなと思っています。 型駆動開発とは 型駆動開発とはなにか。書籍「プログラミングTypeScript――スケールするJavaScriptアプリケーション開発」から引用させてもらいます。
こんにちは。 株式会社 CHILLNN という京都のスタートアップにて CTO を担っております永田と申します。 弊社では、バックエンドを typescript で実装しており、「宣言的プログラミング」と「関数型ドメインモデリング」のパラダイムを導入しています。 この構成は、一休 CTO である伊藤さんによる宣言的バックエンド開発の発信に大きく影響を受けており、よく言及されている「関数型ドメインモデリング」も拝読しました。 どれも非常に興味深く拝見させていただいたのですが、どうしても概念として理解することと、実装に落とし込むことの間には大きなギャップがありました。多くの試行錯誤を繰り返す中で、かなりこれらのパラダイムのメリットを実際に享受できるようになってきました。本記事では、我々の現時点での具体的実装上の tips を紹介します。 これらのパラダイムの導入を検討している方々にとって、少し
はじめに こんにちは、からころです。 今回は、VSCode でホバー時の TypeScript の型ヒントをすべて表示する方法について書いていこうと思います。 ※ 投稿日の 2024/10/17 から 2024/10/28 ごろに仕様が変わり、defaultMaximumTruncationLengthの書き換えだけでは、動作しなくなりましたので修正版を公開しています。 ※ 2025/06/29時点で、仕様がまた変わっていたので、動作しなくなりましたので修正版を公開しています。 デフォルトの設定では型の情報量が増えると型が省略される VSCode では、TypeScript を利用して開発する際に、ホバーすると以下のように型ヒントを表示することができます。 しかし、デフォルトの設定のままでは、下記のようにプロパティ数が多くなると型ヒントが省略されてしまいます。 上記の解決方法を以下で説明し
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く