webpack 5 の webpack federation という概念について - Qiita
注意: まだHEADにすらマージされていない機能です。 僕の現状の理解で書いてます。細かいニュアンスは見落としてるかも。 今の課題 異なるチームで、異なるビルドプロセスのものを統合するような巨大なフロントエンド、いわゆるマイクロなフロントエンドやってると、同じようなライブラリが内部的に重複するよね webpack build (chunk) 間で、そういう自明なもののを重複を省いたり、一方向ではなく、相互に読み出せるようにしたいよね ScriptedAlchemy氏の提案 異なるWebpackビルド同士が連携する、Federation という概念を作る。 Host と Remote という概念を追加する。既存のものは Host となる(?)。 Remote は、それぞれに要求する chunk (react, vue など)と、他に外側に提供するインターフェースを明示する。 (optimaz
next.js で lighthouse 満点を目指した - Qiita
なぜやるか 普通にやってても満点は難しい。まずは無で100点を目指す。 Google が Mobile First Index やりだしたら多分 lighthouse のスコアも使うだろうという予想 next.js というある程度現実的なフレームワークを使うことで適度に YakShaving もこなせるだろうという予想 使ったもの next.js: export mode workbox 結果 コード https://github.com/mizchi/next-pwa-boilerplate デプロイ先(netlify) https://eloquent-spence-e8f2bb.netlify.com/ PWA 91点は、 netlify 使っている制限で、HTTP to HTTPS のリダイレクトを設定するにはカスタムドメインを設定する必要があり、金を払いたくないので諦めた。設定す
redux で特定のアクションが来るまで SSR し続ける - Qiita
状況 A のロードが終わったら B をロードする B のロードが終わったら C をロードする C のロードが終わったら end を表示する こういうものをSSRしたい。 問題 ReactDOMServer.renderToString() は同期しかとらないので、普通にやるだけだと A のロード待ちで止まってしまう。 この目的で使っていた https://github.com/recruit-tech/redux-async-loader が react-router v3 に依存していて、更新できていない。 解決策 componentWillMount まで実行されるので、その action を収集する C のロード完了の action が実行されまで、store を更新しながら何度も render する 対象とするコード /* @flow */ import React from 'r
universal-router で react-router を倒す - Qiita
import UniversalRouter from 'universal-router' const routes = [ { path: '', // optional action: () => `<h1>Home</h1>`, }, { path: '/posts', action: () => console.log('checking child routes for /posts'), children: [ { path: '', // optional, matches both "/posts" and "/posts/" action: () => `<h1>Posts</h1>`, }, { path: '/:id', action: (context) => `<h1>Post #${context.params.id}</h1>`, }, ], }, ] co
Type Friendly な Reducer 定義を考えて実装してみた - Qiita
https://qiita.com/mizchi/items/0e2db7c56541c46a7785 を考え直す。 このパターン、明らかにまだ冗長で、しかもFlowもTSもこれでは推論器がよく落ちるという問題があった。 なのでそもそも型が自明なラッパーを定義するのがいいのでは、という発想からスタートしている。 追記: hard-reducer という名前で実装した 既存の reducer 定義の何が面倒臭いか 自明なことを何度も書く 定数値を何度も書いているようで結局 case 文で 一意に紐付いている Action の Union Type の推論が失敗こけやすい (flow も ts もすぐ型をロストする) 巨大 switch case 守るべき reducer の spec とは reducer の (State, Action) => State というインターフェース 最終的に
Web Animations API を使ってみる - Qiita
Animation周りが苦手だったので、Flash のタイムラインアニメーションエディタみたいなものを練習がてら作ってみたい、ということで勉強した。 本記事は勉強ログ気味。 Web Animations API とは CSS Animation の keyframe 制御を JS から可能にしたようなもの。 CSS Animation は 自分で止まったり再開したりできないし、フレーム制御も出来ない。 JS から制御できないのでコントロールしづらかったが、その問題を解決する。 Web Animations 実装具合と Polyfill Can I Use 見る限りは Firefox で 実装済み、 Chrome で実装中 https://caniuse.com/#feat=web-animation polyfill なしで試した結果、chrome で elem.animate(...)
AMP letter を読み解く - Qiita
日本語訳があるので面倒臭がらずに読んだほうがいいです。 要約 AMPは無意識にユーザーがGoogleエコシステムに留まるようになっており、また検索結果に対してプレミアムな演出や優先順位を与えており、Webの中立性を破壊している、という指摘。 Googleが言うように、Webの速さが懸念ならば、AMPという技術の有無に関わらず特定の速度を満たせば今のAMPと同じような特典を与える、また明示的にGoogleのエコシステム内にいるという演出(おそらくヘッダーを付与するなど)を行う、といった提案。 私見 GoogleのWebの速さに対する懸念も、AMPの実装の邪悪さも、自分は両方よく分かる。 AMPは自分の仕事のドメインとしてチェックしているが、プラグインがGoogleのホワイトリストとして管理されていて、実際には政治力を使って、プラグインを登録させるといったアクションが必要になり、日本のような狭
CSS Grid Layout Generator でレイアウト用CSSを生成する - Qiita
最近作ってたものの紹介です。だいたいできたんで公開します。 これは何 ワークフローによりますが、CSS書く際に最初に決めるのは大まかなレイアウト構成だと思います。 で、最近はコンポーネント志向でReactComponentとか書いていくと、各領域が何を占めるかみたいな設計に便利なのが、CSS Grid Layout ですね。たぶんそう。 これからのグリッドレイアウト 第1回 Grid Layout Moduleの概要 CSS Grid だと何がいいかというと、やたらプラガブルなんで、機械的に吐き出しても汚くならない点です。というわけで作りました。 レイアウト設計、毎度結構だるくて、僕みたいなあんまCSS書きたがらないエンジニアだと、GUIでポチポチやって、それっぽいCSSを吐き出してくれるといいな、なんて思ったりしていました。 ただ、自分はこれを作る過程で Grid Layout に対して
2017末時点での React Component 設計のベストプラクティス - Qiita
どう考えているか、というのを聞かれたので、記事に起こしておきます。個人の意見です。 Prettier を使う 気づけばコードの整形を人間がやる時代は終わりました。 細かいコーディングスタイルでレビューの時間を取るぐらいだったら、一貫した自動整形ルールを適用すべきです。 人によっては細かいこだわりがあって prettier の規則が気に食わないかもしれず、僕も最初はそうでしたが、Atomで保存する度に自動整形を走らせる prettier の強烈な開発体験によって、最終的にそれらのこだわりを全て捨てることが出来ました。 生産性を求めるなら、現時点では最優先で導入すべきものです。 React.createClass を使わない v16 で削除されたのでいわずもがな。 同様に、 createClass でしか使えなかった mixin 周辺機能も丸ごと deprecated です。 「可能な限りは」
puppeteerでフロントエンドISUCONのためのパフォーマンス計測ツールを作りたい - Qiita
この記事は、 Recruit Engineers Advent Calendar 2017 の2日目です。 リクルートテクノロジーズで パートナーとして働いてる mizchi です。ここでの仕事は、 yosuke_furukawa が忙しくて調べられないことを、勝手に調べてくることです。 今までリクルートでやったことは Next.js, AMP, PWA, Puppeteer って感じ。今回は Puppeteer を使ったE2Eテストの自動化やパフォーマンス評価の話をします。 puppeteer とは リポジトリ名でわかりますが、GoogleChrome チームが公式に提供する Chrome の Headless Driver です。 スペルがとにかく覚えづらい クロスブラウザテスト以外にはかなり万能なツールです。E2Eテスト、スクレイピング、日々の作業の自動化、なんでもござれ。 他のブラ
Puppeteer で FirstMeaningfulPaint を取得する - Qiita
const puppeteer = require('puppeteer') async function getPerformanceMetrics(page) { const { metrics } = await page._client.send('Performance.getMetrics') return metrics.reduce((acc, i) => ({ ...acc, [i.name]: i.value }), {}) } async function waitForFMP(page) { let doneMet = null while (true) { const data = await getPerformanceMetrics(page) if (data.FirstMeaningfulPaint !== 0) { doneMet = data brea
AMP/PWA をどこで/いつ使うか - Qiita
某所で使った資料の公開版 用語整理 PWA: ネイティブアプリのようなUXを提供するための機能群 SPA: JSで遷移するシングルページアプリケーション AMP: 後述 PWAMP: AMPで流入させてPWAを起動する形式 MFI: モバイルファーストインデックス いまさら聞けないPWAとAMP アメブロ2017: Isomorphic Web Appの進化編 AMP とは イニシャルビューのためのHTMLの特殊なサブセット GoogleにホワイトリストされたHTML属性しか使えない GoogleにホワイトリストされたJSプラグインしか使えない CSSはHEADに全部書く AMP仕様を満たすと、Googleがキャッシュして、モバイルの検索流入ではそのキャッシュを使う HTTPS必須 必ずしも全ページをAMPに対応する必要はない PWA: ServiceWorker の機能 リソースの先読み
Flowtype導入のための指針・実際の運用について - Qiita
このドキュメントの目的 自分は趣味でFlowをずっと使っていて、またプロダクションでも今まで3プロジェクトほどにFlowを導入した。その知見。 「Flow は便利そうだけど、怖い」「いれてみたら色々ハマったからクソ」「わからん、なにもかも…」という人に対し、自分がいままで出くわしたパターンや、聞かれた疑問について、メジャーな解法を提示する。 なぜFlowを導入するか Babel から段階的に導入することが出来る React の JSX にも推論を入れることができる 部分的に適用できる ASTがES準拠であり、ESLintなどがツールが使える(TSは独自AST) それ自身ランタイムに全く影響はないので落とすのも簡単 実際にはReactと一緒に使うのが、エコシステムもユースケースも揃っていて、一番効果を発揮するだろう。それか、小さい npm モジュールを自分で書くとき。 型のメリット/デメリッ
Flow & Redux で Reducer の実装パターンを考える - Qiita
/* @flow */ // constants const INCREMENT = 'increment' const ADD = 'add' export const Actions = { INCREMENT, ADD } // actions export type IncrementAction = { type: typeof Actions.INCREMENT } export type AddAction = { type: typeof Actions.ADD, payload: number } export type CounterAction = IncrementAction | AddAction // reducer type CounterState = { value: number } export default (state: CounterStat
Real World React 2 - 2016/09/27 - React Meetup #4 - Qiita
About @mizchi Qiita のフロントエンドエンジニア React勝手エヴァンジェリスト 4ヶ月で14kg痩せた (80kg => 66kg) 近況 ビジネスドメインのリファクタが主でアウトプット少ない 泥臭系の知見は溜まってる 会社のメンバーが増えた + 自分以外のフロント系の人が増えたので、設計を明示しないといけない この資料は何 JSer.info 5周年記念イベント - connpass (2016/01/16) にて発表した資料を加筆したもの 如何にしてReactを「ふつうのウェブアプリ」に導入していくか ふつうのウェブアプリ NOT SPA SPA でなくともReactは使える jQuery に支配された現代のフロントエンドを改善したい => 複雑なモジュールを局所的に解決するのにReactが有用であることを示したい フロントエンドの流れ AJAX以前(~2003)
春からはじめるモダンJavaScript / ES2015 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 春ですね！人の配置がリファクタリングされ、コードもリファクタリングの季節です。 では僕がここでモダンなJavaScriptとES2015の利点を語る役をやるので、みなさんはチームを説得する役をやってください。 JavaScriptの歴史 まず最初にJavaScriptの歴史を踏まえることで、今学ぶべきものとその理由を確認しましょう。 なぜ2016年の記事でES2016ではなく、ES2015なのか、と疑問に思った方もいるかもしれません。それは、ES2015がただの年次アップデートではなく、これから始まる毎年のメジャーバージョンアップの起点
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Suspense for Data Fetch の SSR時のデータローディングを先取りして実装する - Qiita
render-prop で お手軽な状態管理層を作る - Qiita
Flow で型が書かれた React.Component から storybook を自動生成してみた - Qiita
render prop と HOC について - Qiita
