俺の webpack.config.js-20200503 - mizchi's blog
基本思想 とにかく薄く。必要なものだけ。基本は ts-loader を transpileOnly: true で使うだけ。最悪これだけでいい。型チェックはIDEか yarn tsc -p . --noEmit でやる。 CRA や parcel は使わない。暗黙な振る舞いが多すぎるので。一切勉強したくない人はいれていいと思うが、その場合 eject しない、dist ディレクトリをそのまま使うこと前提。 style-loader/css-loader は外部CSSを読むときに設定する worker-plugin はなくてもいいけど、 worker もビルドしたいことが多いので、入れていることが多い html-webpack-plugin と webpack-dev-server 組み合わせると、他と組み合わせずに完結して動く。このHTMLを本番で使わずとも、デバッグで使ってることが多いの
2020 年、 React 軸で学ぶべき技術 - mizchi's blog
なぜ仮想 DOM という概念が俺達の魂を震えさせるのか - Qiita から 5 年経ち、 仮想 DOM を備えた React やそれを採用した Vue や他のライブラリも市民権を得たように思います。 有用な技術が市民権を得る、というのはエコシステムが花開くことでもあります。新しいプロダクトを作る際の技術選定において、 TypeScript + React が常に正解というわけではないですが、このスタックはかなり強力だという手応えがあります。 このスタックは得意のウェブフロントエンドは勿論、それ以外もとりあえず 80 点ぐらいの品質でプロトタイピングできる、というようなエコシステムになってきたような肌感があります。 モダンフロントエンドだと TypeScript と Webpack は採用しているのを前提として、本記事では React を軸にその技術を活かすために、次の 6 個の技術を紹介
フリーランス完走した感想 - mizchi's blog
2 年ほど走ってみました。 Qiita の Increments を退職します - mizchi's blog からの 転職活動 https://gist.github.com/mizchi/4e097923bb92399d03ced9da44f15cfa の結果 この記事は、自分の体験を書くことで、どういう人がフリーランスに向いてるか、というのをわかるように書いたつもりです。自分に近い属性ということで、ある程度プログラマとして経験を積んだ人向けです。 フリーランス辞める理由 フリーランスが嫌になったわけではないです。機会があればまたやりたいとも思っています。今回はフリーランスを続けるより良い選択肢があった、というだけの話です。 個人事業主を 2 年やって、消費税の徴収方式が変わるタイミングがあり、法人化してフリーランスの働き方を続けるか、個人事業主をやめるか、という 2 つの選択肢があり
React Hooks をどう使っていくか - mizchi's blog
大きく、末端コンポーネントと全体アーキテクチャの視点がある。 末端コンポーネントでの Hooks ここはあまり議論の余地なく、setState で local state を持っているものや、 componentDidMount していたものを置き換えることが出来ると思う。 FC を class にせずにちょっとリッチにするのが簡単になる。 class の setState 相当 function Counter() { const [count, setCount] = useState(0); const onClick = useCallback(() => setCount(s => s + 1), []); return <button onClick={onClick}>{count}</button> } componentDidMount / componentWillUn
実践: React Hooks - mizchi's blog
hooks が発表されてから趣味でも現場でもずっと hooks を使っています。おかげでだいぶこなれてきて、だいたいなんのライフサイクルでも表現できるようになってきました。 最初は単に useState が state を、 useEffect が componentDidMount/componentDidUpdate を置き換えるもの、と説明を済ますつもりでしたが、 useEffect についてはライフサイクルのモデルがぜんぜん違うので、別の説明をする必要があるように感じていました。 で、その結果 React Hooks を理解するには、関数のメモ化を理解するのが最も簡単だと思ったので、その説明をしつつ、イディオムを解説していこうと思います。 最初に: React Hooks は何であり、何ではないか 関数コンポーネントが状態を持てるようにするもので、関数のメモ化のテクニックを多用しま
今年お世話になったCLIコマンド集 - mizchi's blog
ヒストリ履歴からよく使ってるものをお焚き上げする。 注意点: npm 周り、グローバルコマンドは npm i -g で入れてて、ローカルで扱うものは yarn で使うという癖がある 追記: シェルじゃなくてCLIだろと言われるのが多かったので訂正した vscode $ code . -r 現在ディレクトリを VScode で開く。 -r が肝で、新しいウィンドウを生成せず、既存のウィンドウを開き直す。 yarn $ yarn install --prefer-offline yarn install 時にローカルキャッシュを優先する。テザリング環境下でリポジトリを作成するのに便利。 フリーランスになってから出先で作業することが多く、ギガ足りない問題が多々発生した。 git $ git clone <github-url> --depth 1 HEAD だけ clone する。テザリング環境
Elm 2日ほどやった感想 - mizchi's blog
12月はなんとなく新しいことをやりたくなる。ということで、elm をやってみた。 大昔に触った気がするけど、文法が Haskell っぽいこと以外、何も覚えてなかった。というか当時触った signal とかがなくなってたので別物になってた。 作ったもの 勉強がてら作った、球拾いゲームみたいな何か コードはここ https://github.com/mizchi-sandbox/elm-playground elm-platform, svg の扱い, キー入力、乱数の副作用の分離などが学べた。乱数は面倒くさくなったので外部(JS)からSeed与える方式にして、気持ち純粋になった。 (自分の)環境構築 Parcel を使った brew install elm # OSに応じて mkdir elm-playground cd elm-playground yarn init -y yarn a
TypeScript入門以前ガイド - mizchi's blog
某社で自分が React/Redux + TypeScript などの講習をやってみた結果、TypeScript 入門用資料が必要だと思って書いたやつです。 このドキュメントのターゲット TypeScript で書かれたプロジェクトに参加する人 TypeScript を導入するために、その事前知識が必要な人 このドキュメントの読み方 ES2015 for Beginners ES2015 for ES5 Programmers ES Modules 非同期表現: Promise と async/await TypeScript エコシステム編 自分が React/Redux などの講習でいろいろやってみた結果、 ES2015 と TypeScript を同時に教えると、初学者は何がどの概念に由来するかの区別が出来ずに混乱します。なので、ES5 -> ES2015, ES2015 -> Ty
Redux 再考 - mizchi's blog
今まで自分で作ったものが十数個、仕事で5社ぐらいの redux を見てきたので、その結果思うところを書く。 前提として、自分はエコシステムに乗るという意味で今では redux 肯定派だが、redux それ自身が過剰に抱えている複雑さはもっと分解されるべきだ、という立場。 Redux がうまく設計されているとどうなるか 一貫した一つの設計論に従うので、考えることがなくなる 難しさが廃されるのではなく、難しい部分が一箇所に集中する。React Component の末端では、何も考えることがなくなる。状態管理という難しい部分を作る人と、末端のコンポーネントのデザインに注力する人を分けられる。 大規模になっても設計が破綻しにくい、というエンタープライズ向きな特性を持つ。が、その技術基盤は(静的)関数型由来の考えが多く、基礎設計や基盤理解にはハイスキルが要求され、需要と適用対象のミスマッチを感じる
Chrome に PWA for Desktop が来ていたので next-editor で試した - mizchi's blog
追記: Canary じゃなくてもいいらしいのでタイトル修正した。が…実装具合はよくわからない 今年中に来るとは聞いていたやつ。要はウェブアプリを デスクトップアプリ化する。Electron と違って Chrome の Sandbox と同じ権限で動いている Twitter Lite をデスクトップ PWA にして使ってるんだけど、最 & 高です。 Mac だと Chrome Canary で enable-desktop-pwas のフラグを立てると使えます。 pic.twitter.com/0TPhe8gyQL— Eiji Kitamura / えーじ (@agektmr) 2018年7月12日 ちなみに Chrome Canary + フラグは上級者向けなので、自身のない方はいましばらくお待ち下さい。そのうち安定版で普通に使えるようになります。— Eiji Kitamura / えー
漸進的型付け言語の時代に必要なもの - mizchi's blog
最近では、Gradual Typing、漸進的型付けと呼ばれる型システムを備えた言語(拡張)が増えてきています。 次のようなもの JavaScript: TypeScript / Flowtype Python: mypy / pyre-checker PHP: hack / php-storm flow/pyre-checker/hack と facebook 製が多いですね。 この記事は、それらを使う動機と運用について書きます。この記事の出発点として、 おそらく TypeScript/Flow で発生した問題が後発の言語で発生すると思っており、それらを使う方や、設計する人への提言でもあります。 自分は昔 https://github.com/mizchi/TypedCoffeeScript というAltJS作ろうとして、実装のツラミはなんとなく知ってるつもりです。ホビーレベルで作るもの
React Component 視点でのアトミックデザインの解釈といくつかの疑問 - mizchi's blog
フロントエンドの中でも、JS書くプログラマと、CSSを書くマークアップと、デザインカンプを作るデザイナで、コンポーネントという概念がズレる。だいたいこれらが一人だったり兼任だったりで1~2レイヤーの開発ステップになるが、完全分業だったり人が多くなると混乱の元になる。 誰かが決定的に間違ってるというつもりはない。正直、どっちかというと本来のデザイナ側の用語定義に倒した方がいい気がしているが、プログラム上の都合もいろいろ混ざってきて、話が簡単ではない。 自分の理解が間違ってる可能性もある。この記事はレビューをもらうために書いている側面もあり、指摘されたら追記していく。 読んだもの。 Atomic DesignとCSS設計 - Atomic Designとは何か | CodeGrid Atomic Designの考え方と利点・欠点 – wkr. Atomic Design の大雑把な理解 基本的
ServiceWorker as a Service, または Universal ServiceWorker という発想 - mizchi's blog
ServiceWorker とは本質的に リクエスト＆レスポンスモデルであるので、それをサーバーサイドで実装で一種のサーバーロジックとして動かしてしまって良いはずだ ー という発想に目から鱗だったので、ちょっと考えてみたいと思う。 www.publickey1.jp ここで試せる。 https://cloudflareworkers.com/#a9bc9ef6b4248289c71518581df30bc7:https://tutorial.cloudflareworkers.com Cloudflare はCDN業者なので、 それに特化して Service Worker as a Service みたいな表現はしていないが、実態としてはサーバーサイド ServiceWorker だ。Fastly では varnish のミドルウェアなどでキャッシュ破棄設定のロジックやリダイレクトを書いて
フロントエンドの負債と向き合う - mizchi's blog
某所で書いたものを公開用に書き直したもの 前提 フロントエンドでTDDは難しい、というかほぼ不可能である。なぜなら事前に副作用をデータとして表現できるか不明だからだ。たとえばあなたのプロダクトの画面の何処かにボタンを追加するために、その内部表現を事前に思い浮かべることが可能だろうか？ react-redux などのFluxフレームワークは如何に副作用をアクションとして表現することで、テスト・デバッグのための情報を残すか、という視点で発展してきた側面がある。あの冗長なアクション定義は、全てデバッグのために書いていると言っても、過言ではない。それすら「Textは文字がある」といったトートロジーなデータになりがち。 フロントエンドの現実的な単体テストは、他の開発者のために、自分が書いたコードの要求を満たしているか検知する手段として、防衛的にテストアフターしておく。これぐらいしか現実的な手法がない
当初の懸念どおりブラウザのプッシュ通知は邪悪に使われはじめている。実装側はクリックまで購読確認を待つべき。 - mizchi's blog
追記: 2019/11/12 2年経ったけど体験が悪化し続けた結果、 Firefox がこの記事の通りになりましたね… www.fxsitecompat.dev プッシュ通知、ネイティブアプリの機能郡をWebに持ち込むPWA技術の売りの一つだが、当初から懸念されていたとおり、非常にノイジーなものとなってしまっている。自分も気づけばあらゆるサイトの購読確認を、無意識で拒否を押すようになってしまった。 hagex.hatenadiary.jp 少し前の記事。最近はどこかで wordpress のプラグインになったのか、目にする機会が非常に多くなり、非常にストレスフル。最初は技術的な目新しさからか、ある程度容認していたが、さすがにこの状況が悪化する一方で、本気でやばいんじゃないかと思っている。とくに初見のブログの記事を読む前に、購読確認が出るのが最悪の体験となっている。 そもそもプッシュ配信とは
60FPSへの夢、そしていかにキャッシュを従えるか / 書評「超速! Webページ速度改善ガイド 使いやすさは「速さ」はじまる」 - mizchi's blog
CAの ahomu/1000ch さんからご恵贈頂き、レビュー書いてくれと頼まれたので、自分のパフォーマンスというものへの思いの丈と共に書評を書こうと思う。 自分も6年ぐらいフロントエンドぐらいやってきたけど、あんまりちゃんと用語定義をしないまま「勘」で調査しがちだったのと、彼ら二人がどの数値見てるんだろう、という視点で読んだ。 gihyo.jp 要約: これはフロントエンドエンジニアの勘を体系化/言語化したものだ フロントエンドエンジニアにとって Chrome DevTools は日常的にお世話になる、「これナシでは生きていけない」という類のツールだ。だが、これの読み方は癖があり、経験的に蓄積してきた積み重ねがなければやや難しい側面があった。 この本は、フロントエンドエンジニアが今まで経験的に蓄積してきたでろう「勘」を、Webの仕様や各社のUXガイドラインの明確な定義を通して再整理したも
やはりHTML/DOMは再発明されるべきじゃないか - mizchi's blog
と思う次第である。以下理由。 JavaScript, GUI設計の今 JSはそのプラットフォーム特性上、あらゆる言語の使用者の、あらゆる不満が集まる場所で、ヘイトを集めやすい環境だと思う。近年は npm というプラットフォームの登場でエコシステムが生まれ、思いつく限りあらゆるメソッドが適用されてきた。貧弱な言語基盤だが、その中で生き残った方法論が、今一番GUIの課題を上手く扱えている、と自分は考えている。 React/Redux や Angular によって、Flux/MVVMという抽象パターンが枯れてきたように思う。(この際、現場はまだ jQuery だぞ、みたいな話は無視する)。要は View は State の写像である、ということに尽きる。State はシリアライズ可能(JSON)で、Flux Action/Rx.Observable の Event Stream を入力とし、それ
Redux は 概念的に Rx のサブセットであるという話 - mizchi's blog
この資料のアレ。 mizchi.hatenablog.com Reducer は単なる (State, Action) => State の関数で、redux.combineReducers は複数の reducer を名前空間でマップした新しい reducer にするもの。 Rx分かる人、Redux分かる人向けに、 redux.combineReducers を実装して、Rx.Observable.scan で reducer として実際に動くコードを書いた。 const Rx = require('rx') const combineReducers = reducerMap => { const initialState = Object.entries( reducerMap ).reduce((acc, [key, reducer]) => { return Object.ass
フリーランス一週間目、不安、人格、Redux - mizchi's blog
契約先 週3でアカツキ様、週2でリクルートテクノロジー様で開発に関わらせてもらっている。どちらも公開の許可を貰った、というかむしろ宣伝してくれと言われた。アカツキは @seizans さん、 リクルートテクノロジーズは @yosuke_furukawa さんの繋がりで仕事をとった。事前に面識がある人に相談することで、人格面や技術面のすり合わせが楽で、ゼロベースの信頼関係にならず対人関係のストレスが減るようにコントロールした、つもりではある。 全く違う仕事をしているのではなく、どちらも redux 周りをやっている。みんなそこで苦しんでいる。今、界隈を絶望させているのは react-router v4 であり、これが諸悪の根源であるといって差し支えない。既に辛い気持ちなっている。絶対に倒したい。 ネットの人格 契約先の話で思い出したんだけど、僕はネットで暴れてる方と、リアルで卑屈になってる人
Re: React.js界隈の人に聞きたい - mizchi's blog
React.js界隈の人に聞きたい 前提 Reactより前に僕がやりたかったこととして、冪等性の担保の為に毎フレーム document.body.innerHTML を書き換えたかったがパフォーマンス的にそれが許されなかったが、Reactは擬似的にそれを達成させてくれたという圧倒的感謝🙏がある— ダイナモポグラマ (@mizchi) 2016年5月23日 SPA 世の中にSPAの需要があるのか？という点考えていたけど、需要がないからSPA技術がいらない、というのはたぶん間違ってて、SPA技術を持たない人が多いからその発想もなく、SPAで達成できることがイメージ出来ないのがアプリケーション設計の縛りになっている、という感じな気がする— ダイナモポグラマ (@mizchi) 2016年5月23日 GmailやTrelloやPivotalやグラブルは異常な技術の集大成ではなく、個別に分解可能な
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
