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
近日連投していた Next.js 記事のサンプルコードを公開しました。このサンプルコードを元に、私のフロントエンドディレクトリ構成・テスト観点を紹介します(あくまで執筆現在の脳内アウトプットになりますのでご了承ください) フロントエンドディレクトリ構成の事情 タイトルの「フロントエンドディレクトリ構成」をさす「Components」のディレクトリ構成は、いつも悩みのタネです。このモジュールシステムは「デザインシステム観点・アクセシビリティ観点・フロントエンド実装観点」の 3 つの観点が混在するため事情が複雑です。どうせ作るのなら「デザイナー・フロントエンド」どちらの開発基盤にもなりえる、盤石なモジュールシステムを目指したいですよね。 "AtomicDesign やめました"という声をたまに聞くのですが「デザインシステム的に捨てていいの?」と思うこともあるので、とくに要望がなければ、筆者は「
ダイアログやハンバーガーメニューといったユーザーインタフェース(UI)は、多くのウェブサイトで利用されており頻繁に見かけます。どこでも見かけることから「簡単に作成できる」と思われがちですが、意外と実装が難しいUIです。たとえば、エンジニアでなくとも、以下のような現象に気付いたことはないでしょうか? ダイアログを表示中に、裏側のコンテンツがスクロールできてしまった ダイアログを表示中に、Tabキーでキーボード操作を行うと裏側を操作できてしまった ▼裏側がスクロールできてしまう例 ▼裏側がキーボード操作できてしまう例 これらを解決するためには、実装で注意する必要があります。本記事では、ダイアログやハンバーガーメニュー等のモーダル系のUIに存在する気付きづらい問題点と、解決方法を紹介します。ダイアログとハンバーガーメニューはそれぞれ役割の異なるUIですが、画面全域を覆うUIという意味において同種
はじめに 過去このブログでは Visual Regression Testing(以降 VRT)に関連した記事をいくつか書いてきました。 Puppeteer を使った Storybook の自動スクリーンショット撮影用のアドオンを作った - wadackel.me reg-viz のリブランディングをした - wadackel.me reg-cli の Report UI をリニューアルした - wadackel.me Storybook と reg-suit で気軽にはじめる Visual Regression Testing - wadackel.me 関連ツールへのコントリビュートから始まり、現在業務でも活用しています。業務で扱うプロジェクトでは、検証対象となるケースが約 2,500 程度になっていて、実行時間に不満が出るようになりました。 今年の 1 月頃にその不満を解消するため高
The Single-Dev Framework that Just Worksthe most productive way to build web applications in JavaScriptGet Started Redwood is the full-stack JavaScript application framework.Batteries, backend, React, conventions, and opinions included.
Unopinionated utilities for resizeable split views. Zero Deps Tiny: Each is between 1-2kb gzipped. Fast: No overhead or attached window event listeners, uses pure CSS for resizing. Unopinionated: Only compute view sizes. Everything else is up to you. Two utilities: Split.js - The original library, maintained since 2014, works with float and flex layouts. Supports all browsers. Split Grid - Success
const mikan = require('mikanjs'); console.log(mikan('常に最新、最高のモバイル。Androidを開発した同じチームから。')); /* <span style="display:inline-block" role="presentation">常に</span> <span style="display:inline-block" role="presentation">最新、</span> <span style="display:inline-block" role="presentation">最高の</span> <span style="display:inline-block" role="presentation">モバイル。</span> <span style="display:inline-block" role="
Dataflow Proposals とは 以下の5つのプロポーザルをまとめて Dataflow Proposals と呼んでいる。 Stage 2: Pipe operator Stage 1: Call-this operator Stage 1: Partial application(PFA) Stage 1: Extensions Stage 0: Function.pipe and flow 例えば Pipe operator, Call-this operator, Partial application を組み合わせると、以下のように書けるようになる。(提案段階なので変わる可能性アリ) import { getAuth, getIdToken } from "firebase/auth"; function isPublic(article) { return articl
try { const data = await fetchSomething(); // 正常系レスポンスの処理 } catch (err) { if (isAxiosError(err)) { // 異常系レスポンスの処理 } } 動機はつぎの 3 つです。 データ取得も宣言的に書きたいから データ取得に関係ない例外も catch してしまうから HttpError の集計に不便だから データ取得も宣言的に書きたいから 要約すると、データ取得時は常にこのように書きたい、という話です。useSWR・useQuery や apollo/client でお馴染みのインターフェイスです。 const { data, err, status } = await fetchSomething(); if (data) // 正常系レスポンスの処理 if (err) // 異常系レスポンスの処理
Intro 従来の History API を改善する Navigation API の仕様策定と実装が進んでいる。 これは、History API の使いにくかった部分を補うだけではなく、「JS で画面遷移をする」という現状のミッシングピースに取り組み、SPA が抱える多くの問題だけでなく MPA すら改善する可能性がある。 この API の目的と仕様を解説しつつ、実装のメモを残す。 画面遷移と SPA の軌跡 Web は HTML の取得と描画を繰り返す、画面遷移(Navigation)を前提としたアーキテクチャ(のちに SPA からの逆算で MPA と呼ばれる)が基本であり、ブラウザなどの実装もそれに最適化されている。 一方「アプリケーション」の設計手法をそのまま Web に持ち込んだ SPA は、この Navigation によってもたらされる UX の低下を防ぐ部分がある一方、既
そこそこの規模があるプロジェクトで実行すべきタスクを定義するとき、初手として Makefile を使いがち。 Pros make は事実上どんな環境にもあることを期待してよい シェルで実行されるコマンドをそのまま書ける タスクの依存関係が明示できる Cons make では positional arguments が使えない 少し複雑なことをしようとすると Makefile 専用の文法を覚える必要がある 現代では、ファイルベースのタスクの依存関係は make が発明されたころほどは必要ではない Docker とか Go とか Webpack がよしなにしてくれることが多い 例: docker compose のラッパー ちょっとしたコマンドのラッパーを書きたいことがある。Makefile を書きはじめたらすべてのエントリポイントを make にしたい。ということで、以下のような Make
fz-browse: fzfライクな自由度の高いインタラクティブな検索ツール、ただしブラウザに表示する fz-browseという、fzfライクなインタラクティブな検索ツールを書きました。 fz-browse自体は検索エンジンを持っているわけではなく、既存のripgrepやripgrep-allなどのツールと組み合わせて、インタラクティブな検索体験を自分で組み立てるツールです。 コマンドを組みあわせたインタラクティブな検索(絞り込み)はpercol、peco、fzfなどが有名ですが、これらは検索の結果や操作もターミナル上で行います。 ターミナルは、書籍や画像などのコンテンツを検索した結果を表示してもあまり楽しくない場合があります。 fz-browserでは既存のコマンドラインツールを組み合わせて検索するのは同じですが、この検索結果の表示や操作をウェブブラウザ上で行います。 ブラウザで表示でき
対象 業務レベルでサーバーサイドで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が正常に削除できること
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く