Storybook MCP を試してみた
Storybook MCP のセットアップ Storybook MCP を使用するには @storybook/addon-mcp アドオンが必要です。以下のコマンドでインストールします。 npm install @storybook/addon-mcp .storybook/main.ts ファイルを開いて、@storybook/addon-mcp をアドオンに追加します。 export default { "stories": [ "../src/**/*.stories.mdx", "../src/**/*.stories.@(js|jsx|ts|tsx)" ], "addons": [ "@chromatic-com/storybook", "@storybook/addon-vitest", "@storybook/addon-a11y", - "@storybook/addon-
Canvas 内に直接 HTML を描画できる HTML in Canvas API について
HTML in Canvas API は WICG の提案段階にある実験的な API です。現時点では Chrome Canary の chrome://flags/#canvas-draw-element フラグを有効にすることで利用できます。 HTML in Canvas API の使用方法 HTML in Canvas API は以下の 3 つの要素で構成されています。 layoutsubtree 属性 drawElementImage() メソッド paint イベント canvas 要素に layoutsubtree 属性を追加することで、canvas 内に描画したい HTML を定義できます。この段階ではまだ canvas 内には描画されません。 <canvas id="canvas" width="400" height="300" layoutsubtree> <div i
なぜJavaScriptのfetchはawaitを2回しないとレスポンスを取れないのか | maguro.dev
const resp = await fetch("https://api.example.com/data"); await を2回書いているのが気になったことはありませんか？1回の await で一気にレスポンスボディまで取れたら楽なのに、と思ったことはないでしょうか。 とある休日の午前中、いつものようにYouTube上でライブコーディング動画を見ていました1。そこで配信者の方が、fetchを使ってレスポンスボディを取得する際に2回目のawaitが必要であることに対して、「なんでfetchはこんなにめんどくさいんだろう」と言っていました。言われてみると、確かにめんどくさいような気もします。 この記事では、なぜ fetch がこのような設計になっているのかをいろいろな観点から掘り下げてみます。 fetch の使い方おさらい まずはJavaScriptのfetchの基本的な使い方を確認して
Reactコンポーネントの不要な再レンダリングを制御する。useMemo/useCallbackの使いどころとPropsの粒度管理 | レバテックラボ（レバテックLAB） - レバテックLAB
執筆 中川 幸哉 有限会社 WINGSプロジェクトが運営する、テクニカル執筆コミュニティ（代表：山田祥寛）に所属するテクニカルライター。新潟県上越市出身。会津大学コンピュータ理工学部卒業後、現在は新潟市に在住。ReactやAndroidを軸に、モバイルアプリ開発やWebサイト制作、Webメディア編集部の業務改善や、プログラミング技術記事の執筆等に携わっている。著書に『たった1日で基本が身に付く! Androidアプリ開発超入門』、『基礎から学ぶ React Native入門』 監修 山田 祥寛 静岡県榛原町生まれ。一橋大学経済学部卒業後、NECにてシステム企画業務に携わるが、2003年4月に念願かなってフリーライターに転身。Microsoft MVP for Visual Studio and Development Technologies。執筆コミュニティ「WINGSプロジェクト」代表
自己補正するコンポーネント: レンダリング中に状態更新する公式テクニックの解釈
Reactにおいてプロダクトの品質を高く保つには、Reactのやり方に合ったコードを書くことが重要です。公式ドキュメントの名物ページ「そのエフェクトは不要かも」には、useEffectの望ましくない使い方と、それに代わるテクニックが紹介されています。 この記事で取り上げるのは、その中でも「props が変更されたときに一部の state を調整する」のセクションで紹介されている、レンダリング中にステートを更新するテクニックです。 このテクニックは一見すると奇妙で、知ってはいるけど使っていいのかよく分からないという方も多そうです。しかし、一見突飛に見える記述でも、深く理解すれば実はReactのデザインに完璧に則っているというのがReactの公式ドキュメントの特徴です。技術に対する向き合い方として、公式の説明であっても妄信せず批判的に見ることはとても重要です。しかし、Reactの場合は最終的に
Storybook を MCP サーバ化したらフロントエンド開発が自動化される未来が見えた - PLAY DEVELOPERS BLOG
こんにちは。テックリードの丸山 @maruyamaworks です。最近は Claude Code に全部賭けています。 前回、GitHub Copilot を使って Storybook を作った話を書きました。 developers.play.jp 今回はその応用編として、Storybook を MCP サーバ化して LLM に提供することで、社内 UI コンポーネントを使用したフロントエンドの開発を自動化できるのではないか、ということで実験してみたいと思います。（これをやるために Storybook を作ったといっても過言ではない） 何をやろうとしているのか まずは先駆者から学ぼう MCP サーバを実装する 実際に試してみた 今後の展望 おわりに 何をやろうとしているのか この記事では何をやろうとしているのか、最初に概要を説明します。 やりたいことは、LLM にプロンプトを投げてコード
【結論】TypeScriptの型定義はtypeよりinterfaceを使うべき理由
はじめに TypeScriptでコンポーネントのPropsやオブジェクトの型を定義するとき、typeとinterfaceのどちらを使うべきか、一度は悩んだことがあるのではないでしょうか。 巷では「どちらでも良い」「チームで統一されていればOK」といった意見もよく見かけます。 しかし、私は 明確な理由をもって「基本的にはinterfaceを使うべき」 だと主張します。 この記事では私の実体験で遭遇したReactのPropsの深刻なパフォーマンス問題を例に交えながら、なぜinterfaceが優れているのか、そしてtypeはどのような場面で使うべきなのかを解説します。 type aliasを使いたくなる魅力と、その裏に潜む罠 まず、なぜ多くの開発者がtypeを選びがちなのでしょうか。 それは、開発体験の良さにあります。 typeで定義した型は、VSCodeなどのエディタでホバーすると、最終的に解
TreeShakableなResultライブラリを作りました
はじめに JavaScriptでは、throwを使ってエラーを明示的に投げることで、処理を中断する「大域脱出」が可能です。しかし、TypeScriptではこのthrowによって発生するエラーの型を記述できないため、型安全性が損なわれてしまいます。 この問題を解決するために、関数の成功・失敗を明示的に扱えるResult型が有用です。 TypeScriptでResult型を利用する場合、neverthrowやeffect-ts、fp-tsなどのライブラリがよく挙げられます。 しかし、それぞれ一長一短があり、neverthrowは比較的シンプルで使いやすいものの、現在は活発なメンテナンスが行われておらず、複数のPRが長期間放置されています。 effect-tsやfp-tsは高機能ですが、Result以外の多くの概念も含んでいるため、「Resultだけ欲しい」ケースでは導入コストが高く、バンドルサ
【TypeScript】カスタムエラーのすすめ
TypeScriptで開発をしていると、APIエラーやバリデーションエラーなど、さまざまなエラーを扱う場面があります。 そんなときに、標準のErrorクラスだけで対応していませんか。 この記事では、カスタムエラーを導入するメリットと、ボイラープレートを減らしてカスタムエラーを楽に定義出来るライブラリを紹介します。 カスタムエラーを作る理由 標準のErrorクラスを使用することで楽にエラーを作成できますが、次のような問題があります。 エラーの種類を区別しづらい 追加の情報（HTTPステータスやエラーコードなど）を持たせづらい メッセージが一貫しない たとえば次のような例を考えてみましょう。 try { throw new Error('User not found'); } catch (error) { if (error.message.includes('not found')) {
過激派が教える！ useEffectの正しい使い方
ReactのuseEffectは、フックの中でも使い方が難しいものの一つです。そこで、この記事では筆者が考えるuseEffectの望ましい使い方を皆さんに伝授します。 基本原則 技術やその要素の使い方を考えるにあたって、筆者が好んでいるのは基本原則を置いてそれに基づいて判断することです。ということで、この記事ではまず筆者が考えるReactの基本原則を紹介します。 筆者がもっとも重要視する原則は、ReactはUIライブラリであるということです。つまり、ReactにはUIの管理をさせるべきであって、その他のことはReactの役目ではないということです。Reactが難しいと思う人がいる場合、何でもかんでもReactにやらせようとするから余計に難しくなっているのだと思います。 例えばアプリケーションのロジックの管理やそれに付随するステートの管理はReactの役目ではないので、Reactの外部で処理
小手先に見えるテクニックでも、実はReact的に考えられる
皆さんこんにちは。React、使っていますか？ Reactを″正しく”使うことは難しいと感じる方も多いのではないでしょうか。 特に筆者はReactの正しい使い方に厳しく、こんな記事も出しています。熟練のReact使いでもなければ、この記事を読んで難しいと思うのも仕方がありません。 useEffectに関しては、React公式のドキュメントでも「そのエフェクトは不要かも」というページがあり、useEffectを使ってしまいがちだが、useEffectの使用が適していない場面について解説されています。 この記事の目的 上記の公式ドキュメントで解説されている中でもkeyを使うテクニック（あとでこの記事でも説明します）に関しては、今より未熟だった昔の筆者は、あまり良く思っていませんでした。なぜなら、それが 「Reactらしくない、小手先のテクニック」 に見えたからです。 しかし、よくよく考えれば、
モダンなフロントエンドにおけるテストについて ［Modern Featured Test］ | gihyo.jp
本連載について はじめまして！ サイボウズ フロントエンドエキスパートチームのnus3です。 本連載では、Webフロントエンドに関してもう一歩踏み込んだ知識について、サイボウズフロントエンドエキスパートチームのメンバーによって不定期で解説記事を掲載しています。 本記事では、モダンフロントエンドにおけるテストについて、その種類や導入方法などを紹介します[1]。 モダンフロントエンドでのテスト ここ数年のWebフロントエンドでは次のように、さまざまな変化がありました。 ReactやVue.jsといった宣言的UIを採用したライブラリの普及 TypeScript中心としたエコシステムの発展 ES Modulesの採用の広がり ViteやSWC、RspackやTurbopackなどの新しいビルドツールの登場 この変化に合わせて、Webフロントエンドを対象にしたテストのツールや手法も増えてきました。
React Ink によるリッチ CLI (ClaudeCodeの裏側のアレ)
(この記事の AI 成分は 5 割ぐらいです) claude-code や gemini-cli を触った人なら、やたらリッチな CLI のインターフェースが一体どうなってるか疑問に思ったはずです。 これは ink というライブラリで実装されています。実体は React のカスタムレンダラーで、React の差分レンダリングで CLI を構築することができます。 中では yoga というレイアウトエンジンが使われており、これは React Native でも使われているもので、 Web で display: flex を使ったときと同じレイアウト計算モデルになります。 つまり、 React や ReactNative の知識で CLI (TUI) の アスキーアートの UI を作ってるわけですね。 実際に作ってみた例 React Ink の可能性を探るべく、ターミナルで動くゲームを実装して
進化するPromiseオブジェクト ［JS Modern Features no.2］ | gihyo.jp
こんにちは！ サイボウズフロントエンドエキスパートチームの左治木です。 今回のテーマは「進化するPromiseオブジェクト」です。 Promiseは、非同期処理を管理するためのオブジェクトで、ECMAScript 2015 (ES6)で導入されました。ECMAScript 2017ではasync／await構文が追加され、非同期処理がより直感的に記述できるようになりました。現在では、async／await構文が非同期処理の主流となっています。 一方で、Promiseの機能はasync／await構文の登場後も進化を続けています。これにより、非同期処理がさらに扱いやすくなり、従来のPromiseでは難しかった細かい処理も可能になっています。今回は、ES2020以降で追加されたPromiseの新機能をユースケースを交えて解説します。 Promiseの基本を簡単におさらい Promiseは、非同
VoltAgent - Open Source TypeScript AI Agent Framework
import { openai } from "@ai-sdk/openai"; import { Agent, VoltAgent, createTriggers } from "@voltagent/core"; import { createPinoLogger } from "@voltagent/logger"; import { honoServer } from "@voltagent/server-hono"; import { weatherTool } from "./tools/weather"; const logger = createPinoLogger({ name: "with-slack", level: "info" }); const slackAgent = new Agent({ name: "slack-agent", instructions:
Storybook Play functionでAHA testingのすゝめ - LayerX エンジニアブログ
バクラク事業部でソフトウェアエンジニアをしている @ta1m1kam です。 フロントエンド開発において「どのテストをどれだけ書くべきか？」という問いは、誰もが一度は悩むテーマです。ユニットテスト？E2Eテスト？ビジュアルリグレッション？それぞれに役割があり、バランスが求められます。 Testing Trophy そんな悩みに対する一つの指針として、Kent C. Dodds氏が提唱した 「Testing Trophy（テスティング・トロフィー）」 という考え方あります。（提唱自体は2021年ごろなので、今では割と一般的になっているかなと感じています。） kentcdodds.com ポイントは「ピラミッド」ではなく「トロフィー」 この考えでは「最も費用対効果が高いのは統合テスト」だと指摘しています。 実際、アプリケーションでのユースケースを1つのコンポーネント単位でシナリオベースに検証で
「型システムのしくみ」発売のお知らせ - まめめも
「型システムの仕組み - TypeScriptで実装しながら学ぶ型とプログラミング言語」という本を書きました。 「型システムの仕組み - TypeScriptで実装しながら学ぶ型とプログラミング言語」 どんな本？ 簡単な型チェッカを自作してみることで、型システムの仕組みを概観する本です。 型チェックする対象の言語はTypeScript（のサブセット言語）、型チェッカを実装するための言語もTypeScriptです。 たとえば、次のようなプログラムが型チェックできるようになります。 const add = (x: number, y: number) => { return x + y; } const a = add(1, 2); const b = a + true; 型チェッカは、それぞれの変数がどういう型を持つか管理しつつ、プログラムの各パートがどういう型になるかを判定していきます。
ReactとCSSで一定時間表示される通知をやるときの色々な方法 - Qiita
フロントエンド、というよりUI一般では、ユーザーの操作に対してまったく無反応なのは良くありません。ユーザーが意味のある操作をしたならば、何らかのフィードバックを返すべきです。 例えば、何かをユーザーのクリップボードにコピーするボタンというのはありがちですが、クリップボードに何かを書き込んでもそれだけだと目に見える変化がないので、追加で「コピーしました」のような通知を出すというのはよくあるパターンです。 ここでは、そのような通知が、ちょっとフェードインしながら表示され、一定時間後にフェードアウトしながら消えていくという要件を想定することにしましょう。 transitionを使う基本的な実装 まずはReactの部分をざっくりお見せします。 import { useState } from "react"; import "./styles.css"; export default functi
TypeScript 5.8で条件付き戻り値型に対するナローイングができるようになりそう（特定の制約を満たす場合） - Mitsuyuki.Shiiba
数日前にTypeScript 5.7 RCがアナウンスされてリリースが楽しみだなー！ってところなんだけど、そのさらに数日前に、ウォッチしていたこのPR↓がマージされてTypeScript 5.8.0のマイルストーンに入った。わー！ これが今日のお話。TypeScript 5.8.0でConditional return type narrowingが入りそう。楽しみ！ Conditional return type narrowing? 直訳すると「条件付き戻り値型の絞り込み」かな。引数の型によって戻り値の型が変わる関数を定義したいときに、例えばこんな風に書きたくなる。 declare const record: Record<string, string[]>; declare const array: string[]; function getObject<T extends str
実践: await using でリソース開放
実践 いつ使うんだこれと思ってたら使う日が来たシリーズ。 今回、Deno で使ったんですが、 Node.js やブラウザでも Polyfill を入れれば動きます。 try finally で puppeteer を終了したい Deno で puppeteer を扱うために、こういうコードを書いてました。 // original import puppeteer from "npm:puppeteer@23.6.1"; import chromeFinder from "npm:chrome-finder@1.0.7"; let browser: puppeteer.Browser | null = null; try { browser = await puppeteer.launch({ headless: false, executablePath: chromeFinder(),
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
