React Server Componentsに感じたフロントエンドの消失
はじめに 新年早々に面白そうな記事を見つけました。ReactでのAPI呼出しを最適化するために「部分的にサーバサイドで実行するコンポーネントを作る」というもののようです。 あるいは去年の記事ですが気になってたものとしてBlitz.jsでReactベースのFWであるnext.jsに永続化層を持たせてRailsのようなFWにしようというアプローチもあります。 どちらの記事も書かれてる内容自体は分かる気がするものの 「それをフロントエンドでやる意味あるの？」 というのが拭えずイマイチ腑に落ちなかったんですが、単純に 「私と最前線でやられてる方々で期待してるものがたぶん違う」 という気がしてきたので、その辺を整理のために書いてみます。 注意書き Vue.js/Nuxt.jsは少し触ったことがありますが、React Server ComponentsやBlitz.jsを触ったことは無いです 「なんで
デザイナーとエンジニアを巻き込んだワークフローの改善｜鈴木慎吾 / TSUMIKI INC.
「エンジニアリングに興味があるデザイナー、デザインに興味があるエンジニア Advent Calendar」20日目の記事です。 今年の５月から、社内でクライアントワークのチームから自社事業のチームに異動し、映画・ドラマ・アニメのレビューサービスのFilmarksで有料会員機能のPMを担当しています。 以前はUIデザインやアプリ開発、あるいはその中間的な仕事としてプロトタイプ開発やディレクションなどを経験してきました。 PM業の傍ら、社内のデザイナーとエンジニアの受け渡し部分の改善に取り組みました。その検討過程について紹介します。 要件定義・UIデザイン・開発間のワークフロー改善もともとFilmarks内ではディレクターがGoogleスライドなどで要件資料とGithub Issueをつくり、 デザイナーがSketchでUIをつくりZeplinで書き出したURLをエンジニアに受け渡し、エンジニ
UIデザインをきちんとエンジニアに伝えるための、イケてる設計資料を定義してみた｜ymrl
こんにちは。freeeのUXチームでデザイナーをしている@ymrlです。freeeでは5年半エンジニアをしたあとデザイナーに異動して、もうすぐ2年半になります。UXチームではデザインシステムやアクセシビリティーまわりのことをやりながら、freeeのプロダクトのUIがより良く、より早く作られるためには何をすればいいのかをずっと考えています。 今回は、そんな中で考えた、デザイナーがエンジニアにUIを作ってもらうときに、作ってほしいものがきちんと伝えられるようになる方法を考えた話をします。 「設計資料って何ですか？」freeeのアクセシビリティー・チェック・リストは「対象」を「デザイン」「コード」「プロダクト」の3つに分けていて、それぞれデザイナー・エンジニア・QAがチェックを実施することを想定しています。 このなかで「デザイン」の項目にはいくつか、「設計資料」というのが登場していて、デザイナー
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
