はじめにTypeScriptで型を定義する際、interface と type のどちらを使うべきか。これは、多くの開発現場で一度は議論になるテーマではないかと思います。 世の中の多くのドキュメントや記事では、クラスへの implements のしやすさや、interface が持つ「宣言のマージ(Declaration Merging)」の利便性が紹介されることもあり、interface の利用が推奨されるケースもよく見かけます。 しかし、特にサーバサイドアプリケーションや、ある程度規模のあるシステムを開発する上で、私はこの「宣言のマージ」機能が、時として予期せぬ挙動や、場合によってはセキュリティ上のリスクを静かにもたらす要因になると感じています。 今回は、なぜ私がプロダクトコードにおいて interface の積極的な使用を避け、type エイリアスを好んで使うのか、具体的なシナリオ
TypeScript以外が嫌いです こんにちは、TypeScript原理主義者のTakoです。今日は私がなぜTypeScript以外の言語が心の底から嫌いなのかをお話しします。 はじめに みなさん、世の中にはプログラミング言語がたくさんありますよね。Java、Python、JavaScript、Ruby、Go...。でも、私にとってそれらは全て「TypeScriptではない言語」というカテゴリに分類されます。つまり、使う価値のない言語です。 型がないなんて、人生がないようなものJavaScript?あんなの型がなくて何が楽しいんですか?undefined is not a functionとかcannot read property of nullとかいうエラーと戯れるのが好きですか?私は嫌いです。 //TypeScriptの美しさ interface User { id: numbe

