markuplint で HTML の構文チェックを始めよう
ブラウザが HTML を解釈する方法はその他のプログラミング言語と比べてはるかに寛容です。ブラウザは HTML 内に構文エラーを発見しても大抵の場合は問題なくページに表示されます。ブラウザには、誤って書かれたマークアップを解釈する方法を決定するための組み込みのルールがあるためです。 例として以下のコード例を確認してみましょう。<ul> タグは仕様でその子要素には 0 個以上の <li> タグまたは script supporting elements (<script> と <template>)のみが許可されています。従って、<ul> タグの子要素に <a> タグを配置している以下のコードは構文エラーとなります。 <ul> <a href="/home">Home</a> <a href="/about">About</a> <a href="/blog">Blog</a> <a hre
【Vue.js】ref と reactive どっちを使う？
Vue.js の Composition API が登場してから 1 年少しが経過しており、すでに使いこなしている方もいらっしゃるのではないでしょう？ 私自身お仕事で Composition API を使用しており、従来の Options API と比較して UI とロジックの分解がよりやりやすくなったように思えます。リアクティブなデータをコンポーネントの外で定義できるようになったことで、1 つのコンポーネントにまとめて書かざるをえなかった論理的な関心事に分けてそれぞれ別のファイルで定義できます。 書き心地としては React のカスタムフックに近い感じとなっていますね。 個人的には React がクラスコンポーネントから関数コンポーネント + Hook へ移行したように、Vue.js においても Composition API へ移行する流れが来るのではないかと思います。 さて、そんな
Playwright でコンポーネントテスト
Playwright は Cypress Puppeteer と並ぶ E2E テストのための Node.js フレームワークです。Chromium, Chrome, Edge, Firefox, Webkit (Safari)と多くのブラウザに対応しているという特徴があります。 そんな Playwright ですが v1.22.0 から React,Vue.js,Svelte のコンポーネントに対してテストを実行できるようになりました。つまり、もともと備えていた E2E レベルのテストに加えて、結合レベルのテストまでカバーできるようになったということです。 Playwright のコンポーネントテスティングの特徴と使い方を見ていきましょう。 Playwright でテストを書くメリット 現状フロントエンドにおいて、コンポーネントテスティングを実施する際に使用されるフレームワークとして Te
JSDocで型を定義してTypeScriptの恩恵を受ける
普段から TypeScript で開発されているほうならば、TypeScript の恩恵を十分に堪能されていることと思います。 特に私は VS Code のインテリセンスには頼りっぱなしでこれがなければまともにコーディングができない体になってしまいました。 しかし時には、TypeScript という概念が存在しない退屈な世界で開発を行わなけらばならない状況はあるでしょう。私はもはやキーボードでタイピングすることすらままなりません。 そんな JavaScript しか利用できない状況で代替手段となるのが、JSDoc です。JSDoc のアノテーションによって型を付与することによって最低限の支援を受けることができます。 @Type @Type タグを使用すると、TypeScript で型をつけるときと同じように型を宣言できます。
フロントエンドのテストのモックには msw を使うのが最近の流行りらしい
皆様フロントエンドのテストを書いていらっしゃいますでしょうか？ フロントエンドのテストを書くときには API コールする処理を全てモックする必要があります。外部の API をコールする処理をテストに含めると API サーバーが落ちているなどの外部の要因によってテストが失敗してしまう可能性がありますし、テストを実行するたびに実際に API をコールしてしまうとサーバーに負荷がかかってしまうなど外部に対しても悪影響を与えてしまいます。 さて、従来のモックする手段としては Jest のモックを利用して axios や fetch などのモジュールをモック化する手法がよく使われていたかと思います。 最近のテスト手法として API コールをモックする際に Jest ではなく Mock Service Worker (以下 msw ）を使用する手法が注目されています。実施にどのように使用されているのか
Storybook でインタラクションテストを作成して Jest で再利用する
Storybook の Component Story Format 3.0 では新機能として play() 関数が追加されました。 play() 関数は Storybook 上で ユーザーのクリックやフォーム入力のようなインタラクションな操作を表現することができます。 play() 関数の大きな特徴としては Component Story Format の移植性の高さを利用して Storybook 上で定義したインタラクションを Jest など他の領域においても再利用できることです。 この記事では Vite に Storybook を導入してインタラクションテストを作成して Jest で再利用するまでの手順をやってみたいと思います。 Vite プロジェクトの作成 まずは以下コマンドで Vite プロジェクトを作成します。
Vue 向けの Vite 製の UI コンポーネントカタログツール Histoire
Histoire はフランス語で「Story」という意味の単語であり、Storybook のように UI コンポーネントのカタログを作成するツールです。 Histoire は以下のような特徴を謳っています。 Vite にネイティブ対応 Histoire は Vite 向けのツールであるので、vite.config.ts の設定を再利用できます。このあたりの特徴は Vitest と同様ですね Story をフレームワークそのままの書き方で作成できる Storybook の場合 Vue で SFC ファイル形式のコンポーネントを作成していたとしても、Story を作成する場合には .stories.ts のような拡張子でファイルを作成して Storybook 向けのコンポーネントの記述をする必要があります。一方 Histoire は Story を作成する際にも .vue や .svelte
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
