- はじめに - 9月くらいから趣味でフロントエンド周りをやっていたので、その勉強過程のまとめ。 何が良かった悪かったとか、こうすればよかったとか、所感とか。 - はじめに - - 前提 - - どんな感じで進めたか - 最初の開発 TypeScriptとNext.jsを使った開発 アプリ手伝いから自分のアプリ開発まで - できてないこと - - 所感 - - おわりに - - 追記 - - 前提 - 前提として9月頭くらいの私のフロントエンドに対する理解と技術的な知識はこんな感じ。 5年程前まではjQueryで謎のWebサービスや動きモリモリのプロフィールページを作ったりDjangoで研究室のWebサイトを作ったりしてた Railsチュートリアルはやったことある 仕事では普段機械学習モデル作ってるが、機械学習のデータやモデルの変更が及ぶ場合に既存のPHP、Railsアプリの改修をしたり、
Yahoo! JAPAN トップページを Atomic Design と React・Redux・TypeScript で作り変えたお話
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちはお久しぶりです。岡部和昌（@kzms2）と申します。 今回お話しする内容はタイトルでほぼ全部述べているのですが、PC 版 Yahoo! JAPAN のトップページを 2019 年 10 月 1 日に刷新、主に開発環境をアップデートした経緯と採用した技術に関してのお話です。 見た目に関しては特に大きな変化はなかったので、気が付かなかった方も多いのではないでしょうか？ なぜ刷新したか Yahoo! JAPAN トップページは 2008 年 1 月 1 日に大規模なリニューアルを行いました。その頃からある程度の改修はあったものの、基本的にはコードの継ぎ足しで修正を加えている状態でした。 （参照；Yahoo! JAPAN トップ
Atomic Designをやめてディレクトリ構造を見直した話｜食べログ フロントエンドエンジニアブログ
こんにちは。フロントエンドチームの金野と申します。 食べログでは現在、React+TypeScriptでフロントエンドのリプレースを進めています。 以前の記事で、食べログではAtomic Designをどのように取り入れているかの紹介をしました。 しかし、最近のリプレース作業では、Atomic Designとは異なるディレクトリ構造を採用しています。 今回の記事では、「なぜAtomic Designをやめたのか」という理由と、「どのようなディレクトリ構造にしたのか」を紹介します。 Atomic Designを導入したねらいと導入した結果 上記の記事で言及した通り、当初Atomic Designを導入したねらいは以下になります。 1. コンポーネントの責務がより明確になる 2. 見た目の粒度だけでなく、ロジックの責務も明確にできる 3. 「ドメインが入るか／入らないか」。「抽象的か／そうでな
Vue.js × Atomic Design - コンポーネント分割の指針 / Vue.js and Atomic Design - Guideline for components division
Vue.js 講演用資料です。 # 概要 コンポーネントをどのような粒度で分割し、どのように実装するべきかというのは難しいテーマです。 一概に正解があるとも言い切れないテーマですが、この指針を疎かにすることはチームを混乱に陥れることと同義です。 それが SPA 未経験のチームであればなおさらです。 直近のプロジェクトはまさにそんなプロジェクトでした。 本セッションではアトミックデザインのエッセンスを用いてコンポーネント分割の指針を示し、 またコンポーネント実装時に注意すべき事柄についてお話します # URL HomePage: https://nrslib.com Twitter: https://twitter.com/nrslib
近日連投していた Next.js 記事のサンプルコードを公開しました。このサンプルコードを元に、私のフロントエンドディレクトリ構成・テスト観点を紹介します（あくまで執筆現在の脳内アウトプットになりますのでご了承ください） フロントエンドディレクトリ構成の事情 タイトルの「フロントエンドディレクトリ構成」をさす「Components」のディレクトリ構成は、いつも悩みのタネです。このモジュールシステムは「デザインシステム観点・アクセシビリティ観点・フロントエンド実装観点」の 3 つの観点が混在するため事情が複雑です。どうせ作るのなら「デザイナー・フロントエンド」どちらの開発基盤にもなりえる、盤石なモジュールシステムを目指したいですよね。 "AtomicDesign やめました"という声をたまに聞くのですが「デザインシステム的に捨てていいの？」と思うこともあるので、とくに要望がなければ、筆者は「
はじめに HTML＋CSSコーディングにおいて、「どのように要素を特定してスタイリングするのか」というCSS設計上の課題に対し、「ひとつ上の視点で思考できる概念図」を紹介します。 この図を用いることで、3種類の異なるスタイリングアプローチ（OOCSS方式 / 包括要素基点方式 / BEM方式）の本質を一度に俯瞰できるため、全てを同じ枠の中で捉えられます。そして、最終的には種別や規模の異なるサイトやプロジェクトに対し、同じメソッドを使ってそれぞれ最適な設計がおこなえるようになります。 ※この記事は標準化ノウハウ公開の一環として書いています。 仕組みの概要や前提事項などについては「UltimateCoding 概要・前提事項」のエントリをご確認ください。 経緯 / 制作者中心のデータ分類 そもそもですが、HTMLとCSSは目的も仕様も異なる言語です。 HTML+CSSコーディングを一般的な視点
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=
【Atomic Designに懐疑的なあなたへ】改めて考えたい React / Next.js のデザインパターン
フロントエンド開発は一般的に複雑性との戦いです。放ったらかしにしておくとますます複雑になり、変更するのが難しくなります。これまでにも、このような複雑さをどうにかして制御しようとして、Atomic Designをはじめとした様々な設計手法（デザインパターン）が考えられてきました。 しかし、React / Next.js を使ってチーム開発を行う際に、現状のデザインパターンでの運用では「どうもうまくいかないな」と思う場面に多々遭遇しました。そのような経験を踏まえて、「コンポーネントをどのように設計するか」「どのようにディレクトリを分けるか」を徹底的に考え、新しいデザインパターン「Tree Design」にまとめました。 Tree Design はまだまだ仮説段階です。今後弊社チームで運用していく中でブラッシュアップする予定です。しかし、他のフロントエンド開発チームがデザインパターンを再考する際
前書き フロントエンドエンジニアの松原(@simezi9)です。 先日10月30日にクラウドワークスさんをお借りして実施したVue.jsの設計勉強会である、Vue.jsアーキテクチャリング勉強会 にて、 BASEの現在のVueコンポーネントの設計に関して登壇してお話してきました。 全体の資料はこちらです もともとBASEではVue.js+TSを採用した大規模なシステムのリニューアルプロジェクトが2018年からスタートしていました。それにあたっての大まかなフロントエンドの構築方針は以前もblogや外部登壇で発表していました。 次世代の管理画面を作るフロントエンドの取り組み - BASE開発チームブログ 次の5年を支えるVue.js製UIコンポーネントライブラリを育てる これまでの発表では大枠の技術スタックやワークフローの話が多かったですが、 今回はVueコンポーネントの設計が勉強会の主眼にあ
脱・Atomic Design - HTML+CSSコーディングの粒度分類法（HTML Parts） - Qiita
はじめに HTML+CSSコーディング専用の粒度分類を紹介します。 この仕組みは、デザインやワイヤーフレームなどの視覚情報を分解することに焦点をあて、分解した対象を部品化する流れも併せてガイド化した汎用手法です。 世の中には、コーポレートサイト / ポータルサイト / サービスサイト / システム管理画面 / ブログサイト… といった様々な種別のサイト、Webページがありますが、これらの「完成予想図（視覚情報）」を同じ方法で分解して、コーディング用の部品にできます。 粒度と言えばAtomic Designが有名ですが、この「HTML Parts」も粒度そのものの考え方についてはAtomic Designの踏襲です。その上で「思考の入り方・捉え方」や「名称と定義」をコーディング側に寄せることで、CSS設計やコーディング業務を標準化しやすくしています。 ※この記事は標準化ノウハウ公開の一環とし
と言えば、zennで一番人気のあるの記事です。 Reactの堅牢な開発基盤を築きたいときに非常に参考になります。 @Meijin_gardenさんのこの記事が出たのは、ほぼ一年前。 今日までの間に、React v18.0のリリースというビッグなニュースもありました。 なので、2022年秋となると、一年前とは少し様子も変わってくるかもしれません。 「概ね賛成だけど、ここはこうしてみたい気もする」という部分もあります。 そんなわけで今回は、2022年秋バージョンのbulletproof-reactを一緒に考えていきたいです。 Reactベストプラクティスの宝庫！「bulletproof-react」が勉強になりすぎる件の内容を前提に書いていきますので、まだ読まれていない方は、先に本家の記事を読まれると良さそうです。 改めて考えるbulletproof-reactの良さ ディレクトリ構成 Rou
Atomic Design は難しい Webフロントエンド開発をしている人で Atomic Design を用いた経験がある方に会った時は、必ず 『Atomic Designどうですか？』と聞くようにしています。 大体の方はちょっと苦笑いをしながら『やっぱり難しいですねぇ』とか『試行錯誤しながらで...』みたいなことを教えてくれます。 私もメインの開発をする際に Atomic Design という枠組みを用いています。そして、同様に色々と悩んだのですが、このあたりについて納得がいく解釈ができたと思っています。 そこで、私の思う Atomic Design の難しさや、そう思う原因、どうやってそれを解消するかという点について、https://atomicdesign.bradfrost.com/ を適宜参照しながら共有したいなと思います。 そもそも Atomic Design 何やねん。な方
自社サービス『ツクリンク』はリリースから7年が経ちました。 直近でAtomic Designをベースにしたデザインシステムの作成と、CSS設計の変更をしたので紹介します📛 CSSの変遷現在の設計の話をする前にこれまでのCSSを紹介。 Ver１ 初回リリース時 昔懐かしいCSSです。Sassも使わずベタ書き。 #main .articles p { } #main .articles .header { }実は今でも一部で生きています。反省してます。探さないでください。 Ver２ リニューアル リニューアルをしたタイミングでCSS設計にはMindBEMdingを採用、SCSSを使い格段に書きやすくなりました。ファイルはBlockごとに分け、クラスの衝突を防いでいました。 # _block.scss .block { &__element { &--modifier {} } } # ディレ
こんにちは、クレイの阪本です。 もともと外部委託パートナーとしてクレイ案件のお手伝いをしていましたが、気づけば中の人となっていました。 よろしくお願いいたします。 先日、DocBaseはフロントエンド構成を Backbone.js+Coffeescript から React.js+TypeScript へ移行しました。大改修です。 どれくらい大きな変更だったかというと、10万行(2500ファイル)もの変更が行われ、それまでRubyだったはずのリポジトリ代表言語がTypeScriptに替わってしまったほどでした。 なお、2021/3/31のリリースでリニューアルすべてが終了したわけではありません。今後、機能拡張やUI改善をしやすくするための足がかりという位置づけです。 安全にリリースするためテスト期間を多めに取ったこともあり、期間としては1年ほどかかってしまいました。 今回はどのようにリニュ
こんにちは、GaudiyデザイナーのTORAJIRO（@jirosh1998）です。 『英単語アプリ mikan』の副業デザイナーとして、Figmaリファクタリング&デザインシステムの一歩目を構築した話を書こうと思います。 このnoteの最後に、今回作成した『mikan DesignSystem』のデータを公開していますので、ぜひご覧ください👋（mizoさんをはじめmikanのみなさん、具体的なアウトプットの公開まで許可いただき感謝です！心広すぎ！） 読んで欲しい人 - これからチームでデザインシステムを作っていきたい - コンポーネントライブラリをFigmaで構築したい - Figmaをリファクタリングして、デザイナーの作業効率を上げたい デザインシステム本題に入る前に、このnoteで書いている「デザインシステム」の定義について触れておきます。デザインシステムとは「良いデザインを『効率
Atomic DesignをVue.jsで実現するための構成と考え方 | Biscuetでの例をもとに - SMARTCAMP Engineer Blog
スマートキャンプのデザイナー/エンジニアのhaguriです。 弊社では8月1日、インサイドセールスに特化したCRM Biscuet（ビスケット） という新サービスをリリースしました。 biscuet.jp Biscuetでは Vue.js + Atomic Design でコンポーネント設計をしています。今回はその構成と考え方・Biscuetチームでの運用について紹介していきます。 Atomic Design について templatesとpagesについて Biscuetでのルール atoms molecules organisms pages ディレクトリ構成 App.vue components/ plugins/biscuet-materials/ さいごに Atomic Design について Atomic Design とは、コンポーネント単位で設計していくデザイン・開発手法で
レガシーなフロントエンド環境をリプレースするためにチームでやっていること｜食べログ フロントエンドエンジニアブログ
はじめに はじめまして！食べログFE（フロントエンド）チームの金野と申します。 普段は、食べログフロントエンドの設計・開発や、新規事業・食べログテイクアウトの技術サポートなどを行っています。 食べログテイクアウトについては、Nuxt.js + TypeScriptの開発について記事を書いているので、興味がある方はぜひ御覧ください。 さて、以前の記事でご紹介したように、食べログFEチームではレガシーシステムのリプレースをReact/TypeScriptで行っています。 今回は、新しいシステムについてもう少し詳しい技術スタックや、どのようなプロセスで開発しているのかを紹介します。 開発効率化のための取り組みリプレースのお仕事はただひたすら実装するだけではありません。 「壊れにくいアプリケーション」「メンテナビリティが高いアプリケーション」にするために、アーキテクチャや採用する周辺技術について、
Atomic Design思考でVue.js×Plotly.jsでのグラフComponentを実装した結果 - ABEJA Tech Blog
第0章：はじめに こんにちは。はじめまして。 ABEJAでフロントエンドとバックエンドをフラフラしているエンジニアの齋藤(@z-me)*1です。 本ブログは ABEJA Advent Calendar 2019 の9日目です。 不本意ながらABEJAで開催するフロントエンドのミートアップやカジュアル面談でよく、 ABEJAってAIの会社ってイメージはあるけどUI/UXガッチリやってるイメージがない。 と言われる事が多いので、当ブログ編集長*2が言っている通り*3、ABEJAではプロダクトを開発＆提供しているということをお伝えしたいと思います。 今回はその中でも、あまり外部に広く知られていない、ABEJA Insight for Retailの提供しているDashboardで、どのようにUI/UXに力を入れて開発しているのかや、その開発手法(Atomic Design)やグラフCompone
脱・Atomic Design - HTML+CSSコーディングの粒度分類法（HTML Parts） - Qiita
はじめに HTML+CSSコーディング専用の粒度分類を紹介します。 この仕組みは、デザインやワイヤーフレームなどの視覚情報を分解することに焦点をあて、分解した対象を部品化する流れも併せてガイド化した汎用手法です。 世の中には、コーポレートサイト / ポータルサイト / サービスサイト / システム管理画面 / ブログサイト… といった様々な種別のサイト、Webページがありますが、これらの「完成予想図（視覚情報）」を同じ方法で分解して、コーディング用の部品にできます。 粒度と言えばAtomic Designが有名ですが、この「HTML Parts」も粒度そのものの考え方についてはAtomic Designの踏襲です。その上で「思考の入り方・捉え方」や「名称と定義」をコーディング側に寄せることで、CSS設計やコーディング業務を標準化しやすくしています。 ※この記事は標準化ノウハウ公開の一環とし
記事の概要と動機 Takepepeさんの「AtomicDesign 境界線のひき方」という記事を読んでいて、はたと気づいた。「限定的コンポーネントを横断的なものに移行する」という箇所は、SOLID原則のISPとそのリファクタリングの話だ。ISP（Interface Segregation Principle）とはインターフェース分離原則である。 コンポーネントは、はじめは限定的コンテキストで実装するべきでしょう。共通利用される頃合いに、リファクタリングすれば十分です。その際に忘れてはならないことが「抽象化」です。 この記事は、Takepepeさんの記事中の以下の一文に対して、インターフェースという観点から解説を加えた返歌、つまりアンサーソングである。 コンポーネントのインターフェース フロントエンドのコンポーネントのインターフェースとは、単純化するとPropsの型である。 type Art
モバイルアプリ開発において宣言的UIフレームワークを利用する際のコンポーネント粒度についての考察 - クックパッド開発者ブログ
こんにちは、クックパッド事業本部 買物サービス開発部の佐藤（@n_atmark）です。 私の所属する買物サービス開発部ではクックパッドアプリにおける買い物機能*1の開発を行なっており、私は2020年の上期から買い物機能のモバイルアプリ開発の担当をしています。 2020年上期〜2021年上期では、クックパッドiOSアプリの買い物機能開発に、 2021年下期からは、クックパッドAndroidアプリの買い物機能開発に携わっています。 クックパッドアプリの買い物機能開発に関する詳細はクックパッド開発者ブログにもまとまっていますので、ぜひ合わせてご覧ください。 techlife.cookpad.com techlife.cookpad.com 前述の通りクックパッドアプリにおける買い物機能をiOS/Android両プラットフォーム向けに開発しているのですが、実はそれらの開発には共通している点がありま
開発部で週1で新しいことをやってみる『Dev実験室』の取り組み AtomicDesignを知る デザインシステムを知る CSS設計どうするのが良い？ って話をする
はじめに こんにちは、Blabo!でモバイルエンジニアをしている@youmeeeです。 今回は、弊社の共創プラットフォームサービスである「Blabo!」のiOS/AndroidアプリをFlutterにてリプレースしたので技術的な話や、リプレースを通じての所感などを書き記していこうと思います。 Blabo!のFlutterリプレース版は各OSこちらからインストールできます。 iOS版： https://apps.apple.com/jp/app/1174269704 Android版： https://play.google.com/store/apps/details?id=bo.bla.app&hl=ja Flutterとは FlutterとはGoogleが提供するクロスプラットフォームSDKです。 2018年にStableリリースが発表され、最近サービスでの導入事例もじわじわと増えてき
プロダクトのパフォーマンスを改善するためにVue.jsの関数型コンポーネントやpropsに関する施策を行った話 - SMARTCAMP Engineer Blog
こんにちは！フリーランスエンジニアとしてスマートキャンプに参画している芳岡です。 弊社のプロダクトであるBiscuet(https://biscuet.jp/)の開発に初期から参画していますが、サービスが世の中に展開されていく過程、チームが大きくなっていく過程を間近で見れとても興味深く思っています。 今回は、そのBiscuetで使用しているVue.jsのパフォーマンス改善を行ったのですが、そこで気づいたいくつかのポイントを整理してお届けします。 Vue.jsのパフォーマンス 関数型コンポーネント propsは、オブジェクト全体か各プロパティごとか？ プロパティごとに渡す方法 オブジェクトを渡す方法 注釈 最後に Vue.jsのパフォーマンス Vue.jsでは、状態変更によって、仮想DOMが繰り返し再計算（updateRender)されるため、それによりパフォーマンスが悪くなることがあります
READYFORは、日本最大級のクラウドファンディングサービスです。今回は、「実践！フロントエンド分離戦略」をテーマに、Ruby on Rails で稼働しているサービスを Next.js を利用して分離する取り組みについて発表しました。フロントエンドエンジニアの江面陽一氏からは、UIリニューアルがよい方向に進んだときのエピソードについて。 スピード重視の立ち上げ期あるある負のループ 江面陽一氏：では、私から「”READYFORフロントエンド” の黎明」というところで、分離に向かっていいサイクルに傾き始めたときのきっかけをお話ししたいと思います。よろしくお願いします。 まず簡単に自己紹介させてください。江面陽一と申します。SIerからWebをやりたいなと思って転向しまして、READYFORに2018年の11月に入社をしています。私生活では、バンド活動をしていたり、猫を飼っていたりしています
React.memoを適用すれば、コンポーネントの不要な ReRender を防ぐことができます。しかしながら、Provider 設計・バケツリレーの見直しを行うことで、React.memoを使わずとも、ReRender の抑止は可能です。 最適な Context Provider 設計とすることで、React.memo使用によるオーバーヘッド削減が期待できます。そして「過剰な Provider 分割も場合によっては不要」ということを解説していきます。 3つのパターン サンプルリポジトリを用意しました。（Next.jsで作っていますが、特に意味はありません）「+1」押下でカウントアップし「input text」入力で、入力内容が更新される簡単なサンプルです。 こちらでは、以下３つのパターンが用意されています。ReRender されている様子は console.log 出力のほか、React
AtomicDesign 境界線のひき方
AtomicDesign はコンポーネント粒度の指標として共有し易く、多くのプロジェクトで採用されています。しかしながら、その設計概念が先立ってしまい、いくらかの課題を抱えている場合があります。 1.影響範囲が特定しにくい 2.依存関係が特定しにくい 3.汎用性が低くなりがち 4.汎用性の高低が判別できない 多くの場合「粒度」だけを基準にしてしまい、横断的コンテキストに「早期区分」 してしまっていることが直接的原因です。 「関心範囲の広さ」区分 アプリケーションを構成するモジュールは「関心範囲の広さ」で区分を行うことが鉄則です。次の２つのhelper.tsを見てください。全く同じ関数が定義されていたとしても、どこで利用される想定のものなのか、すぐに判別できますね。utilsは、プロジェクト内で横断的に再利用される可能性が高い（関心範囲が広い）ものが集約されます。 AtomicDesign
🙋♂️エンジニアの@dachi_023です。約4ヶ月ぶりに記事を書きます、がんばります。 この記事について コンポーネントやAtomic Designについて書いています。ここではUIデザインのフローに関するAtomic Designの実践ではなく、開発(実装)のフローにはめ込んだ場合にどうすべきなのか、というお話をしています。 コンポーネントとAtomic Design ReactやVueをはじめとするライブラリのお陰でフロントエンド開発に「コンポーネント」という考え方が浸透した今日この頃ですが、そんなコンポーネントの設計についての話なんかをしているとよく現れるのが今回の主題に挙げている「Atomic Design」です。Atomic Designはデザインシステムを効率よく作成するための手段のひとつですが、その中に登場するコンポーネントを5階層(Atoms, Molecules,
コンポーネントの設計方法って 「大体の場合はこのやり方で設計したら勝手に良い感じになるから！」 みたいなベストプラクティスは無いのか気になった(楽して設計したい)。 私は React をメインで使用していますが、コンポーネント設計の話なので Vue メインの方でも読んでいただけると思います。 サンプルや参考記事は React ベース・Vue ベースどちらも出てきます。 また、この記事ではコンポーネントの分割方法のみに注目しており、コンポーネントのスタイルや状態保持の設計については基本的に言及しません。 それらの内容についてはこちらの記事が大変参考になりますのでオススメです。 ベストプラクティス 結論としてはベストプラクティスのようなものは見つかりませんでした。 結局は良い設計は作るものによる、というのが答えになってしまいそうです。 しかしヒントになる情報や勉強になる事例も見つけたので記事に
こんにちは！Magic Momentのフロントエンドエンジニアの石田です！ Magic MomentのフロントエンドではReactを採用しており、 コンポーネント設計にはAtomicDesignを採用しています。 みなさんはコンポーネントを使い回せていますか？ 今回は僕がMagic Momentで実施しているコンポーネントを使い回すための開発手法をご紹介します。 コンポーネント駆動開発 コンポーネント駆動開発とは、画面を作る際に小さなコンポーネントから作成していき、小さなコンポーネントを組み合わせて画面を作る「ボトムアップ」の開発プロセスになります。 この手法を使用すると、小さなコンポーネントとして再利用できる部品を設計できます。そのため、コードの重複を減らし、保守性を向上させることができます。また、コンポーネントを組み合わせて画面を作成するため、開発の効率性も向上します。 Magic M
atoms を atoms であり続けさせるための工夫は以前記事に書いたので参考にしてみてください。 AtomicDesign の atom より小さな世界の扉を開く 軸の転換 粒度軸重視から概念軸重視へ 以下は簡単なブログサービスで作成するであろうコンポーネントを5つの方法で分類した例です。 粒度軸で分類しても、概念軸の分類をしないとキレイな構造にはならない 概念軸で分類すると、粒度軸で分類しなくてもかなりキレイな構造になる 概念軸と粒度軸で分類すると、非常にバランスの取れた構造になる 概念軸と関心で分類すると、スケールに強くなる 5 概念軸と関心と粒度軸で分類すると、スケールに強く、関心をまとめつつ粒度の恩恵も得られる 5 なぜ粒度軸より概念軸なのか 粒度軸の中で概念軸の分類を行う 概念軸の中で粒度軸の分類を行う この2つの一番大きな違いは、関心のまとまりです。 DDD の基本でもある
受注管理機能を支える技術 〜 VueCompositionAPIとGraphQLとAtomicDesignとScopedStyle〜 - 弥生開発者ブログ
こんにちは、 @mugi_uno です。 少し前に背骨の手術を受けたら身長が伸びました。 🎉 受注管理機能をリリースしました 2020/12/10に、Misocaに新しく「受注管理機能」をリリースしました。 www.misoca.jp いままでは、請求書・見積書・納品書といった単位でのステータス管理が主でしたが、新たに追加された受注管理機能を使うことで、案件単位でステータスを管理しつつ、各文書への変換も簡単に行えるようになりました。 そして、同時にこの受注管理機能は、開発面においても様々な新しい技術面でのトライもありました。 Vue.js & Vue Composition API GraphQL Apollo Client & Vue Apollo Atomic Design Scoped Style 今回は、これらについてどういった対応をしたのかと、リリース後にふりかえってみてそれぞ
FlutterアプリにおけるUI Component Architecture #LayerXテックアドカレ - LayerX エンジニアブログ
こんにちは。バクラク申請・経費精算 ネイティブアプリエンジニアのyoheiです。 最近はこたけ正義感の逆転裁判プレイ動画を見ながら法律の勉強してます。好きなラジオは真空ジェシカのラジオ父ちゃんです。M-1も応援してます！ この記事はLayerXテックアドカレ2023の26日目の記事です。前回は 赤羽さん が「Go言語のORMであるGORMをv1からv2へのマイグレーションした話」を書いてくれました。27日目の記事 id:itkq さんより「勤怠をいい感じにする社内Slackアプリ #LayerXテックアドカレ - LayerX エンジニアブログ」ポストされました。一緒にご覧いただけたらと！ バクラク申請・経費申請では現在のモバイルアプリをFlutterでのリプレースを進めています。そのうえでチームとしてUIコンポーネント(Widget)をどの用に作っていくか設計(UI Component
Component Driven User InterfacesThe development and design practice of building user interfaces with modular components. UIs are built from the “bottom up” starting with basic components then progressively combined to assemble screens. Modern user interfaces are more complicated than ever. People expect compelling, personalized experiences delivered across devices. That means frontend developers a
こんにちは、CTOの鈴木です！前回のブログ執筆から気がつけばなんと2年経過！今回はスペースマーケットのメインであるWebサービスとアプリ部分の技術スタックについてまとめてみようと思います。 技術スタックについては定期的にまとめており、変遷については以下の記事に書いています。 2016年 スペースマーケットを支える開発環境とアーキテクチャ – 2016年秋編 2017年 スペースマーケットの技術スタック【2017年末版】 前回2017年からの差分としてわかりやすいように、新規追加は太字、撤退したものに関しては取り消し線をつけてみてます。それでは見ていきましょうー。 Web Frontend 言語 Javascript Typescript GraphQL 言語としては、Universal Javascriptを引き続き推奨し、プロダクト施策などに絡めてTypeScriptへの移行を進めていま
READYFOR主催のフロントエンド勉強会【実践！フロントエンド分離戦略】を開催しました！ - READYFOR Tech Blog
2021年2月5日に、READYFOR主催としては初となるオンライン技術勉強会、【実践！フロントエンド分離戦略】を開催しました！本記事では、当日の様子と各セッションの内容を振り返ってみたいと思います。 readyfor.connpass.com 当日は実に最大240人を超える視聴者が参加してくださり、Twitterでもご好評の声をいただきました。当日の様子はこちらのTogetterでも空気感が感じられると思うので、ぜひご覧になってみてください。 togetter.com 1. READYFORのフロントエンドを2019年末から全体像を構想してどうしていくか検討した話 まずはフロントエンドチームのエンジニアリングマネージャー岡村（@resqwork）による、「READYFORのフロントエンドを2019年末から全体像を構想してどうしていくか検討した話」です。 2019年8月に岡村がジョイン
学生エンジニアのためのチャットサービスをNext.js + TypeScript + AtomicDesign + Firebase9 + Dockerで作った（β） - Qiita
学生エンジニアのためのチャットサービスをNext.js + TypeScript + AtomicDesign + Firebase9 + Dockerで作った（β）DockerFirebaseOSSNext.jsAtomicDesign はじめに ※今回の開発は、株式会社OwN様からいただいた技術課題の一環で行ったものになります。 自己紹介 会社員やりつつ、趣味で個人開発を行っております。 フロントエンジニアのふぁると申します。 【Twitterリンク】 itamaster サービスについて サービス名 hacker-class-roomを略して、「はかくら」です！ リポジトリURL こちらになります。 https://github.com/FAL-coffee/hacker-class-room サービスの概要 「プログラミングの授業が始まるが、ついていけるのか不安......」 「情
ぼくのかんがえたフロントエンドアーキテクチャ
はじめに 普段開発しているフロントエンドのアーキテクチャがそこそこ良くできていると得意顔になれる気がしたので、思想を書いてみようと思います ※ その他、プロジェクトの構成については Yota Hada さんの記事をご参照ください 記事のターゲット フロントエンドのアーキテクチャ構成に悩んでいる人 ちょっとイケイケ・ゴリゴリのディレクトリ構成で開発をしてみたい人 バックエンドからフロントエンドに転向してチーム立ち上げをするので困った人（私） 個人的な雑記を含んでいますので、読みにくさはあしからず… 構築背景 バックエンドで何度かプロジェクトの生き死にを経験したエンジニアがフロントエンドチームを立ち上げてイチから構成を考えることになった バックエンドで馴染みのあったクリーンアーキテクチャの構成をWebアプリケーションのフロントサイドで実現しつつ、コンポーネント開発にAtomicDesignを取
記事のターゲット 基本的に私です Storybookを触ってみたは良いけど公式アドオンの選定に迷っている人 公式アドオン各々の利点がわかっていない人 フロントエンド初心者だけどStorybook知ってそうな雰囲気出してドヤりたい人 Storybook とは UIコンポーネントを分離して開発するためのオープンソースツールで、Web上のサンドボックス環境を提供してくれます。 ローカルホストで立ち上げ、ブラウザ上で細かな動作確認を行えるので細かいコンポーネント単位で開発がしやすくなります。 また、サンドボックスではUIコンポーネントのカタログを検索・閲覧する機能を提供することでUIの再利用性を高めることができます。 ビジネスロジックに寄らないコンポーネント実装やMockingもお手軽なのでAtomicDesignベースの開発では必需品かもしれません。 ただし、サンドボックス環境も開発者の手でコン
はじめに Reactを触って早くも2年が経ちました。エンジニア歴も2年が経ってしまいました。 時が経つのは本当に早いですね。 最近は人に教えたり、新規プロジェクトの立ち上げメンバーとして任される機会が増えてきました。 そういう中で、自分でベストプラクティスを考えて、コードや設計に落とし込む必要があるとひしひし感じる今日この頃です。 これまで二年間色々なコードを見たり書いたりして、最近やっと自分の中で少しずつベストプラクティスが見えてきた気がするので、色々な記事の力を借りつつ言語化してみようと思います。 書く内容は自分がReactの案件にアサインされた時に知りたかった内容を意識しています。 主に考え方の話になるので、具体的なコードは書きません。 自由に書いている為、各レイヤーもずれていますので（前半は原則の話、後半はメモ化の話）、その辺りはご了承ください。 意識するべき原則の話 良いコードや
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
3ヶ月くらいフロントエンドやったのでやったこと一旦まとめ - Stimulator
私のフロントエンドディレクトリ構成・テスト観点 2022
1段上のCSS設計・コーディングの概念図（HCDCモデル図） - Qiita
React.ComponentProps 型を積極的に使おう
BASEのVue.jsコンポーネントの設計について登壇してきました - BASEプロダクトチームブログ
本気で考えるReactのベストプラクティス！bulletproof-react2022
Atomic Design はなぜ難しいか？どうやって難しさを解消するか
Atomic DesignをベースにしたデザインシステムとCSS設計｜あっきー
DocBaseのフロントエンド改修をどのように進めたか
Figmaのリファクタリングからはじめるデザインシステムの構築｜TORAJIRO
Reactコンポーネントの抽象化とインターフェースのリファクタリング
AtomicDesignとデザインシステム、CSS設計について
共創プラットフォームアプリ「Blabo!」をFlutterでフルリプレースしました - Qiita
「TypeScript」を使わない手はない READYFORのUIリニューアルを支えたフロントエンドの技術
React.memo を濫用していませんか？ 更新頻度で見直す Provider 設計
Atomic Designを実践して得た学びと失敗 - コネヒト開発者ブログ
フロントのコンポーネント設計ベストプラクティスを探してみた話
AtomicDesignを活用する「コンポーネント駆動開発」のススメ
BCD Design によるコンポーネントの分類 - Qiita
Component Driven User Interfaces
スペースマーケットの技術スタック【2019年末版】 | スペースマーケットブログ
Storybook公式アドオンをまとめてみた - Qiita
Reactのベストプラクティスを模索する - Qiita