TL;DR TypeScriptでライブラリなどを覗いているとよく見かける<T, K extends keyof T>について、問題を分解してきちんと理解する試みです。 extends この場合のextendsの役割は継承ではなく、制約です。 例えば以下のようなイメージ。 type StringOrNumber<T extends string | number> = T type A = StringOrNumber<string> type B = StringOrNumber<number> // Type 'boolean' does not satisfy the constraint 'string | number' type C = StringOrNumber<boolean> type User = { id: number; name: string; }; cons

切り替える理由 自社の主力製品で利用している技術(WebRTC / WebTransport)がブラウザベースのため TypeScript を利用する Go を採用したのは sqlc が使いたかったという理由 sqlc-gen-typescript が出てきたのでもう Go を使う理由がなくなった 自社サービスチーム全員が Go にまったく興味が無い sqlc 自体は便利 そもそも自社に Go への興味がある人がいない 自社サービスの規模ではボトルネックになるのはデータベースであって言語ではない もしアプリでスケールが必要なときは Rust や Erlang/OTP に切り替えれば良い コネクションプールは PgBouncer を利用すればいい TypeScript からは 1 コネクション 1 接続で問題無い どうせフロントエンドでは TypeScript を書く 自社では React

TypeScriptとDocumentaion tests / Documentation tests with TypeScript

はじめにタイトルは若干煽りですが、TS 5.0 でBundlerという設定値が追加されたため、Nodeを使う場面はほぼ無くなったと思います。 今回は Node.js と TypeScript のモジュール解決の仕組みについて、moduleResolutionというオプションの観点から解説します。 この記事を書くにあたって実際に動作確認は行っていますが、もしも間違っているところがあればご指摘いただけると幸いです。 なお、 Node.js LTS v18、TypeScript v5.0 時点での情報です。 今後のバージョンアップにて変更がある可能性があります。 TL;DR"moduleResolution": "Node"は使わないほうがいい おそらく求めているものはBundler tsc をビルドツールとして使用している場合はNode16 / NodeNextがベスト Nodeを使う場合でも

tsconfig.jsonを書く時に必要なオプションが何だったか、どんな役割を持つかを忘れてしまうため、個人的によく使いそうなオプションを書いていきます。 TypeScriptのバージョンは4.4です。 各オプション target TypeScriptはJavaScriptにコンパイルされるため、その時にどのバージョンのJavaScriptで出力するかをtargetで指定します。 ドキュメントを確認すると、デフォルトはES3ですが、以下の中からも選択できます。 es3, es5, es6/es2015, es2016, es2017, es2018, es2019, es2020, es2021, esnext どれを選択すれば良いかは、Node.jsのバージョン毎に推奨されるtargetがあるため、node.greenを確認します。Node.jsのバージョンは、node -vで確認できま

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

皆さんこんにちは。早速ですが、TypeScriptのmoduleオプションはご存じでしょうか。moduleオプションは、例えば次のような値をサポートしています。 commonjs umd es2015 esnext node16 nodenext 皆さんは、moduleオプションが何を設定するオプションなのか一言で説明できますか？ 実は、TypeScriptの熟練者であってもmoduleオプションを一言で説明することは難しいはずです。なぜなら、そもそもこのmoduleオプションが複数の異なる意味で使われており、もはや一言で説明できるようなものではなくなってしまったからです。 この記事では、TypeScriptのメンテナーが書いた次のGitHub issueをベースに、moduleオプションを取り巻く状況を説明します。 moduleオプションの意味とは 昔はmoduleオプションの意味は明確

昨年から執筆を続けていた書籍が 4/24 に刊行します。「フロントエンド開発のためのテスト入門」という本です。 書籍ならではのテストコード解説を目指して 次の投票結果は、書籍企画時に持ち込んだ筆者のツイートです。フロントエンドテストに関していえば、8 割近くの方が何かしら不安や不足を感じている、という結果になりました。 不安や不足の原因は様々なものがあるかと思います。そのうち、筆者が着目したのは「テスト手法の豊富さ」です。「単体テスト・結合テスト・E2E テスト、何をどれほど書けばよいのか？」という疑問は、フロントエンドに限らず、はじめて自動テストに取り組まれる方が通る関門ではないでしょうか。 自動テストを書くには「テスト対象」を明確にしたうえで、テスト対象に適したテストコードを書く必要があります。本書は、現場で書かれるものに近い「テスト対象 = アプリケーションコード」をサンプルとして用

export type Bookmark = { id: number; url: string; comment: string; }; このファイルには型しか書いてありませんね。ということは、「型定義ファイル」として bookmark.d.ts という名前にするべきでしょうか。実はそうではなく、この場合は bookmark.ts とするべきです。 「型定義ファイル」とは、「どこか別の場所にある実装に型をつけるためのファイル」です。たとえば、以下のファイルは「どこか別の場所にある実装」に型をつけているから、 *.d.ts にするのは自然です。 いっぽう、 type Bookmark は別のどこかにある *.js の型を与えているわけではないので、 *.ts でよいです。 このように本来 *.ts であるべきものを *.d.ts にしてしまうことには問題があります。代表的な問題として型エラ

