一休レストランの XState 導入記 - 一休.com Developers Blog
このエントリーは 一休.comのカレンダー | Advent Calendar 2023 - Qiita の22日目の記事です。 レストランプロダクトUI開発チームの鍛治です。 一休レストランのフロントエンドを担当しています。 一休レストランでは Next.js App Router Remix を採用しています。 user-first.ikyu.co.jp 昨年の終わり頃から始まった一休レストランのリニューアルですが、フロントエンドは Nuxt v2 (Vue 2) から Next.js App Router (React) に、という大きな切り替えで、不慣れだった我々は React 初心者がひっかかる落とし穴を全部踏み抜いてきました。 例えば、チュートリアルに従って useState で変化する状態を定義して、最初はそれで全てがうまくいっていました。機能追加していく過程でいつの間にか一
一休レストランで Next.js App Router から Remix に乗り換えた話 - 一休.com Developers Blog
このエントリーは一休.com Advent Calendar 2023の15日目の記事になります。 CTO 室の恩田です。 現在は一休レストランのフロントエンドのリアーキテクトを手がけています。 今日はその中で Next.js App Router から Remix に乗り換えた話をご紹介したいと思います*1。 背景 6日目の記事で香西から紹介させていただきましたが、2023年10月に一休レストランのスマートフォン用レストラン詳細ページをリニューアルしました。 一休レストランの Rust バックエンドが正式リリースされました。https://t.co/7N4VGv5ej9 このページのスマートフォンビューはバックエンドが Rust で書かれた GraphQL になってます— naoya (@naoya_ito) 2023年10月4日 ちなみにフロントエンドも、旧バージョンは Nuxt v2
React / Remix への依存を最小にするフロントエンド設計 - 一休.com Developers Blog
CTO 室の恩田(@takashi_onda)です。 一休レストランのフロントエンドアーキテクトを担当しています。 Intro 一休レストランでは、以前ご紹介したようにフロントエンドで React / Remix を利用しています。 user-first.ikyu.co.jp 一方、設計方針としては、React / Remix への依存が最小になるように心掛けています。 今日は、そんな一見矛盾するような設計方針について、ご紹介したいと思います。 この記事を読んでいただき Remix に興味をもたれたら、明後日 2024/8/7(水) 19:00〜 のオンラインイベント offers-jp.connpass.com にもご参加いただけると嬉しいです。 この記事でご紹介している疎結合なフロントエンドアーキテクチャを実現する Remix の魅力についてお話します。 なぜ依存を最小にするのか？ R
【React】リッチテキストエディタ（Quill、Tiptap、Slate...）の考え方や前提知識
概要 4年ほどProductionで使っていたリッチテキストエディタ（Quill on Nuxt.js v2）をTiptap on Next.jsに移行しました。 既存のQuillエディタの使い勝手をTiptapで再現しつつ、改善できるところは改善しつつ、既存の4年分のリッチテキストデータが正しく編集できるようにしなければいけませんでした。 本記事では移行の具体的なプロセスを解説しようと思っていたのですが、リッチテキストエディタは前提知識があまりに多いため、前提となる知識や考え方を解説しているだけでそこそこのボリュームになりました。そこで、一旦考え方や前提知識をまとめた、という体で公開します。 本記事を読んでから各ライブラリのDocsを読んだりカスタマイズを始めたら、少しハードルが下がっていることかと思います。 対象読者の例 リッチテキストエディタに興味がある リッチテキストエディタの開発
ecspressoを活用したECSデプロイの改善 - LayerX エンジニアブログ
2月にバクラク事業部Platform Engineering部DevOpsチームに入社したid:itkqです。7月はLayerXエンジニアブログを活発にしよう月間 ということで、この記事では、私が入社してから中心となって進めた、ECSサービスのデプロイの改善について書いています。 バクラクのインフラ 私が所属するバクラク事業部では、バクラク請求書をはじめとする、BtoB向けのSaaSを提供しています。SaaSは主にAWS上でホストしており、サービスの大半がECS Fargateにデプロイされています。昨年、プロダクト開発をイネーブルメントするEnablingチームが発足し*1 、今後の事業成長を支えられるようなソフトウェアアーキテクチャと周辺の仕組みが発達してきています。以下の記事で述べられているように、モノレポかつサービスが多数存在します。 tech.layerx.co.jp DevOp
ブラウザの履歴を操作して「戻る」ボタンで広告を出すやつについて – コーヒーサーバは香炉である
2023年後半頃から、ブラウザの「戻る」ボタンを押すと、訪問したおぼえのないページが表示されることが増えた。そういうページは大抵、記事風の広告やサイト内の記事へのリンクが大量に並ぶという構成になっている。 こんなレイアウトになってることが多い。 この手法はブラウザバック広告とかブラウザバックレコメンド (あるいはレコメンデーション) とか呼ばれており、国内外の複数のWeb広告会社がこれを提供しているようだ。 たとえば、こちらはGMOアドマーケティングの “TAXEL” が提供しているブラウザバックレコメンド。 【新たな収益・回遊源が誕生！】ブラウザバックレコメンド サイトから離れてしまうユーザーに対し、広告やレコメンド記事を表示させることで、収益化や内部回遊に繋げることを目的としているフォーマットになります。 ……というのがセールスポイントらしいのだが、サイトから離れる人は、サイトから離れ
TypeScript 4.9のas const satisfiesが便利。型チェックとwidening防止を同時に行う
TypeScript 4.9 から、satisfies operator が使えるようになりました。従来のas constと組み合わせ、型チェックと widening 防止を同時に行えます。筆者的には、"顧客が本当に必要だったもの"です。 本記事では satisfies とは何か？ as const とは何か？ 2つを組合わせるとどのようなメリットがあるのか？ について、実際のコードと共に解説します。 結論 TypeScriptで 定数を export する場合は、as const satisfies を設定しておくと便利です。 export const myName = "田中" as const satisfies string; export const foodList = { ramen: "ラーメン", udon: "うどん", soba: "そば" } as const sa
ネストオブジェクトの罠 RE: TypeScriptで「選択肢」の定義をEnum的な定数にまとめる
この記事は、静的解析とビルドサイズ面で興味深いテーマでした。記事として自分の考えを書きます。 注意。あくまでビルドパフォーマンス視点での最適化です。強い意図があって、自分のドメインモデリングの方法論ではこれが最適なんだ、というなら元コードの方法論を止めるつもりはありません。 元記事のコードを minify するとどうなるか 元コードを参考に、それにアクセスするサンプルコードを書いてみます。 const sortingOptions = { priceDesc: { id: "priceDesc", sort: "price", order: "desc", label: "価格が高い順", }, priceAsc: { id: "priceAsc", sort: "price", order: "asc", label: "価格が安い順", }, ratingDesc: { id: "ra
GitHub Actions & ecspressoによるデプロイフロー構築 - コネヒト開発者ブログ
こんにちは、リードエンジニアの @dachi_023 です。今回はGitHub Actionsとecspressoでデプロイフローの構築をしたのでそれについて書いていきます。先に言っておくと簡単にセットアップできるし設定もシンプルなのでかなりおすすめです。 Actions | GitHub kayac/ecspresso: ecspresso is a deployment tool for Amazon ECS これまでのデプロイ コネヒトではECS環境へのデプロイに silinternational/ecs-deploy を採用しています。CodeBuildもしくはTravis CI上からecs-deployを利用してECS環境にアプリケーションをデプロイする構成です。 CI/CDツールの乗り換え検討 これまでずっとTravis CIを利用してきました。しかし 料金体系の変更 があった
Must ➡ Can ➡ Will で考えるキャリア
「やりたいことが見つからない」と『Will の呪い』に悩む学生・若手の方はそれなりにいます。そうした人たちに向けた Will, Can, Must の使い方についてのスライドです。 2024年7月6日に実施した
†ダークローンチ† - SmartHR Tech Blog
こんにちは、プログラマのkinoppydです。私の働いているプロダクト基盤チームでは、現在全プロダクト横断従業員検索システムを作成しており、旧システムとのリプレースを行っています。その際に我々が採用した、†ダークローンチ†という手法を皆さんにお伝えしますので、ぜひ参考にしてください。 ダークローンチのイメージ画像です ダークローンチとは？ ダークローンチとは、リリース手法の一つです。すでに稼働しているサービスのトラフィックをコピーして、新たにリリース予定のサービスに対してそのトラフィックを流し、レスポンスを記録しつつ破棄するという形のリリースです。すでに稼働しているサービスから見ると、トラフィックをコピーされる以外は何も変わりません。ダークローンチは、実際のサービスのトラフィックを利用することで、シナリオテストよりも遥かに実態に即したテストが可能であり、かつ既存のユーザーに一切の影響を与え
カヤック発OSSカタログ - KAYAC Engineers' Blog
SREチームの長田です。 今回は、カヤックのメンバーが業務で使うために開発・公開しているOSSなプロダクトをまとめて紹介しようという企画です。 KAYAC organization以下にあるものだけでなく、在籍中のメンバーが作ったものもひっくるめて、実際に業務で使用しているものを中心に 紹介しています。 以下の3つのカテゴリに分けて記載しています。 各カテゴリ内はアルファベット順です。 ツール編 人間が手動で実行するもの アプリケーション編 どこかに常駐して、イベントを受け取ると動作するもの ライブラリ編 ツールやアプリケーションから参照されるもの 集めてみたらそこそこの量になったので、本記事では詳細な説明は省いています。 GitHubリポジトリのURLや関連記事のリンクを併記していますので、より詳しく知りたい場合はそちらを参照ください。 (...) 内はそのプロダクトで使用している主なプ
React Router v6.4はClient Side Remix
React Router v6.4 が、破壊的変更を伴わないマイナーバージョンアップながら、機能追加の内容としてはかなり新しい世界観を追加してきたので、5 分くらい眺めて気づいたことをメモしておきます。 Routing と Data Loading/Mutation の統合 まずはリリースノートがこちら。 そしてリリースノート内に貼り付けられている動画がこちら。 1:45 しかない動画なので、動画を見ていただければこの記事はあんまり読まなくてもいいかもです。 さて、動画内では、次の 2 つの機能を <Route> コンポーネントへと統合した話題が語られています。 データ読み込み（Data Loading） 0:00〜 0:28〜 エラーハンドリングの話題もあり データ更新（Data Mutation） 0:52〜 <Route> に統合された API は、ざっくりと次のような形です。 <R
useOutletContext v6.22.3 | React Router
declare function useOutletContext< Context = unknown >(): Context; Often parent routes manage state or other values you want shared with child routes. You can create your own context provider if you like, but this is such a common situation that it's built-into <Outlet />: function Parent() { const [count, setCount] = React.useState(0); return <Outlet context={[count, setCount]} />; } import { use
React Router v6のOutletとReact.lazyの組み合わせが便利
React Router v6 で登場した <Outlet /> を活用すると、良い感じに共通レイアウトを組み込めて、さらに <React.Suspense> や React.lazy() を組み合わせると体験が良くなるのを見つけました。おそらく React Router v6 を利用する上での頻出イディオムになると思うので、自分用のメモとして残しておきます。 最終的なサンプルコードはこちら。 使用したライブラリは次のとおりです。見た目がしょぼいとテンションが下がるので MUI で装飾していますが、本筋とは関係ないので今回は特に触れません。 react@18.0.0 react-dom@18.0.0 react-router-dom@6.3.0 @mui/material@5.9.3 @mui/icons-material@5.8.4 @emotion/react@11.10.0 @emo
React.ComponentProps 型を積極的に使おう
Atomic Design でいう Atoms に相当する、汎用コンポーネントについての小話です。次の様に Props 型定義を用意し、解説している記事をよく見かけます。<input />タグを使わずコンポーネント化している理由は style を施すためかと思いますが、このコンポーネントが受け取れる Props は限定的で、メンテナンスコストが高いためお勧めできません。 type Props = { value: string; onChange?: React.ChangeEventHandler<HTMLInputElement> onBlur?: React.FocusEventHandler<HTMLInputElement> } export const Input = ({ value, onChange, onBlur }: Props) => ( <input value=
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
外部ファイルをExcelに読み込む際の作業を効率化するPower Queryの活用
明日から始める持続可能なドキュメンテーション戦略 / Sustainable Documentation Strategies: Documentation as a Product
GitHub - goldbergyoni/nodebestpractices: :white_check_mark: The Node.js best practices list (July 2024)
GitHub - getsops/sops: Simple and flexible tool for managing secrets
