TypeScript 関数型スタイルでバックエンド開発のリアルTSKaigi 2024 のスライドです
vanilla-extractを使ってみた感想
個人的にvanilla-extractを試していたのでその感想などを紹介できたらと思います。 要点 CSS modulesっぽくかけて型があるのがとても良い 採用したらメリットが大きそうなケース オブジェクト形式でも違和感なくかける人 CSSに型が欲しい人 CSSでNestを制限したいなど秩序をもたらしたい人 CSS modulesっぽくかけるのがとても良い 個人的に従来のピュアなCSSやCSS modulesのように別ファイルでCSSを管理するのが好みなのでこの書き方ができるのはメリットでした。 特にCSS modulesのようにファイルを管理できるのが良いです。 import { style } from '@vanilla-extract/css'; export const headerStyle = { wrapper: style({ padding: '16px', disp
自社サービスのバックエンドを Go から TypeScript へ切り替えるための整理
切り替える理由 自社の主力製品で利用している技術(WebRTC / WebTransport)がブラウザベースのため TypeScript を利用する Go を採用したのは sqlc が使いたかったという理由 sqlc-gen-typescript が出てきたのでもう Go を使う理由がなくなった 自社サービスチーム全員が Go にまったく興味が無い sqlc 自体は便利 そもそも自社に Go への興味がある人がいない 自社サービスの規模ではボトルネックになるのはデータベースであって言語ではない もしアプリでスケールが必要なときは Rust や Erlang/OTP に切り替えれば良い コネクションプールは PgBouncer を利用すればいい TypeScript からは 1 コネクション 1 接続で問題無い どうせフロントエンドでは TypeScript を書く 自社では React
エラーや非同期処理をより安全に扱うための TypeScript ライブラリ Effect-TS
TypeScript の型システムを活用して、本番のアプリケーションにおける実用的な問題を解決することを目指しています。Effect-TS は、以下のような特徴を備えています。 並行性（concurrency）：Fiber ベースの並行モデルにより、高いスケーラビリティと低レイテンシを実現 コンポーザビリティ（composability）：小さく再利用可能なパーツを組み合わせることで、メンテナンス性、可読性、柔軟性の高いソフトウェアを構築する リソースの安全な管理（resource-safety）：処理が失敗したとしても、安全にリソースを開放する 型安全性（type-safety）：TypeScript の型システムを活用した型推論と型安全性に焦点を当てている エラー処理（error handling）：構造化された信頼性の高い方法でエラーを処理する 非同期性（asynchronicity
Next.js + TypeScript + Tailwind CSS の開発環境をできるだけ丁寧に構築する【2024年】
はじめに 最近、Next.js、TypeScript、Tailwind CSSを使って技術ブログを立ち上げました。（まだあまり更新は進んでいませんが…） このプロジェクトを通じて構築した開発環境がわりと快適だったので、誰かの参考になるかもしれないと記事を書いてみることにしました。 できる限りわかりやすく詳細な説明を心がけましたが、その結果、記事のボリュームが大きくなってしまいました。長文ですが、興味のある方はぜひ読んでみてください🙏 また、この記事内で紹介した内容をセットアップしたリポジトリを公開しています。 Next.jsのボイラープレートとして活用可能ですので、興味のある方はぜひ覗いてみてください。
TypeScriptで学ぶ！SOLID原則
はじめに 皆さんこんにちは、株式会社エムアイ・ラボのエンジニアです！ 今回はソフトウェア設計のSOLID原則について学習したので、弊社のメインの開発言語であるTypeScriptのサンプルコードを使って共有できればと思います。 SOLID原則は、オブジェクト思考プログラミングにおいて、ソフトウェアがメンテナンスしやすく、拡張や変更に強いソフトウェア設計を行うための原則です。 SOLID原則にはSOLIDの頭文字をそれぞれとった、５つの原則があります。 単一責任の原則（Single Responsibility Principle） 単一責任の原則とは、クラスが一つの機能や責任を持つべきで、クラスが変更される理由は一つであるべきというです。 クラスが一つの機能や責任のみを持つようにすることにより、コードは再利用可能でテストが容易になります。 単一責任の原則を遵守している例 以下のBirdクラ
ライブラリにTypeScriptコードを同梱するときはディレクトリを分けよう - Qiita
ライブラリがこんな構成になっていませんか？ TypeScript製のライブラリをnpmで配布するとき、そのパッケージの構成は次のようなフラットな構造になっていませんか？フラットな構造とは、TypeScriptファイル(.ts)と、型定義ファイル(.d.ts)が同じディレクトリにあるような構成です。 ├── index.ts ...... TypeScriptファイル ├── index.d.ts .... 上の型定義ファイル | package.jsonのtypesフィールドで指定してる。 ├── index.js ...... 上のJavaScriptファイル | package.jsonのmainフィールドで指定している。 | ├── module.ts ..... TypeScriptファイル | index.tsからimportされている。 ├── module.d.ts ...
Axios 使うのやめたらビルドサイズが 10 KB 減って、なんか知らんがパフォーマンスも良くなった話
この記事について Zenn では長らく通信処理に Axios を使っていました。 しかし、Fetch API が多くのモダンブラウザなどで普通に使えるようになった今、使う必要性があまり無くなったため、Axios を使っている処理を全て Fetch API に置き換えることになりました。 この記事では、その置き換え作業をどう進めていったのか、その結果どう良くなったのかを解説していこうと思います 🗽 解説より置き換えた結果を知りたいのよ私は！！！ って方が居るかと思いますので、最初に置き換えたことで良くなった部分を紹介しようと思います。 まず一番良くなったところといえば、ずばりサイト全体のビルドサイズが 10 KB も減りました。( ちなみに、10 KB は圧縮時のサイズで、圧縮しない場合 100 KB になります 😇 ﾜｰｵ ) グローバルのビルドサイズが 103.35KB gzip 時
TypeScript JP解散のお知らせ
TypeScript JP の代表の sasurau4 です。この度、TypeScript JP は解散することになりました。 本記事では TypeScript JP の解散について報告します。 経緯 TypeScript JP はオンラインで行ったTypeScript Meetup #4を最後に、事実上の活動停止状態になっていました。 活動が停止した主な理由は、COVID-19 の影響によるコミュニティ活動全般における制約と代表である私のモチベーション低下が原因です。 COVID-19 が猛威を振るっていた 3 年の間も、TypeScript は躍進を続け、その活躍の場は広がり続けています。 2023 年に入り、政府によるマスク着用の要請が解除された辺りから、オンラインに限らず、リアルでのコミュニティ活動もちらほらと復活し始めました。 これによって、活動停止していた理由の 1 つは解消さ
令和5年に知っているべきTypeScriptのnamespaceの知識
TypeScriptにはnamespaceという構文が存在します。この構文はTypeScript初期からある独自構文の一つですが、現在では特殊な用途以外では使う理由が無いため、よく知らないという方も多いでしょう。 実際、一部のレアケースを除いてnamespaceを使う必要はありませんが、それでも知識としてあったほうが良いことが多少あります。この記事ではこの部分を解説します。 型に.でアクセスできるやつ TypeScriptを使っていると.を使って型にアクセスする機会があるでしょう。例えばReact.FCなどです。 実は、親.型名のように.を使って型にアクセスできるのは、namespaceの機能です。上のコードでのReactは単なる型や単なる変数ではなくnamespaceなのです。 試しに、Foo.BarがstringとなるようにFooを定義してみてください。これができる方法は2つしかありま
今あえてTypeScriptのビルド＆バンドルツールを探してみる | フューチャー技術ブログ
ちょっとしたフロントエンドの開発で、TypeScriptに最初から対応していて、簡単に使えるものは何かないかな、と調べてみたメモです。React/Vue/Angularの場合はそれぞれの初期化コマンドで何から何まで用意してくれます。Next.js、Nuxt.js、Gatsbyなども、これらのビルドのステップを簡略化するコマンドを提供しています。基本的にこれらのウェブフロントエンドを開発するときには、小規模・中規模ぐらいならあんまり気にしなくておまかせでもいいと思います。 今回は、それらのフレームワーク固有のビルドツールとは別に環境を作りたい人で、TypeScriptの環境が欲しい、ウェブの開発がしたい、という前提でいろいろ探してみました。 今回試してみたのは次の4つです。 Parcel Fusebox ncc Rome.js JavaScriptのビルドツールとはJavaScriptでビル
ゼロランタイムで fetch に型をつけたい
まだライブラリ化してないのと、フルパス対応してないけど、いじれば使えると思う。 これは何 こういう感じに fetch に型がついて動く import { type TypedFetch, JSON$StringifyT, JSON$ParseT } from "./typed-fetch"; const stringifyT = JSON.stringify as JSON$stringifyT; // こんな感じの記法で型情報を与える const fetch = window.fetch as TypedFetch<{ "/api/:xxx": { method: "GET"; bodyType: { text: string; number: number; boolean: boolean }; headersType: { "Content-Type": "application/
TypeScript 5.0 で追加された verbatimModuleSyntax とは何か？
// A: そのまま残る import { Foo } from "./foo"; // B: 識別子 `Foo` が削除される import {} from "./foo"; // C: import 文ごと完全に削除される どれになるかは、以下の状態の組み合わせ依存する（他にも条件あるかも）。 そのファイルでFooが値として参照されるか、型として参照されるか、参照されないか Fooがfoo.tsで値として定義されているか、型として定義されているか tsconfig のオプション設定 importsNotUsedAsValues: 値として参照されない import 文を残すかどうか preserveValueImports: 参照されない import 識別子が値なら残す isolatedModules: ファイル単位でトランスパイルする 上記は出力するモジュール形式が ESM の場合
Electron + React + TypeScript の開発環境構築
% tree -a -I 'node_modules' . ├── dist ├── package-lock.json ├── package.json ├── src │ ├── main.ts │ ├── preload.ts │ └── web │ ├── App.css │ ├── App.tsx │ ├── index.html │ └── index.tsx ├── tsconfig.json ├── tsconfig.node.json └── webpack.config.ts 3 directories, 11 files dist/: webpack の出力先フォルダ src/main.ts: メインプロセスのエントリファイル src/preload.ts: プリロードスクリプト src/web/: レンダラープロセス (= React アプリケーション) ソースコー
Electron での TypeScript サポートを発表 | Electron
Electron npm パッケージに、Electron API 全体の詳細なアノテーションを提供する TypeScript 定義ファイルが含まれるようになりました。 これらのアノテーションは、たとえ純粋なJavaScriptを書いていていても、Electron の開発エクスペリエンスを向上させることができます。 ただnpm install electron を実行して、あなたのプロジェクトに最新の Electron の入力を取得できます。 TypeScript は、Microsoft が作成したオープンソースのプログラミング言語です。 これは、静的型をサポート追加することで言語を拡張する JavaScript のスーパーセットです。 TypeScript のコミュニティは近年急速に成長しています。そしてTypeScriptは、最近のStack Overflow開発者調査で 最も愛されてい
【入門】ElectronをTypeScriptで手軽に試したい
この記事はClassi developers Advent Calendar 2022の8日目の記事です。 はじめに Electronとは、Windows、macOS、Linuxで動作するアプリが作れるソフトウェアフレームワークです。 読者対象者は以下の様な方です。 Electronの概要は知っているが、触ったことが無い方 TypeScriptで実装し学習したい方 Vue.jsやReactなどのライブラリは考慮しないで、Electronが動く環境を試したい方 今回紹介する実装は、出来るだけシンプルな構成を目指しました。一旦依存関係を出来るだけ省きElectronの機能に集中する事を目的としています。 実は、Electron Forgeという簡単にテンプレートが作成できるツールもあります。ある程度Electronに慣れてきたら、こちらを利用してみても良いでしょう。 作ったもの 開発環境 ma
GoogleAppsScriptは何で書くべきか(公式orローカル / JSorTS ) - Qiita
初めに ライブラリ等でメリットデメリットが大きく変わってくるため、 大雑把になっています GoogleAppsScriptを書く手段 公式サイトで作成する 公式エディタ(https://script.google.com)でJavaScriptで記載する ローカルで作成する(EditorはVSCode) JavaScriptで記載し、そのままclaspでpushする TypeScriptで記載し、そのままclaspでpushする(自動でトランスパイルされる) JavaScript/TypeScriptで記載し、webpack等を使ってビルドして、claspでpushする それぞれのメリット・デメリット 公式エディタを使って、JavaScriptを使う メリット ライブラリ,サービスの使用やデプロイを、GUIで書ける JSDocで型を記載できる(paramとreturnしか使えない) 一応G
TypeScriptのnamespaceは非推奨ではない - Qiita
結論から 公式の TypeScript ドキュメントの何処にも namespace を非推奨と示唆する記載は無い。 尚且つ microsoft/TypeScript#30994(comment) で TypeScript チームのリード開発者である Ryan Cavanaugh 氏が述べているように将来的に廃止される事も無い。 TypeScript の namespace について調べると公式では無い記事や投稿で非推奨（deprecated）というワードが目立つ事、tslint や typescript-eslint を使用していると namespace の使用で注意されてしまう事などから非推奨と認識されてしまっていると推測する。 個人的に「非推奨」という強いワードは「使用するな」というメッセージ性を感じる。開発者同士の間で誤解を生みかねないため namespace は非推奨では無いと伝え
JavaScript / TypeScript の豆知識 10 選 - Qiita
JavaScript / TypeScript の豆知識 10 選 初めに JavaScript / TypeScript にまつわる豆知識を、10 個ほど集めてみました。 コードは全て TypeScript で書いていますが、内容はほぼ全て JavaScript にも当てはまることです。 少し長めの読み物ではありますが、気軽に当記事を楽しんで頂ければ幸いです。 それでは、以下が目次です。 JavaScript / TypeScript の豆知識 10 選 初めに 1.Nullish と Falsy 関連参考資料_1 2. tsconfig の便利な設定 関連参考資料_2 3. 依存関係の綺麗な図示の仕方 関連参考資料_3 4.正しい XSS のやり方 関連参考資料_4 5.removeChildren 関連参考資料_5 6.数値型を関数の引数として使う時の小技 関連参考資料_6 7.hi
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Microsoft、「TypeScript」高速化のために開発した「Deopt Explorer」を一般提供／「V8」の内部構造を理解している上級ユーザー向けの「Visual Studio Code」拡張機能