はじめに TextField RadioGroup SelectForm CheckboxGroup DatePicker コンポーネント使用側実装例 おわりに 本記事を執筆するにあたって、 マナリンク Tech Blog運営さんのReact Hook Form(v7)を使ったコンポーネント設計案 piyokoさんのMUI v5 + React Hook Form v7 で、よく使うコンポーネント達を連携してみる という記事を参考にさせていただきました。いつも非常にわかりやすい記事をありがとうございます。 はじめに こんにちは、ラクスフロントエンド開発課の斉藤です。 React Hook Form v7 + MUI v5 + zod v3を使ったよく使うコンポーネントの実装例を調査しており、こちらの記事を参考に実装を進めてみました。しかしRadioGroupやDatePickerをatom

ファンタラクティブのエンジニアの 太田 です。 数値入力コンポーネントを作成する際に type="number" を使用するのをやめたことについて書きます。 input[type="number"]とは input[type="number"] (PC) input[type="number"] (スマホ) 数値を入力するためのinputで半角数値以外の入力を除外する 問題 validな数値しか受け付けない 数値以外の値が入力できないためTypeScriptでも扱いやすくよさそうに思えますが、使用するユーザーは戸惑うことがあるようです。 実際にあった問い合わせや、問い合わせから想像する状況は以下のようなものです。 入力できない (全角入力してる) 確定したら値が消えた (全角入力してる) ペーストできない (全角でペーストしてる) キーボードではなく、UI上の▲▼で入力しないといけないと思

対象 業務レベルでサーバーサイドでJestを書いたことはないけれど、新プロジェクトでは書くことになったみたいな方を想定して記述しています。 Jestについては中々ベストプラクティスが集まりにくいので、経験的にこう書くと「きれいに」・「早く」・「正確に」書けるよというTipsを集めてみました。もし、よろしければお読みください。 前提 TypeScript Node.js Jest DBアクセスありの状態を想定しています 1. it文内では、必ず1回は、expectをつかって検証をする JestのPRをレビューしてるとたまに見受けるのですが、expectを使ってないケースがあります。 // NG it('userを正常に、作成できること', async() => { await createUser({ name: 'Mike' }); }); // OK it('pdfが正常に削除できること

Atomic Design でいう Atoms に相当する、汎用コンポーネントについての小話です。次の様に Props 型定義を用意し、解説している記事をよく見かけます。<input />タグを使わずコンポーネント化している理由は style を施すためかと思いますが、このコンポーネントが受け取れる Props は限定的で、メンテナンスコストが高いためお勧めできません。 type Props = { value: string; onChange?: React.ChangeEventHandler<HTMLInputElement> onBlur?: React.FocusEventHandler<HTMLInputElement> } export const Input = ({ value, onChange, onBlur }: Props) => ( <input value=

概要 Storybook6.4からデフォルトでCSF3の書き方が使えるようになったので、自分なりに調べたことをまとめてみました。TypeScript + Reactで説明します。 公式の記事はこちら この記事の内容は以下のとおりです。 CSF2からCSF3の変更点 CSFの既知の問題と公式の対応状況 インタラクティブストーリーの書き方 CSF3で書いたストーリーをユニットテストに応用する方法 この記事の説明で使うコンポーネント 名前を入力してSubmitボタンを押すと、ボタンを押した時の入力テキストを下に表示するコンポーネントです。 import { VFC, useState } from 'react' export type Props = { title: string } const SimpleFrom: VFC<Props> = ({ title }) => { const

/** * 疑似コード */ //直前でIDを指定して取得したのにも関わらず const someEntity = someRepository.findById('some-id'); //Entity自体の存在確認をするのは良いが... if(!someEntity) throw new Error('SomeEntity not found'); //IDの存在まで確認しなければいけないのがなんかダサい。。 if (someEntity.id) { //someEntity.idを使った何かの処理 } 理想的には、 Repositoryに渡すとき(saveなど)はIDが発番されていないくても良い Repositoryから抜き出すとき(findAll, findByIdなど)はIDが発番されていることが保証されている というモデルを実現したい。 ということで、TypeScriptのUn

出典: https://www.npmtrends.com/typescript TypeScriptはJavaScriptを拡張して作られたプログラミング言語です。トレンドが示すとおり、TypeScriptはJavaScriptに代わって第一に選択される言語になりました。TypeScriptが提供する静的型システムは、コードの保守性と可読性を大幅に向上させます。またブラウザ等の互換性を心配することなく、モダンで便利なJavaScriptの機能を利用できます。 TypeScript DeepDiveは初心者からベテランまで役立つオープンソースのドキュメントです。JavaScriptのモダンな機能からTypeScriptの様々な魔法に至るまで丁寧に説明されています。多くのコードサンプルがあり、具体的なTypeScriptの使い方を簡単に理解できます。TypeScript DeepDive日本

なぜ執筆プロジェクトを立ち上げたのか？ 2020年の年末から年明けに開催された技術書典10で「はじめてのJest入門」を執筆しました。私自身はIT業界に約10年いますが、受託案件やR&Dのようなプロジェクトに参加することが多く、テストについての経験があまり得られないまま過ごしてきました。そんな中で社内のメンター＆メンティープログラムでTDD（Test-Driven Development：テスト駆動開発）について学ぶ機会があり、セッションを通して学んだことを記憶に残す意味でも、この本を書くことに至りました。しかし、前回の書籍ではTDDやテスト自体の概念についてはあまり触れず、セッションで利用したJestの基本的な機能や使い方についてフォーカスしました。 前回の技術書典10のイベントを通じて、同じような悩みや課題感を持った方多くがいることを知ることができました。JavaScriptは元々フロ

2021-12-17 Harajuku.ts Meetup #1