はじめにReact +TypeScriptでAPIを呼び出す際、エラーハンドリングは避けて通れません。しかし、「とりあえずtry-catchで囲む」だけでは不十分です。この記事では、実践的なエラーハンドリングパターンを解説します。 基本的なtry-catch-finallyパターンtypescriptconst handleNameSearch = async (e:React.FormEvent) => { e.preventDefault(); onLoadingChange(true); // ローディング開始 try { const response = await fetch('http://localhost:3000/api/v1/wines/search_by_name', { method: 'POST', headers: { 'Content-Type': '

この記事は、下記の記事への反論というよりも、「TypeScript でバックエンドを書く」というテーマについて、別の観点から整理したい という意図で書いています。 元記事は、文脈が分かりづらいと感じたため、自分なりにバックエンドの特性にフォーカスして再整理しています。 最近、以下の記事を見かけました。 記事の内容は、バックエンドもTypeScript で書きましょうという内容です。 たしかに、TypeScript は現代のフロントエンド開発においてデファクトスタンダードとも言えます。型安全性、補完の効きやすさ、そしてJavaScriptとの互換性。いずれも実務で使うには非常に便利です。フロントエンドではもはや必須とも言える存在です。 ただ、バックエンドという文脈においては、TypeScriptを選ばない理由もあるよね? と感じました。TypeScript を否定したい訳ではなく、「あ

TSKaigi2025の登壇資料です

課題意識 特定の商品を数量を指定して購入できるECサービスのドメインモデルを表現とします。TypeScriptで構築する際に、「数量」を単にnumber型で扱うことは可能ですが、よりロバストな設計を目指す上で以下の2つの方法論があります。 Refinements(値の制約を表す): 「数量」は一般的に自然数です。1度の注文で指定できる上限を設けるビジネスルールがあると仮定します。この場合、number型に「自然数」「上限付き」の制約を加えた値として表現します。 Branded Types: (同じ構造の型を区別する): 「価格」などの他のnumber型と混同されないように、これらの数値を型レベルで区別したいです。JavaやC#に見られる公称型の概念をTypeScriptで模倣するBranded Typesのテクニックを用いることで、これらの誤った利用を型システムで防ぐことができます。 Br

はじめにTypeScript は静的型付け言語として、コードの品質を向上させ、多くのバグを未然に防ぐ強力な型システムを提供しています。しかし、その構造的型システム(structural typing)には限界があります。似た構造を持つ型が互いに互換性を持ってしまうことで、意図しない代入や関数呼び出しが可能になり、論理的なエラーを引き起こす可能性があるのです。 このような問題に対処するために「Branded Types(ブランド型)」という手法が使われます。これは、TypeScript の型システムを拡張して名前的型システム(nominal typing)の特性を模倣し、似た構造でも異なる役割を持つ型を区別できるようにする手法です。本記事では、Branded Types の基本概念から実装方法、実践的な活用例まで、段階的に解説していきます。 構造的型システムとその課題 TypeScrip

「なにがしたいか」をベースにコメントをつけておくと、後で読むときのコストが下がりやすい。 実際にプロダクトコードで書いたことがあるコメント↓ (簡略化してます) // 画面内に入った動画を自動再生する+ほかの動画は停止する (すでに再生済みだったら再生しない) useEffect(() => { if (inView && !hasBeenPlayed && canAutoplay) { /* ... */ pauseOtherVideo(); play(); } /* ... */ }); このコンポーネントにはコレを含めて4つのコメント付きのuseEffectがあった。たびたび読み返す機会があったが、その度にこれらのコメントが大いに役立った。 なぜコメントが必要なのか? useEffectの中身はたいてい複雑な処理になる。しかもたいてい無名関数を渡すので、実現したい仕様に関する情報がな
TypeScript 5.8で導入されるerasableSyntaxOnlyフラグを使うと、enumやnamespace、クラスのパラメータプロパティ、moduleキーワードなどの構文をエラーとして検出できます。これらの構文はNode.jsでTypeScriptを実行する際に非互換な構文であり、本フラグの導入によりNode.jsとTypeScriptの互換性が高まります。本記事では、erasableSyntaxOnlyフラグの挙動と、なぜこのフラグが導入されたのかを解説します。 erasableSyntaxOnlyフラグの挙動 erasableSyntaxOnly とは、「削除可能な構文のみ」という意味です。削除可能な構文とは、Node.jsでTypeScriptを実行される際に削除される構文のことです。後ほど詳しく解説します。 erasableSyntaxOnlyフラグは、tsconf

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに Node.js +TypeScriptによるサーバーサイドの開発は、クライアントサイドとスクリプトを同じ言語で管理できるなどのメリットがあります。 その際に使用するのが、Node.jsウェブフレームワークであり、データベース連携は必要不可欠です。 ですが、普段データベースに触れる機会が少ないデータベース初心者にとって、SQL文を書くのはハードルが高く感じます。 そういった状況で役に立つのが、「Object-RelationalMapping / オープンソースのオブジェクト関係マッピング」(以降ORM)です。 「Prism

ROSCA株式会社さん主催のイベント フロントからバックエンドまで、TypeScriptでシームレスな開発エクスペリエンスを で発表させていただいた際に使用したスライドです。

本記事はこちらの改訂版です。コードも改良しています。 三項演算子は本当に読みにくいのか コードをドキュメントのように読みやすくすることは非常に多くのメリットがあります。 そして、プログラミング言語自体にも読みやすくするためだけに存在する構文があります。 その1つが三項演算子です。 いやいや、三項演算子は読みにくいだろう、と思われた方は多いと思います。 しかし、読みやすいケースがあることも私は経験しています。 あなたも経験しているかもしれません。 なぜ、読みやすさに差が出るのか。調べていった結果、ポイントが分かりました。しかし、それを言語仕様として持っているものはありません。 そこで、TypeScript で読みやすい三項演算式を書くためのメソッドを開発したのでご紹介します。 そのメソッドを使ったTypeScript のコードは、次のようになります。Python の条件式(三項演算子)に

TypeScriptは強力な型システムが魅力です。 しかし、複雑な型定義は理解が難しいです。特にライブラリの型定義などはジェネリクスや交差型などがネストしていることも多く、すぐに把握するのが難しい場合があります。 Visual Studio Code(以下VSCode)でTypeScriptの開発をしている際、型にカーソルをホバーすると型情報が表示されます。 しかし、深いネストや複雑な型の場合、展開される情報が不十分で、定義を追う必要があります。 そんな時に役立つVSCodeの拡張機能がないかな〜と探していたら「PrettifyTypeScript」というぴったりの拡張機能を発見しました!この拡張機能を使うと、ホバーした時に型が展開された状態で表示されるため、型情報を把握しやすくなります。 PrettifyTypeScriptの概要 PrettifyTypeScriptを使用すること

「TypeScriptではじめる型システム」という記事をn月刊ラムダノートに寄稿しました。 新刊を発売しました "『n月刊ラムダノート』Vol.4 No.3(2024)発行のお知らせ https://t.co/PGppk1aRRA—lambdanote (@lambdanote) 2024年10月4日 どんな内容?TypeScriptの極小サブセットに対する型検査器を書き、それを通して型システムを体感してみよう、という内容です。 詳しく言うと、boolean型とnumber型と関数型しかないTypeScriptサブセット言語がターゲットです。 型検査器の実装言語にもTypeScript(処理系はDeno)を使います。TypeScriptづくしの一品です。 わかる人向けに言うと、「型システム入門」という本(通称TAPL)の単純型付きラムダ計算に相当する内容をTypeScriptで説明し
TypeScriptではtype alias syntax(型エイリアス構文)とinterface declaration(インターフェース宣言)を使って型を定義できます。 おおよそ両者同じことができるので、どちらを使うか迷います。 両者の使い分けに関する記事は沢山あります。 これらの記事を読んで基本的にはtypeを使えば良いと思っていました。 ですが最近以下のことがあり、typeとinterfaceの使い分けがわからなくなってしまいました。 typeよりもinterfaceの方がコンパイルのパフォーマンスが良いという話を耳にした。 interfaceしか使えない特定の機能を知った。 そこでtypeとinterfaceの違いを学んで、どう使い分ければよいかを整理しました。 type, interfaceそれぞれのメリット typeのメリット interfaceで表現できないことが表現できる

カケハシのプラットフォームチームでソフトウェアエンジニアをしているすてにゃん (id:stefafafan) です。今回は、私がTypeScript をメイン言語として採用しているチームに参加した際、言語や周辺技術のキャッチアップを行った方法について紹介します。 この記事は秋の技術特集 2024の 3 記事目です。 この記事の想定読者 私が元々持っていたスキルセット 認知負荷の増加TypeScript 学習のためにやったこと 学習の進め方 テックリードとの1on1 の中で壁打ちや相談 ペアプログラミング 輪読会 もくもく会 学習コンテンツ O'Reilly Online Learning を使った学習TypeScript Deep Dive プロを目指す人のためのTypeScript 入門 安全なコードの書き方から高度な型の使い方まで type-challenges 公式ドキュメ
概要Storybook6.4からデフォルトでCSF3の書き方が使えるようになったので、自分なりに調べたことをまとめてみました。TypeScript +Reactで説明します。 公式の記事はこちら この記事の内容は以下のとおりです。 CSF2からCSF3の変更点 CSFの既知の問題と公式の対応状況 インタラクティブストーリーの書き方 CSF3で書いたストーリーをユニットテストに応用する方法 この記事の説明で使うコンポーネント 名前を入力してSubmitボタンを押すと、ボタンを押した時の入力テキストを下に表示するコンポーネントです。 import { VFC, useState } from 'react' export type Props = { title: string } constSimpleFrom: VFC<Props> = ({ title }) => { const

はじめにフロントエンドもバックエンドもTypescriptで書きたい!ということで、T3 Stack(T3スタック)について調べてみました。 T3 Stackを利用したプロジェクトを作成するためのCLIツールcreate-t3-appが用意されており、簡単に雛形プロジェクトが作れるため、実際に使ってみました。 この記事は以下の内容をメインに紹介します。create-t3-appの環境構築手順 雛形プロジェクトの解説(特にtRPCを用いたAPIの呼び出し方法について) T3 Stackとは T3 Stackとはsimplicity(簡潔さ)、modularity(モジュール性)、full-stack type safety(フルスタックの型安全)を追求した思想に焦点を当てています。 そしてそれらを実現するために以下6つの技術スタックが採用されています。 ✅Next.js ✅ tRPC

リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く