ROUTE06 でソフトウェアエンジニアをしている @MH4GF です。 ROUTE06 ではエンタープライズ向けビジネスプラットフォーム「Plain」を開発しています。この記事では 2023 年 8 月に Plain クラウド EDI の Web フロントエンドで採用している技術について、その選定理由をまとめました。 現代の Web フロントエンド技術は領域ごとに選択肢が多く、プロダクトに最適な技術選定をする上で検討事項が多いと感じます。この記事がフロントエンド技術選定において参考になれば幸いです。 前提 プロダクトの特徴 技術選定に影響するプロダクトの特徴を箇条書きでまとめます。 エンタープライズ向け SaaS 現在開発中のプロダクトは商取引におけるクラウド EDI のドメインにフォーカス Plain が解決する課題は、元々フルスクラッチで開発すると 1 年かかるプロダクトの開発期間を
こんにちは。4月にヘンリーに入社したSWE / アーキテクト / SETのsumirenです。 弊社ではレセコン一体型クラウド電子カルテの Henry を開発・提供しています。 今回、HenryのフロントエンドをReact + ViteからNext.jsに書き換えました。 この記事では、最初にNext.jsへの切り替えによってもたらされたユーザー体験の向上について説明します。次に、このユーザー体験の向上がどうして生じたのか、その背後にある技術的な要素をエンジニア向けに詳細に解説します。最後に、フロントエンドアーキテクチャに対する我々の長期的なビジョンについて述べます。 対象読者 Next.js導入によるユーザー体験向上 デモ 定量的なパフォーマンス比較 ユーザー体験がどう向上したか FCP高速化の技術的な仕組み Next.jsとViteの基本的なアーキテクチャの違い 補足：工夫しているポイ
Webフロントエンド界隈の文献などにあたっていると、「コロケーション (co-location)」という考え方が時々登場します。 コロケーションを簡単に説明すると、関連するリソース同士を近くに置いておく、という考え方です。 FooComponent.tsx と同じディレクトリに FooComponent.test.tsx を置く GraphQL fragment は、クエリを発行するコンポーネントファイル (pages/user.tsx) ではなく、fragment を利用するコンポーネントファイル (components/UserInfo.tsx) の中で定義する pages/user.tsx からはサブコンポーネントのファイルで定義されている fragment を import してきて、クエリを組み立てて発行する API ドキュメントは API.md に書くのではなく、コードの中にド
かれこれ 5 年くらい趣味開発で npm-scripts を書き続けている。長年書き続けているとノウハウが蓄積されてきて、「こう書くとスッキリする」「迷いがなくなる」「後から拡張したくなった時に、簡単に拡張できる」みたいな書き方が身についてきた。自分の型、あるいは手癖のようなものだと思う。 せっかくなので、id:mizdra の今の npm-scripts を書く時の手癖を書き連ねてみる。 基本形 { "scripts": { "build": "webpack --mode production", "dev": "webpack-dev-server --mode development", "lint": "eslint .", "test": "jest" } } 一番シンプルな npm-scripts を書く時のパターン。以下の 4 つの script を登録している。 buil
こんにちは、フロントエンドエキスパートチームの @mugi_unoです！ kintone では フロントエンドの刷新プロジェクト（通称フロリア）が進行中です。 blog.cybozu.io kintone の開発では E2E 主体の自動テストを整備していましたが、 フロントエンドの刷新に合わせて、新たにフロントエンド側でのテストコードを積極的に書いています。 テストを書くことに不慣れなメンバーもいるため、日々 Pull Request 上でのレビューやペア・モブ作業を通じて、知見の共有が行われています。今回はフロントエンド刷新のテストを書いてきた中から、筆者が有用だと感じた知見やノウハウを紹介したいと思います。 目次 💡「実はそれ最初からパスしてるかもしれない」 期待する操作で期待する結果になることを厳密に検証する 他のテストケースによって前提条件を担保する 💡「テストコード上のロジッ
はじめに こんにちは。WEAR部フロントエンドブロックの藤井です。WEARでは現在、Webサイトのリプレイスを進めています。本記事では、リプレイスに至った背景や課題と、課題解決のために行ったリプレイスのアーキテクチャ選定についてご紹介します。 なぜリプレイスするのか WEARはサービスローンチしてから約10年が経ちます。これまでローンチ当時の技術スタックのまま開発を続け、サービスを成長させてきました。今後もより継続的にスピード感を持ってユーザーへ価値を届けていくにあたってさまざまな課題があったため、新たな技術スタックでリプレイスを開始することにしました。 リプレイス前の環境 リプレイス前の環境はオンプレミスの環境にロードバランサー、Windowsサーバー(IIS)があり、そこでVBScriptが動いています。VBScriptでテンプレートHTMLにデータを流し込み、ブラウザに表示する仕組み
Ruby言語によるWebアプリケーションフレームワークの最新版となる「Rails 7」が正式リリースされました。 Rails 7.0 FINAL: The fulfillment of a vision to present a truly full-stack approach to web development that tackles both the front- and back-end challenges with equal vigor. https://t.co/WxJ0nKYfE7 — Ruby on Rails (@rails) December 15, 2021 Rails 7の最大の変更点は、フロントエンド開発環境が刷新されてNode.jsを用いない構成がデフォルトとなったことでしょう。 Rails 6では、優れたフロントエンド開発環境を実現するためにトランスパ
※前編がこちらにあります 目次 icon links inputs keyboard navigation navigation menu modals prefers-reduced-* “skip” links SVGs tabs tables toggle switches tools tooltips video/audio players アクセシブルなインプット 2019年、WebAIMは上位100万件のWebサイトのアクセシビリティを分析し、エラーがないページの推定割合は1%未満というショッキングな結論に到達しました。アシスティブテクノロジー（支援技術）に頼っている人にとってインクルーシブで使いやすいサイトを作成するには、セマンティックHTMLの基礎を正しく理解する必要があります。Oscar Braunertのインクルーシブなインプットに関する記事は、彼の「小さく始めて共有・
クイックサマリー ‐ 私たちは一連の短い記事で開発者とデザイナーにとって有用なツールやテクニックを紹介しており、直近の記事ではCSS監査ツールとCSSジェネレータを取り上げました。この記事ではタブやテーブルからトグルやツールチップまで、信頼性の高いアクセシブルなコンポーネントを見ていきます。 目次 以下にすべてのアクセシブルなコンポーネントをアルファベット順に記載しました。目次をスキップするか、スクロールして1つずつお読みください。 :focus styles autocomplete buttons carousels "close" buttons content sliders checkboxes color systems color palettes comics component libraries cookie consent prompts dark mode data
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 「それってあなたの感想ですよね」 ..... けど、これじゃ勝てないよね、現場はそんな単純じゃないですよね そんなあなたのデザインにひと摘みのエビデンスを添える手法をいくつかお伝えします。 そうです、ユーザーテストです。 .....まだ閉じないで...まだ諦めないでほしい。 いつものじゃなくて定量的に測るユーザーテストです。 タイトルのような主観的な感想を、客観的な数値で倒すことができるのです。 ここではプロダクトのデザイン（見た目やUI設計）をどう定量的にテストしていこうかというお話をします。 はじめに定量的なユーザーテストをすること
おはようございます、なのくろです。年の瀬ですね。 この記事は ABEJA Advent Calendar 2020 の最終日です。 追記：おかげさまで Qiita LGTM賞 を受賞いたしました、ありがとうございます！ 私は2020年01月にABEJAへ入社しました。チームではフロントエンド開発全般を任されています。 参入してちょうど１年が経過しましたので、今年取り組んだことをまとめました。 「フロントエンドを100倍速く」というタイトルは誇張気味なのですが、難しいことはせず、基本的なパフォーマンス改善を素直に実践したという話を書きます。 本稿では事例とやったことを紹介するのみですが、何かしらの知見や改善のきっかけに役立てば幸いです。 サービスについて 話をする前に、どんなサービスを開発しているかについて少しだけ触れます。 ABEJA社では「Insight for Retail」という、小
SPA のフルリニューアルを技術選定や設計からやることになった。 前回の記事も、そのために検討や調査を行っている際に生まれた副産物をまとめたものだ。 目指すべきは変更しやすいシステムであり、そしてそれは、堅牢性を実現することで達成されるはずだという結論に至った。 numb86-tech.hatenablog.com 今回の記事では、堅牢なシステムの実現に向けてどんな技術を選んだのかを記録しておく。 まだ検証フェーズというか、試し書きや検証を行っている段階なので、今後変わる可能性はある。 前提 現行のアプリは Rails アプリで、その上に Vue を載せて SPA を作っている。 フロントエンドのビルドは Webpacker 。別のプロダクトでは Webpacker を剥がしてしまったが、このプロダクトでは実現できていない。 ビュー関連の処理について、どこまでを Rails でやってどこか
Eric Karkovack氏は20年以上の経験を持つWebデザイナーです。"Your Guide to Becoming a Freelance Web Designer"の著者。興味の対象は広範囲にわたります。 良質でレスポンシブなCSSフレームワークを使えば、どんなWebデザインプロジェクトも有利にスタートできます。CSSフレームワークのなかには、Bootstrapのようにコードが多すぎて重いものもあれば、反応が遅いものもあります。 不必要な選択肢に悩まされない、操作に十分な機能だけあるものが理想的でしょう。 よければ、Material Design Web FramewoeksやOpen-Source WordPress Development Frameworkの記事もご覧ください。 ここでは、軽量でベーシックな20のCSSフレームワークをご紹介します。 FICTOAN FICT
毎回関数を作ってpropsに設定する問題の修正 Reactのよくある問題として、propsに関数を渡すパターンで毎回関数を作って渡してしまうが知られています。 毎回新しい関数を作ってしまうと、同じ異なる値（props）となるため無駄にコンポーネントが更新されてしまいます。 why-did-you-updateでもこの問題を検知できます。 この問題は、関数同士の比較は常にtrueとしてしまうshouldComponentUpdateを実装するか、一度作った関数をちゃんと使いまわす（constructorで作成やpublic fieldを使う）ことで解決できます。 また、ESLintやTSLintといったLintツールでも検知できます。 tslint: jsx-no-lambda eslint: jsx-no-bind 参考 React.jsのrenderの戻り値の中で.bindで新しい関数を
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? できあがったクソゲー できあがったブツ(音が出るので注意) https://teradonburi.github.io/santa/index.html 避けゲーです。始める前に事の経緯を読むとクソゲーを倍楽しめると思います。 ちなみに技術的にすごいものはあまりないかもしれません・・・ どちらかというと限られた時間内に自分の持てる能力で実現するにはどうしたらよいかというのを試行錯誤したことを書きました。 タイトル画面はそれっぽい感じにしました・・・ 事の経緯 JSフレームワーク(またはライブラリ)× ビアバッシュ 初心者勉強会にて最速で
フロントエンドエンジニアの @vwxyutarooo (Yutaro) です。11月の7-8日に San Francisco にて行われた GrahpQL Summit 2018 に参加してきましたのでその様子をお伝えします。 フロントエンドからは私とチームメイトの @carlos の2名、バックエンドからも3名参加しました。 現在のメルカリ Web では GraphQL は使われていませんが、アーキテクチャを刷新する Re-Architecture というプロジェクトにおいて GraphQL を使用しています。 トークの内容は YouTube にて公開される予定ですので、全体の雰囲気と私が気になったトークをいくつか紹介します。 GraphQL Summit とは GraphQL Summit 2018 GraphQL Summit は2016年から始まり今年で3年目となります。Graph
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く