こんにちは！ サイボウズフロントエンドエキスパートチームの左治木です。 今回のテーマは「進化するPromiseオブジェクト」です。 Promiseは、非同期処理を管理するためのオブジェクトで、ECMAScript 2015 (ES6)で導入されました。ECMAScript 2017ではasync／await構文が追加され、非同期処理がより直感的に記述できるようになりました。現在では、async／await構文が非同期処理の主流となっています。 一方で、Promiseの機能はasync／await構文の登場後も進化を続けています。これにより、非同期処理がさらに扱いやすくなり、従来のPromiseでは難しかった細かい処理も可能になっています。今回は、ES2020以降で追加されたPromiseの新機能をユースケースを交えて解説します。 Promiseの基本を簡単におさらい Promiseは、非同
TSKaigi 2025 での発表資料です - スピーカーノート リポジトリ…
Storybook Play functionでAHA testingのすゝめ - LayerX エンジニアブログ
バクラク事業部でソフトウェアエンジニアをしている @ta1m1kam です。 フロントエンド開発において「どのテストをどれだけ書くべきか？」という問いは、誰もが一度は悩むテーマです。ユニットテスト？E2Eテスト？ビジュアルリグレッション？それぞれに役割があり、バランスが求められます。 Testing Trophy そんな悩みに対する一つの指針として、Kent C. Dodds氏が提唱した 「Testing Trophy（テスティング・トロフィー）」 という考え方あります。（提唱自体は2021年ごろなので、今では割と一般的になっているかなと感じています。） kentcdodds.com ポイントは「ピラミッド」ではなく「トロフィー」 この考えでは「最も費用対効果が高いのは統合テスト」だと指摘しています。 実際、アプリケーションでのユースケースを1つのコンポーネント単位でシナリオベースに検証で
はじめに 本当に悔しいし許せないし、エンジニアとして不甲斐ないです。2025年2月26日深夜にハッキングにあいました。どのように相手と繋がり、どのような手口でハッカーに資産を抜かれたか、コードベースで全てお伝えします。今後同じ被害に遭う方が少しでも減ることがあればこんな嬉しいことはないです。 コード解説、さらに対策案も書いていきます。もし他に良い対策案などあればコメントでご教示ください。 ハッカーとのやりとりの流れ ハッカーとは Linkedin でブロックチェーンを使ったプロジェクトを手伝ってくれないかという連絡がりそこからやりとりが始まりました。そして移行の大まかな流れは下記のような感じです。 Linkedinでプロジェクトを手伝ってほしいと言う内容でDMがくる Githubリポを見て実装できそうか確認してほしいと言われる 自分のGithubアカウントを共有してプライベートリポジトリに
TypeScript開発にモジュラーモノリスを持ち込む - Sansan Tech Blog
Bill One Entry*1の秋山です。 本題へ入る前にお知らせです。12/23、TypeScript を活用した型安全なチーム開発をテーマにイベントを開催します。弊社社員のうち、TypeScript を日々の開発で活用しているメンバーが登壇します。ぜひお気軽にご参加ください。 sansan.connpass.com はじめに モジュラーモノリスとは 保守性が低いとビジネスに悪影響を与える 技術的負債と開発生産性 コード品質とビジネス影響 モジュール分割の方針 方針１：モジュールにDBテーブルを専有させる 補遺：モジュラーモノリスとNoSQL 方針２：モジュール内をレイヤードアーキテクチャとして構成する 方針３：ESLint ルールによって実現する TypeScript 開発にモジュラーモノリスを持ち込む ステップ１：単一のエイリアスを設定する ステップ２：ESLint ルールを設定す
実践: 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(),
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
先日、Kamal 2でNext.jsを安価なVPSにデプロイする勉強をしながら、Next.js App Router/Server ActionでCRUDのデモアプリを作成しました（コードはGitHub）。そのときにセキュリティについて気になって点がいくつかあり、勉強しながら対策をしましたので紹介したいと思います。 私自身は業務でNext.jsを書いた経験が限定的です。的外れな議論をしているかもしれません。あくまでもRuby on Railsアプリを書くときと同じ気持ちでNext.jsのアプリを書いたとき、セキュリティ上で気になった点を挙げているだけです。私が見落としている点や誤っている点等ありましたら、コメントやX等で教えていただけると大変ありがたいです。 その１：データ漏洩の危険性 この問題についてはムーザルちゃんねるが紹介しています。またNext.jsの公式ブログでも対策が紹介されて
はじめに 前にも別のモデルでやってる ただ o1-preview は、やり取りを重ねるよりも一発で終わらせるほうがいいらしいので、最終的なテスト全体を渡すようにした。 情報の提示方法が異なると当然結果も変わるので、 gpt-4o でも同様なことを試した。 材料 プロンプトは以下。 基本的に最初にやったときと同じ。ペアプロではないのでその部分の調整をしている - 私がテストコードを提示するのでそのテストケースをパスする最小限の実装をしてください - Vue.js のバージョン 3 と Typescript で実装を行ってください - コードのみを示してくださいコードの解説などは必要ありません - スタイリングは必要ありません - テストケースに失敗したらその内容をチャットで送信するので最小限のコードの修正をしてください - テストのコードには vitest を利用しています jest と互換
process.getBuiltinModule(id) は TypeScript を ESM 化させるか？
こんにちは teppeis です。普段は開発本部長をやってますが、ブログフェスに駆り出されました！ 本日は Node v22.3.0 に続いて v20.16.0 にもバックポートされた process.getBuiltinModule(id) について解説します。 問題: 同期的な条件付き require を ESM 化できない Node v22 にて、フラグ付きで CJS (CommonJS Modules) から ESM を require できるようになりました。いわゆる require(esm) です。これにより、今までは互換性の懸念で ESM 化を足踏みしていた著名ライブラリも ESM 化を試みる動きが出てきました。 TypeScript もその一つで、TypeScript チームは TypeScript 自体を ESM 化しようと試みました。しかしながら、今回の主題である条件付
Storybook 8.2
Storybook is the component workshop behind the world’s top design systems (Carbon, Polaris, Fluent, Lightning, etc.). Accordingly, it is often associated with building and documenting atomic components for reuse. But UI components come in many sizes and shapes. For teams at Faire, Yoobic, and Monday.com, Storybook is the tool of choice for “product UI” such as shopping carts, dashboards, chat widg
Next.js AppRouterで利用できるReactのServer Actions機能。クライアントからサーバ上の処理を関数で呼び出せるので非常に便利ですが、 "use server"; のことをあまり知らず、誤った使い方をすると意図せず公開したくない関数が外部に公開されてしまうケースがあるので注意です（ほとんどこんなケースはないと思いますが、なくはないので注意喚起です）。 Server Actionsの例 Server Actions用の関数として宣言するためには "use server"; が必要です。それ以外は至って普通の非同期関数で大丈夫です。 "use server"; export async function someAction() { return { message: "Server Action", }; } 次に定義したServer Actionsの関数を呼び出
今回の記事はasync/awaitについて。 C#に限らず、現在では多くのプログラミング言語が非同期処理を扱う言語機能としてasync/awaitを採用しています。現在の.NETでも至る所にasync/awaitが使われており、避けて通ることはできない重要な機能となっています。 そこで今回は、C#における非同期処理とasync/await、またC#8.0で導入された非同期ストリームとIAsyncEnumerable<T>について、基本的な使い方を解説していきます。 また、記事の後半では実際にasync/awaitがどのように動作しているかをコンパイル結果を通して説明していきます。この辺りはやや高度なトピックになるため読み飛ばしていただいても構いませんが、async/awaitをより深く理解したい方は是非そちらも読んでみてください。 同期処理 / 非同期処理 async/awaitに関する話
JavaScript において、特に苦手とする人が多い印象のある Promise ですが、await と async の文法が導入されたことで、Promise の仕様を深く理解しなくても非同期処理を自然に書けるようになってきたのではないかと思います。 極論ですが、JavaScript の非同期処理は async await new Promise のみで、（ほぼ）全て表現可能です。特別な理由がない限り then を使わないようにしましょう、ということを周知するのがこの記事の目的です。 なお本記事では Promise の rejected の状態についてほとんど解説しておりません。基本を理解したら、別記事でぜひ学んでみてください。 Promise とは？ Promise は、少し乱暴に説明すると「実行が終わっていないかもしれない何らかの関数」を包んだオブジェクトです。 普通の関数とは違って、
Result 型 (類似するものとして Either Monad の方が有名かもしれません) を導入する場合、アプリケーション全体の設計を変えたり、全箇所を書き換える必要はありません。 neverthrow は部分的に使用でき影響範囲も閉じるので、局所的に使い始めることができます。 (Rust のような) Result 型 とは ざっくり言うと関数の処理の結果と成否を 1 つの型 Result<T, E> で表したものです。(T は期待する結果の型、 E はエラーを表現する型) 筆者は詳しくはないのですが、 Haskell 等にある Either<L, R> とは厳密には違うようです(Either は両方の値が使用可能であることを前提としている？) 参考: Rust ではなぜ、Either 型ではなく Result 型を採用しているのか neverthrow とは TypeScript で
この記事はTSKaigi2024での以下の私の発表内容を書き下ろしたものです。 なぜAPIに型をつけたいのか 現代のWebのシステム開発において、クライアント・サーバーともに型のある言語で開発されることが増えてきました。静的な型検査はコードの堅牢性やよりよいメンテナンス性の向上をもたらします。 プログラミング内部だけで型検査をするだけでも十分メリットはありますが、外部I/Oに対する型付けが不十分だとそのメリットを最大限に発揮してるとは言えません。外部I/Oとは、例えばWebフロントエンドだとLocalStorageやDOMからの入力値、それからネットワーク通信（今回はこれをAPIと呼びます[1]）などですね。サーバー側でいうとAPIからの入力・レスポンスやデータベースへの読み書きが該当します。 個人的な経験から言うと、Webシステムの開発におけるエラーの多くはAPIやデータベースとのやり取
■今回の環境（Python） 今回のPythonはバージョン3.8.5を用いる。（Mac OS） ■asyncとawaitキーワードを使用し複数の非同期処理を並行して実行するでは、asyncとawaitキーワードを使用し複数の非同期処理を並行して実行するスクリプトを書いていきます。 ■コードimport asyncio # 非同期関数 async def fetch_data(url): print("データ取得開始:", url) await asyncio.sleep(2) # ダミーの非同期待機（2秒） print("データ取得完了:", url) return "Data from " + url # メイン関数 async def main(): # 非同期処理の並行実行 tasks = [ fetch_data("https://www.baidu.com"), fetch_d
■今回の環境（Python） 今回のPythonはバージョン3.8.5を用いる。（Mac OS） ■asyncとawaitキーワードを使用してカウントダウンの作成では、早速asyncとawaitキーワードを使用してカウントダウンの作成するために、コードを書いていきます。 ■コードimport asyncio # 非同期関数 async def count_down(): print("カウントダウンを開始します") for i in range(10, 0, -1): print(i) await asyncio.sleep(1) # 非同期に1秒待機 print("カウントダウンが終了しました") # イベントループの作成と実行 loop = asyncio.get_event_loop() loop.run_until_complete(count_down())まずimportでas
新しくCJSとESMの間での解決方法が変わる提案が出てきました。 まだマージされてませんが、すでに複数の承認があり、この方針から変わることはないように見えるので紹介したいと思います。 module: support require()ing synchronous ESM graphs by joyeecheung · Pull Request #51977 · nodejs/node Summary This patch adds require() support for synchronous ESM graphs under the flag --experimental-r... 新しい提案 この仕組みを利用する場合、--experimental-require-moduleフラグが必要となります。 以下は、わかりやすいようにpackage typeを指定せずにデフォルトはCJS
Web アクセシビリティに興味があったので、まず機械的なチェックツールから学んで知識を増やそうということでこのサイトに @axe-core/playwright と markuplint を導入してみました。 @axe-core/playwright のセットアップ 既に Playwright が導入されている状況を想定し進めます。まず@axe-core/playwright をインストールします。 pnpm add -D @axe-core/playwright このサイトの場合 VRT として Playwright を動かしているテストがあるので(過去資料)、そのプロセスに同居する形で axe を実行することにしました。 e2e.test.tsimport AxeBuilder from "@axe-core/playwright"; import type { Page, TestI
[beta] Next.jsクイズ2 • <p>にはなにが表示されるでしょうか？ /app/page.tsx "use client"; import { useCallback, useEffect, useState } from "react"; export default function Home() { const [date, setDate] = useState(); const fetchDate = useCallback(async () => { const response = await fetch("/api"); const data = await response.json(); setDate(data.date); }, []); useEffect(() => { fetchDate(); }, [fetchDate]); return ( <
追記 コメントありがとうございます、ご指摘を参考に読みやすくなるように修正しました！ はじめに (本記事は初歩的な内容ですが、少なくとも僕は引っかかったので記事化したものです) Cookie に HttpOnly という属性があります。 この HttpOnly を設定することで JavaScript からの直接の参照・操作を禁止することによって、XSS などの手法によって悪意のある第三者から Cookie の内容を見られるのを防止することができます。 ここまでは多くの記事に書いてあるのですが、私は一点ずっと勘違いしていました。 いや、直接値を読み取れないってだけで、API呼び出しとかの時に使えないってわけじゃないんかーーーーーーーーーーい！！！ いや、まあそれすらできなかったら何のための Cookie なんですかという話なのでそりゃそうなんですが... ということで見ていきます。 実装例(
令和最新版 CoffeeScriptで書かれたnodeと上手くやっていく方法、そして決別 <わかれ> - moznion
moznion サーバーサイドエンジニア Seattle, Washington在住 10年モノのCoffeeScript on node というのは若干言いすぎで、およそ9年モノです 2014年当時の状況 ES2015以前 (そりゃそう) Babelはあった TypeScriptブレイク以前 (だいたい2016年くらいから広くproduction readyになったという印象) AltJSの萌芽 => この時点でCoffeeScriptを採用したのは間違いではないはず...... 2023年現在の状況 JavaScriptの言語機能がめちゃ拡張された TypeScriptがメジャーに DHH、TypeScriptをやめる => CoffeeScriptを使うメリットはおそらく失なわれたと言ってもよい (このへんを参考にした: https://yosuke-furukawa.hatenab
GraphQL のレスポンスのモックデータの作成を補助する TypeScript ライブラリを作った - mizdra's blog
GraphQL を使って Web アプリケーションを実装していると、GraphQL API のリクエストをモックしたいことがあると思います。 ユニットテストのために、ダミーレスポンスに差し替えたい ビジュアルリグレッションテストのために、ダミーレスポンスに差し替えたい Storybook で story を書くために、ダミーレスポンスに差し替えたい バックエンドの resolver 実装を待たずにフロントエンド側の開発を始めるために、ダミーレスポンスに差し替えたい 一般には GraphQL Client にモックするための機能が実装されてるので、そうしたものを使うことが多いと思います。 zenn.dev また最近は Client よりも外側のレイヤーでリクエストを interrupt してモックする「msw」を使うケースも増えてきてます *1。 blog.engineer.adways.n
こんなPromiseを書いたりしていませんか？ Node.jsでJSを書いていて、非同期通信にPromiseを使うことはよくありますよね。 非同期なのでエラーになることも考えtry-chatch文を使って安全性にも配慮が必要です。 例えばこんなコードはどうでしょうか？ コード例 try { await getPromiseResolve(); //←resolveするだけのPromise new Promise((resolve, reject)=>{ reject("[test]:promise reject"); }) .then((result) => { console.error("promise -> then : result =", {result}); }); } catch (error) { console.error("promise -> catch: error
はじめに promiseを使うとき、いつもpromiseメソッドチェーンで記載していますか？ async/awaitを利用していますか？ もちろん状況によって両方書くのが殆どだとは思うのですが、私はasync/awaitの方が同期的な書き方ゆえに読みやすいため、なるべくそちらで記載しています。しかしながら、エラーハンドリングが理解できていなかったため、エラーの所在を突き止めるのに苦労してしまいました。 そのため、これを機にasync/awaitにおけるエラーハンドリングについて備忘録的にまとめておきます。 この記事のまとめ; catchされるエラーはrejectのみか、throwされたエラーも含まれるか →両方catchできる async関数における処理の順序、awaitがある場合とない場合 →awaitがない場合には同期的に処理が実行され、catchできなくなる エラー処理を外側に伝播し
■今回の環境（Python） 今回のPythonはバージョン3.8.5を用いる。（Mac OS） ■asyncとawaitキーワードを使用して非同期関数と非同期処理を行うでは、早速asyncとawaitキーワードを使用して非同期関数と非同期処理を行うために、コードを書いていきます。 ■コードimport asyncio # 非同期関数 async def print_message(message): print("処理を開始します") await asyncio.sleep(1) # 非同期に1秒待機 print(message) print("処理が完了しました") # イベントループの作成 loop = asyncio.get_event_loop() # 非同期関数の実行 loop.run_until_complete(print_message("Hello, World!"))
はじめに 登壇版 Taskの本質 C# のイテレータ async/await Compiler Transform ExecutionContext builder.Start() の重要性 IAsyncStateMachine.MoveNext おわりに はじめに C#er は呼吸するように使っている async/await。 そんな async/await について、先日 Stephen Toub 氏 (.NET の中の人。中心人物の一人。) が How Async/Await Really Works in C# という非常に面白い記事を投稿していました。 この記事では Stephen 氏の記事をベースに、C# において async/await は実際どうやって動いてるの？というお話をしていきます。 以前に C#での非同期メソッドの分析。 という翻訳記事を書いたのですが、元になった記
前編と後編の2部構成にしています。 前編は【今までのReactらしい状態管理術】 後編は【Next.js 13 /app (React Server Components) らしい状態管理術】 の説明です。両者を比較します。 コンポーネント単位でサーバー側のレンダリングを選択できるので、GraphQLでなくてもバックエンドへのアクセスを纏められたり、あらかじめサーバー側でデータを加工することで、バンドルサイズ0を目指せる React Server Components 。 これは周知の通り、クライアントコンポーネントとサーバーコンポーネントに分かれますが、 useState や Recoil などはサーバーコンポーネントでは利用できないので、 Next.js 13 /app （React Server Components） らしい状態管理術はこんな感じになります。 サーバーコンポーネント
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに C#におけるasync/awaitを使う上で、絶対に意識しないといけないものは「キャンセル処理」です。 正しく処理をキャンセルしないとメモリリークを起こしたり、デッドロックやデータ不整合を引き起こす可能性があります。 今回はこの「async/awaitにおけるキャンセル処理」について話します。 対象 C#におけるasync/await全般 Task/ValueTask/UniTaskすべてに共通します Unity含む C#のasyc/awaitについてイマイチ自信が持ててない人 先に「結論」 asyncメソッドはCancell
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに C#におけるasync/awaitを使う上で、絶対に意識しないといけないものは「キャンセル処理」です。 正しく処理をキャンセルしないとメモリリークを起こしたり、デッドロックやデータ不整合を引き起こす可能性があります。 今回はこの「async/awaitにおけるキャンセル処理」について話します。 対象 C#におけるasync/await全般 Task/ValueTask/UniTaskすべてに共通します Unity含む C#のasyc/awaitについてイマイチ自信が持ててない人 先に「結論」 asyncメソッドはCancell
はじめに ncaq氏の記事を読んで様々なことを学習できました。 asyncが「syncしない」なのにawaitが「waitする」なのは何故か。awaitがasync waitであるという説は正しいのか。async/awaitの語源について学習したことを記事にしました。 asyncとawaitのa-の違い asyncはsynchronize（同期）にa-（否定）が付いてasync（同期しない）となります。 awaitはwait（待つ）にa-（否定）が付いて「待たない」となりません。a-（方向）が付いてawait（待つ）となります。 a-（否定）とa-（方向）の違いです。 a-（否定）は「エイ」と発音する傾向 asynchronous エイスィンクロナス 非同期 Ajax エイジャックス(Asynchronous JavaScript And XML) asymmetry エイスィメトゥリィ
RFC: First class support for promises and async/await by acdlite · Pull Request #229 · reactjs/rfcs
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
Intro Fetch API の実装が広まり、IE もリタイアを迎えたことで、今後忘れ去られていくことになるだろう XMLHttpRequest について。 どのように始まり、どのように広まり、どのように使われなくなっていくのか。その間に残した多大な功績を残す。 XMLHttpRequest の始まり この名前は非常に長いため、通常 XHR と略される。 この API は、現在の Web API のように W3C/WHATWG による標準化を経て策定された API ではない。Microsoft によるいわゆる独自実装の API として始まり、後追いで標準化される。 したがって、Web API の中でもかなり異質な命名である XHR が、XmlHttpRequest でも XMLHTTPRequest でもなく XMLHttpRequest である理由も、Microsoft の命名規則に「
DDDにおけるRepositoryパターン
Repositoryパターンについて再学習した際の備忘録です。 Repositoryパターン ドメインオブジェクトの集まり (以降、集約)を抽象化する設計手法。 DAO(DataAccessObject)とよく似ているが、DAOはデータアクセスの処理を抽象化する手法であり、Repositoryとは意識する点が真逆になっている。 また、DAOはクラスの分割方法については定義されていない点がRepositoryとは違う所となる。 データアクセスの抽象化という観点から、ORMもDAOの一種とも言える。 その特徴からRepositoryの内部でDAOを使用してデータを取得する事はあるが、逆にDAOの内部でRepositoryを使用してデータを取得する事は基本的には無い。 interface PostRepository { findById(postId: PostId): Promise<Pos
実装例から見る React のテストの書き方 - Cybozu Inside Out | サイボウズエンジニアのブログ
2024/04/17: 更新 内容を更新した記事を書きましたので、よかったらこちらも併せて、ご覧ください。 zenn.dev こんにちは！フロントエンドエキスパートチームの@nus3_です。 kintone のフロントエンド刷新プロジェクト（フロリア）では、品質を保ったまま開発を加速させるためにフロントエンドのテストを積極的に行っています。 今回はそんなフロントエンドのテストの実装例をいくつか紹介します。この記事がフロントエンドのテストを行う上での参考になれば幸いです。 テストに使用する主なパッケージ コンポーネントのテスト 補足: Testing Library の記法をチェックしてくれるeslint-plugin-testing-library カスタムフックのテスト 補足: React v18 では @testing-library/react の renderHook を使う 参考
どうも。CX事業本部Delivery部のえーたん（@eetann092）です。 今まで雰囲気でJavaScript（TypeScript）のasync/await、Promiseを使っていて最近苦しんだため、ハマったところの例と対策を備忘録として残しておきます。 await付け忘れ やらかした例 まず、awaitを付け忘れた例です。 import { setTimeout } from "timers/promises"; const unit = 1000; async function logSleepLog(msg: string) { console.log(msg); await setTimeout(1.5 * unit); console.log(msg); } (async () => { logSleepLog("hoo"); console.log("finish");
async/awaitの鬼門の一つとして、適切なキャンセル処理が挙げられます。別に基本的にはそんな難しいことではなく、CancellationTokenSourceを作る、CanellationTokenを渡す、OperationCanceledExceptionをハンドリングする。というだけの話です。けれど、Tokenに手動でコールバックをRegisterしたときとか、渡す口が空いてないものに無理やりなんとかするときとか、タイムアウトに使った場合の始末とか、ちょっと気の利いた処理をしたいような場面もあり、そうした時にどうすれば良いのか悩むこともあります。 こういうのはパターンと対応さえ覚えてしまえばいい話でもあるので、今回はAlterNatsの実装時に直面したパターンから、「外部キャンセル・タイムアウト・大元のDispose」が複合された状況での処理の記述方法と、適切な例外処理、そして最
皆さんこんにちは。現在、フロントエンドでは宣言的UIが大流行しており、そのためのライブラリもReactを筆頭に複数存在しています。 ライブラリが複数存在するところには当然のように比較や論争が起こるものですが、UIライブラリの場合はパフォーマンスがよく焦点となります。 筆者はReactの信者ですが、Reactは古株ということもあってか、最近の議論ではReactは他のライブラリと比較されるかませ犬のような役割を担うのがよく見られます。「仮想DOMは必要ない」といった類のものです。 しかし、筆者の考えではReactは今でも、もっとも真剣にパフォーマンスに取り組んでいるUIライブラリです。特に、Reactはパフォーマンスを高いユーザーエクスペリエンスのための手段として捉えており、ドキュメントにもユーザーエクスペリエンスという言葉が多く出てきます。 そこで、今回はReactが最も有利になるようなベン
jestでDBありのテストを高速化する
課題link お手伝いしているシステムでNestJSを採用しているバックエンドのテストが遅いという課題があったので対処した。 前提link フレームワークDBテストランナーその他 テストの総数は700弱。 最終結果link 最終的には2段階の改修を経てローカルのテストが3倍速程度高速化した。 # before Test Suites: 145 passed, 145 total Tests: 2 skipped, 681 passed, 683 total Snapshots: 0 total Time: 925.063 s Ran all test suites. Done in 926.48s. # ts-jestを@swc/jestに置き換えた Test Suites: 145 passed, 145 total Tests: 2 skipped, 681 passed, 683 t
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
進化するPromiseオブジェクト ［JS Modern Features no.2］ | gihyo.jp
君だけのオリジナル async / await を作ろう / TSKaigi 2025
Web3開発者をねらったハッキング手口の全て（わたしは全て抜かれました...）
Taskを返すeventをawaitで待ってはいけない（気付きづらいうっかりミスの紹介） - Qiita
Next.jsで簡単なCRUDアプリを作りながら気になったセキュリティ: Railsの視点から
ChatGPT (o1-preview) にテストを渡してコードを実装させるとどうなるか試した
"use server"; でexportした関数が意図せず？公開される
【C#】非同期処理とasync/await - Annulus Games
JavaScript で then を使うのは避けよう（await / async の初級者まとめ）
neverthrow で局所的に Result 型を使い、 try-catch より安全に記述する
TypeScriptとGraphQLで実現する型安全なAPI実装
Pythonでasyncとawaitキーワードを使用し複数の非同期処理を並行して実行する
Pythonでasyncとawaitキーワードを使用してカウントダウンを作成する
Node.jsに入る新しいCJSからESMへの読み込み方法の紹介 - hiroppy's site
axe-core/playwrightとmarkuplintを導入しアクセシビリティの自動テストをできるようにした
You Don't Need Next.js | ドクセル
Cookie の HttpOnly 属性について勘違いしていたこと - Qiita
Promise.thenとasync/awaitは混ぜるな危険。まぎらわしくてcatch処理を書き忘れる
async/awaitにおけるエラー処理を実行の順番から整理する - Qiita
Pythonでasyncとawaitキーワードを使用して非同期関数と非同期処理を行う
【C#】C# の async/await は実際にどうやって動いているか。 - ねののお庭。
(Next13 /app) React Server Components 時代の状態管理術【前編】
【C#】async/awaitのキャンセル処理まとめ - Qiita
【C#】async/awaitのキャンセル処理まとめ - Qiita
async/awaitのaの違い～async wait説への反論 - Qiita
XMLHttpRequest とはなんだったのか | blog.jxck.io
async/await周りで苦しんだ箇所の例と対策 | DevelopersIO
neue cc - async/awaitのキャンセル処理やタイムアウトを効率的に扱うためのパターン＆プラクティス
Reactに有利なベンチマークを作ってみた - Qiita