OpenAPI からなるべく生成するフロントエンド開発
こんにちは。 スキーマから何かを生成するのが大好きな seya と申します。 追記 今後は基本お手製スクリプトは書かないで ChatGPT にお願いした方がいいと思います。 ------------- 追記 終わり ------------ 今の会社では REST API のスキーマを OpenAPI で記述しているのですが、それを活用して何かしらを生成するスクリプトをよく書いています。 そんなネタがそれなりに溜まってきたので一挙大放出しようというのがこの記事です。 具体的には次のようなものを作りました。 TypeScript の型と API の生成 by aspida テストのための Factory 関数の生成 msw handlers の生成 API スキーマから生成のデメリット まず初めに、"生成"というのはとても生産的に感じますが、デメリットも存在するので触れておきます。 一番大き
Flutter の描画の仕組みを理解する
私個人の Flutter 歴も早数ヶ月程になってきたのですが、ちょくちょく雰囲気で使っているなーと感じるものが出てきたり(BuildContext や WidgetsBinding など)、描画のタイミングでバグが出た時にフワッとネットで見た記事通りに書いて解決したりなどの場面が出てきました。 それでもとりあえず動くアプリケーション開発はできなくないのですが、ちゃんと自信を持って開発したい & もう一段 Flutter 力を上げたいので本腰入れて Flutter がどう描画しているのかを調べてみたので、その結果をまとめてみました。 同じような課題感を抱いている方の足がかりとなれば幸いです。 はじめに: この記事のスコープ 最初にこの記事で話す「描画の仕組み」とは具体的に何を指すのかを述べます。 前提として、Flutter は大きく次の3つの層から成り立っています。 Flutter arch
エンジニアのための Figma 知識
本記事の多くは Inspect モードを前提に解説しています。 下記に Dev Mode に対応した解説を書いてみたのであわせてご参照ください。 https://codezine.jp/article/detail/18000 エンジニアにデザインツールの知識・習熟は必要か？ しなくても仕事はできると思うのですが、あるとよりクオリティの高い仕事ができることは間違いありません。 という訳でエンジニアがエンジニアとしての仕事をしていく上で「Figma のこういうことを知っておくと良さそう」という知識をまとめてみました。 ユースケースを考える まず始めにデザインは作らないはずのエンジニアが Figma を使う時にどんなユースケースがありそうかを考えてみます。 デザインを元に実装する時 デザインから何かを生成したい時(コードとか画像とか) 自分でちょこっとデザイン修正しちゃう この辺りがあるかな〜
GraphQL クライアント周りで知っておくと良さそうなこと
GraphQL クライアントの選び方について 現状大きく次のような選択肢があります。 Apollo Client Relay Urql 他に react-query や SWR などの GraphQL に特化していないものを使うこともできるらしいがあまりメリットがピンときていない GraphQL クライアントにやってもらいたいこと 上記は Web の GraphQL クライアントの比較しか書いておらず、他のプラットフォーム(Flutter とか)でも選定軸が持てるように、もう少し "GraphQL クライアント" と呼ばれるものに何を期待しているのかを書き出してみる。 graphql リクエストを送れる 最低限の機能です。 エンドポイント、認証トークン は共通のものとして準備して、あとはクエリをのっけたらリクエストが作れたらいいでしょう。 キャッシュを保ってくれる キャッシュの正規化ってな
【フロントエンド初心者向け】ユーザビリティを上げるちょいテク
フロントエンドの開発が初めての人が意外と抜けがちな観点をまとめてみました。 初めにざっくりと概要を話すと「デザイナーが作るデザインでは表現しづらいもの」をまとめたものになります。 デザイナーが作るデザインは静的なものなので(たまにがっつりプロトタイプを作ったりもありますが)、いわゆる"状態"を表現するのが難しかったり抜けたりしがちです。 具体的に言うとローディング、Empty、エラーなどです。これらをよしなに補完できるフロントエンドエンジニアはデザイナーからもきっと「頼りになるぅ！」と思われること間違いないでしょう。 と言うわけでそんな例を紹介していきます。 今後も思いついたら追加する可能性が無きにしも非ず。 ローディングを出そう こう言うクルクルするやつとか こんな感じでシュインシュインするやつがあります。 基本的にユーザがアクションを起こした時に待たせる場合は必ず表示させましょう。 ロ
私が React を好きな理由
何かを好きになるのに、理由なんているかい？ ~セ・ヤ (B.C.2525)~ 出会い あれはおよそ4年前のことでした。 2016年の冬、寒さに震えていた私はフロント未経験の身でありながらフロントの技術選定をしなければならなかったのです。 その頃のフロント界は混迷を極め、 React もまだ枯れておらず、Angular は2系が1系と大きく違うことから叩かれ、Vue が名乗りを上げようとしていました。「フロント界隈は動きが速い」というフレーズも流行語大賞になりそうな勢いでした。 そんな中選択肢・考えることの多さに絶望していた私は React を試しに触ってみました。 そして「思ったより覚えることないし、独自文法とかも少ないからミスってもリカバリー効きそうだな」と直感的に思いました。 はっきり言ってしまえば雰囲気で選んだのですが、今ならこの時の直感は間違っていなかったと自信を持って言えます。
一番文句言われなさそうな React コンポーネントの書き方
最近 React コード生成機を作っていて「一番文句言われなさそうな React コンポーネントの書き方ってなんだ…？」と改めて疑問に思ったので考えてみました。 結論から言うと以下の形をデフォルトにするのが良さそうかなと思いました。 function vs. アロー関数 -> アロー関数 型は基本的に VFC でつけて、 children が欲しい場合は明示的に props に追加する return を省略可能な時省略するか -> しない props を destructure するか -> しない派だったけどした方がいい気がしてきた const Hoge: React.VFC<Props> = ({ title }) => { return ( <Fuga title={title} /> ) } ちなみにですが、大事な前提として TypeScript を使うことを前提としています。(型
TypeScript で type と interface どっち使うのか問題
はじめに あくまで一個人の意見なので絶対的な解ではないというのと、どっちをデフォルトに選んでも普通にアプリケーション開発してて困ることはほぼほぼないと思うので、そこまで気を揉むことでもない、ということだけ最初に述べておいて意見をしたためます。 TL;DR アプリケーション開発では基本的に type でおk Declaration merging したい時だけ interface ライブラリ開発のような使う側で拡張したい(Declaration merging したい)時は interface とりあえずチームでどっちをデフォルトにするかは統一しといた方が気持ちいい type と interface の違い 機能的にはそんなに大きな違いはなく、個人的に判断に関わるのは次の3つかなと思います。 interface では Declaration merging がされる。type ではされない
Node 系ツールのプロジェクト間のバージョン管理に Volta を使い始めてみた
プロジェクト間で必要とされる node.js のバージョンが違うことはままあり、そのために皆さん nvm や nodebrew などのツールを使っておられることだろうと思います。 今回それ系統で Volta というツールを知ったので紹介いたします。 Volta - The Hassle-Free JavaScript Tool Manager Volta の特徴 セットアップが比較的簡単 Rust製で速いらしい 実行する node のバージョンなどをプロジェクトのディレクトリに入るだけで自動で切り替えてくれる npm や yarn でグローバルインストールした時も、どのディレクトリでインストールされたかを自動で記録するため、コマンドラインから直接コマンドを実行できつつもプロジェクト毎に違うバージョンを使うことができる node だけでなく npm や yarn もプロジェクト毎に固定できる
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
