フロントエンド開発の準備
開発の前に決めておくこと 後から変更するのが難しいこと、大きな手戻りが発生する可能性のあることをできる限り開発のはじめに決めておきます。 多言語対応の有無 URLに依存する可能性が高い多言語対応は、後から対応すると制限がかかったり破壊的な変更が必要になる場合があるので、はじめに決めておきます。 多言語対応する予定はなかったけど、後から必要になってしまった場合は仕方ないと思います。 OGPの必要性 動的ルーティングに対するOGPの必要性によってレンダリング方法の選定やCDN周りの選定が変わってきます。 SEOのニーズ こちらもOGP同様レンダリング方法に影響します。 OGPに関しては後からなんとかなることもありますが、SEOが重要なサイトの場合、そもそもSPAを選択しない方が適している可能性もあるので重要です。 対応ブラウザ/バージョン これを明確にしないと、一部のブラウザで使用できないCS
ゆめみのフロントエンドコーディング試験の題材で React の勉強をしました - Mitsuyuki.Shiiba
ちょっと前にツイッターで見かけた、ゆめみのフロントエンドコーディング試験 フロントエンドコーディング試験 「RESAS API を使用して、都道府県別の総人口推移グラフを表示するSPAを作る」っていうお題 React の勉強をするのにちょうどいい題材だなぁって思ったのでやってみた。課題を公開してるってことは「やってみてもいいよ」ってことかなと思ってるんだけど、もし違ったら GitHub のリポジトリーを private にするので連絡ください 1週間でやらないといけないところを2ヶ月近くやってるし、コミットログも特に何も考えずにポイポイ書いたから、全然だめなんだけど、でも、色々勉強になったので、とてもよかった。楽しかったー！ つくったもの こんな感じ これでおわりにするー pic.twitter.com/K8zhrRUp54— Mitsuyuki Shiiba (@bufferings)
A Visual Guide to useEffect
Here is what happens when you try to fetch data directly from the body of a functional component in React 👇 Why does this happen and what tools does React offer to solve this problem? Side effects If your React component affects anything outside of itself, it’s called a side effect. Side effects shouldn’t happen during component render. Therefore they do not belong to the body of a functional com
Webフロントエンドの開発効率を高く保つための考え方
これまでいろんな現場でWebフロントエンド開発をしてきて、メンテナンスしやすく効率の高いWebフロントエンド開発をする上で重要になる考えが自分なりにまとまってきたので記事にしてみます。 Worse is Betterという考え方 自分が見てきた中でWebフロントエンドの開発効率が落ちてしまう一番の要因は、きれいで理論的には優れているアーキテクチャを構築しようとしてそれ自体がもたらす複雑性を支えきれないというパターンです。 少し前にフロントエンドにClean Architecture（以下CA、あの同心円の図を指すのは誤用に近いですがここではそれに乗ります）を導入する記事が流行ったと思いますがあんな感じです。ああいったクラスベースでDIが重要となる設計手法はサーバーサイドのJavaでSpringを使うのとは違ってReactがサポートしているものではないため、CAの実現自体に高い設計スキルが必
個人的 Web フロントエンドスキルの獲得方法 - mizdra's blog
ここ2年くらいの話なのですが、仕事で「フロントエンド会」というチーム内委員会のようなものを立ち上げて運営しています。元々1人の Web フロントエンド職人がプロダクトの Web フロントエンドの面倒を見ていたのですが、その方が異動されることになったので、残った人で面倒を見ていける体制を作りましょう、というモチベーションで発足した会でした。この話については以前イベントで発表したので、詳しくはこのスライドをご覧下さい。 speakerdeck.com Web フロントエンド職人の異動とともに入社した id:mizdra が Web フロントエンドが得意だったので、ペアプロやペアオペ、定例会などを通じてどんどんスキルや知見を配っていく、という戦略で運営していました。実際に 2 年経過してみてメンバーも徐々にキャッチアップしていって、ちょっとしたパフォーマンス改善をやってみたり、最近 Gulp や
Webフロントエンド開発(2021)の見取り図をつくりたい
本業はiOS開発なのですが、6月頃から個人開発でWebフロントを触っています。 Webフロントに入門するときに、開発の前提知識・専門用語が多すぎて、脳が処理しきれない状態になりました。 これでも数年前のより混沌としてた時期よりは安定してきているように思うんですが、それでもやはりカオス感は否めませんでした。 Webフロントエンド開発の見取り図があればいいのにと思ったので、自分でちょっとつくってみようと思いました。 個別の技術要素の情報は豊富にある（ありすぎると言ってもいいかもしれません）んですが、全体像がよくわからないので、 たとえば「TypeScriptで開発した方がいいのか？」とか、「Babelとかwebpackってインストールしなきゃいけないの？」とか、 そういう素朴な疑問が学習進めて行っても、なかなか解消できなかったので、いい感じのざっくり感でまとめられたらと思います。 この記事で全
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://x.com/uhyo_/status/1800017146912948259?s=12&t=suYC6B2IhN7jv0qU5zDxmQ
https://twitter.com/shisama_/status/1661628735349755904?s=12&t=suYC6B2IhN7jv0qU5zDxmQ
https://twitter.com/mizchi/status/1660540694610739201?s=12&t=suYC6B2IhN7jv0qU5zDxmQ
🈚️うひょ🤪✒📘 TypeScript本発売🫐 on Twitter: "😨（面倒くさくて個人開発だとESLint入れてない）（Prettierは入れる） https://t.co/7FjwNU68rQ"
奥野 賢太郎 | Motifaryの中の人 on Twitter: "Reactのクリーンアーキテクチャは、もうなんか細かいことを考えずにSOLID原則…というかもうS（単一責任原則）だけ気にしておけば十分で、だらだら書くな、むやみな依存ツリーを組むなの二点です。あとは、多少優劣あっても、なんとでもなります。"