タグ

ブックマーク / qiita.com/mizchi (27)

  • webpack 5 の webpack federation という概念について - Qiita

    注意: まだHEADにすらマージされていない機能です。 僕の現状の理解で書いてます。細かいニュアンスは見落としてるかも。 今の課題 異なるチームで、異なるビルドプロセスのものを統合するような巨大なフロントエンド、いわゆるマイクロなフロントエンドやってると、同じようなライブラリが内部的に重複するよね webpack build (chunk) 間で、そういう自明なもののを重複を省いたり、一方向ではなく、相互に読み出せるようにしたいよね ScriptedAlchemy氏の提案 異なるWebpackビルド同士が連携する、Federation という概念を作る。 Host と Remote という概念を追加する。既存のものは Host となる(?)。 Remote は、それぞれに要求する chunk (react, vue など)と、他に外側に提供するインターフェースを明示する。 (optimaz

    webpack 5 の webpack federation という概念について - Qiita
    yosuke_furukawa
    yosuke_furukawa 2020/03/14
    面白い概念ではあると思うんだけど、どうなるのかなぁ。既存の枠組みを大きく変えるような気がするので、コアチームはどうするのか。
  • Suspense for Data Fetch の SSR時のデータローディングを先取りして実装する - Qiita

    この記事は react-apollo-hooks から apollo(graphql) 非依存の部分を理解して抜き出した記事です。 追記 動いてる実装は https://github.com/mizchi-sandbox/ssr-data-fetch にあります。 さらに追記 https://github.com/mizchi/ssr-helpers ライブラリに切り出したので @mizchi/ssr-heplers でインストールできます。 import { renderAsync, createResource } from "@mizchi/ssr-helpers"; // data fetcher const resource = createResource(async () => { await new Promise(r => setTimeout(r, 1000)); re

    Suspense for Data Fetch の SSR時のデータローディングを先取りして実装する - Qiita
  • 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 のリダイレクトを設定するにはカスタムドメインを設定する必要があり、金を払いたくないので諦めた。設定す

    next.js で lighthouse 満点を目指した - Qiita
  • render-prop で お手軽な状態管理層を作る - Qiita

    同期 ちょっとした状態を作るのに extends React.Component したくない。状態を隠蔽したHOCも書きたくない。 かつそれでいてある程度宣言的にしたい。 render-props で実装すれば良いのでは? 実装 /* @flow */ import React, { type Node } from 'react' // Generic State Manager export default class WithState<State> extends React.Component< { initialState: State, render: (State, ((State) => State) => void) => Node }, State > { constructor(props) { super() this.state = props.initialS

    render-prop で お手軽な状態管理層を作る - Qiita
  • Flow で型が書かれた React.Component から storybook を自動生成してみた - Qiita

    作ったけど全然未完成です。いろんな都合で黒魔術です。 まだ全然。どっちかというとASTで遊んでみた系ですが、これを想定してない趣味プロジェクトのcomponentsを対象に突っ込んだら、意外と半分ぐらいは動きました。 なにこれ flow が入ってることは前提

    Flow で型が書かれた React.Component から storybook を自動生成してみた - Qiita
  • 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

    redux で特定のアクションが来るまで SSR し続ける - Qiita
  • universal-router で react-router を倒す - Qiita

    Universal Router とは isomorphicガチ勢の kriasoft 先生作の Router ライブラリ。 内部的には path-to-regexp だから express と同じルール 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>Po

    universal-router で react-router を倒す - Qiita
    yosuke_furukawa
    yosuke_furukawa 2018/02/05
    React Meetup でパネルディスカッションの時にrouterをviewのライブラリに依存させるのではなく、SPAのためのrouterがあってそれのview bindingsがあったほうが良いという話が腑に落ちて調べてもらうことにしたそれの結果です。
  • 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 というインターフェース 最終的に

    Type Friendly な Reducer 定義を考えて実装してみた - Qiita
  • 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(...)

    Web Animations API を使ってみる - Qiita
  • AMP letter を読み解く - Qiita

    語訳があるので面倒臭がらずに読んだほうがいいです。 要約 AMPは無意識にユーザーがGoogleエコシステムに留まるようになっており、また検索結果に対してプレミアムな演出や優先順位を与えており、Webの中立性を破壊している、という指摘。 Googleが言うように、Webの速さが懸念ならば、AMPという技術の有無に関わらず特定の速度を満たせば今のAMPと同じような特典を与える、また明示的にGoogleのエコシステム内にいるという演出(おそらくヘッダーを付与するなど)を行う、といった提案。 私見 GoogleのWebの速さに対する懸念も、AMPの実装の邪悪さも、自分は両方よく分かる。 AMPは自分の仕事のドメインとしてチェックしているが、プラグインがGoogleのホワイトリストとして管理されていて、実際には政治力を使って、プラグインを登録させるといったアクションが必要になり、日のような狭

    AMP letter を読み解く - Qiita
  • render prop と HOC について - Qiita

    react-router の mjackson が HOC を批判していたので、自分の考えを書いておきます。 Use a Render Prop! - componentDidBlog https://cdb.reacttraining.com/use-a-render-prop-50de598f11ce mjackson の主張の要約 ES2015 Classes は mixin 的な振る舞いをサポートしていない HOC は 新しい mixin だ 主張1: HOC は自身の振る舞いを自己規定するものである const connector = ReactRedux.connect(...) compose( connector, pure, lifecycle({ componentDidMount() { console.log('mounted') } }) )(Counter) こ

    render prop と HOC について - Qiita
  • CSS Grid Layout Generator でレイアウト用CSSを生成する - Qiita

    最近作ってたものの紹介です。だいたいできたんで公開します。 これは何 ワークフローによりますが、CSS書く際に最初に決めるのは大まかなレイアウト構成だと思います。 で、最近はコンポーネント志向でReactComponentとか書いていくと、各領域が何を占めるかみたいな設計に便利なのが、CSS Grid Layout ですね。たぶんそう。 これからのグリッドレイアウト 第1回 Grid Layout Moduleの概要 CSS Grid だと何がいいかというと、やたらプラガブルなんで、機械的に吐き出しても汚くならない点です。というわけで作りました。 レイアウト設計、毎度結構だるくて、僕みたいなあんまCSS書きたがらないエンジニアだと、GUIでポチポチやって、それっぽいCSSを吐き出してくれるといいな、なんて思ったりしていました。 ただ、自分はこれを作る過程で Grid Layout に対して

    CSS Grid Layout Generator でレイアウト用CSSを生成する - Qiita
  • 2017末時点での React Component 設計のベストプラクティス - Qiita

    どう考えているか、というのを聞かれたので、記事に起こしておきます。個人の意見です。 Prettier を使う 気づけばコードの整形を人間がやる時代は終わりました。 細かいコーディングスタイルでレビューの時間を取るぐらいだったら、一貫した自動整形ルールを適用すべきです。 人によっては細かいこだわりがあって prettier の規則が気にわないかもしれず、僕も最初はそうでしたが、Atomで保存する度に自動整形を走らせる prettier の強烈な開発体験によって、最終的にそれらのこだわりを全て捨てることが出来ました。 生産性を求めるなら、現時点では最優先で導入すべきものです。 React.createClass を使わない v16 で削除されたのでいわずもがな。 同様に、 createClass でしか使えなかった mixin 周辺機能も丸ごと deprecated です。 「可能な限りは」

    2017末時点での React Component 設計のベストプラクティス - Qiita
  • 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でフロントエンドISUCONのためのパフォーマンス計測ツールを作りたい - Qiita
  • Puppeteer で FirstMeaningfulPaint を取得する - Qiita

    概要 パフォーマンスメトリクスのAPIを有効化する setTimeout ループで FMP取得まで待つ コード npm install -S puppeteer 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 getPe

    Puppeteer で FirstMeaningfulPaint を取得する - Qiita
  • 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 の機能 リソースの先読み

    AMP/PWA をどこで/いつ使うか - Qiita
    yosuke_furukawa
    yosuke_furukawa 2017/07/08
    社内で発表してもらった資料。さすがのプレゼンだった
  • Flowtype導入のための指針・実際の運用について - Qiita

    このドキュメントの目的 自分は趣味でFlowをずっと使っていて、またプロダクションでも今まで3プロジェクトほどにFlowを導入した。その知見。 「Flow は便利そうだけど、怖い」「いれてみたら色々ハマったからクソ」「わからん、なにもかも…」という人に対し、自分がいままで出くわしたパターンや、聞かれた疑問について、メジャーな解法を提示する。 なぜFlowを導入するか Babel から段階的に導入することが出来る React の JSX にも推論を入れることができる 部分的に適用できる ASTがES準拠であり、ESLintなどがツールが使える(TSは独自AST) それ自身ランタイムに全く影響はないので落とすのも簡単 実際にはReactと一緒に使うのが、エコシステムもユースケースも揃っていて、一番効果を発揮するだろう。それか、小さい npm モジュールを自分で書くとき。 型のメリット/デメリッ

    Flowtype導入のための指針・実際の運用について - Qiita
  • Flow & Redux で Reducer の実装パターンを考える - Qiita

    背景 段階的に片付けしていく、というFlowのコンセプトで、最も需要が高いのは、純粋なJSで済む状態管理、 とくに Redux の Reducer の部分であると考えられる。 実際のコード とりあえずこうなるだろうというのを書いてみた。 /* @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 CounterA

    Flow & Redux で Reducer の実装パターンを考える - Qiita
  • 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)

    Real World React 2 - 2016/09/27 - React Meetup #4 - Qiita
    yosuke_furukawa
    yosuke_furukawa 2016/09/27
    #reactjs_meetup
  • 春からはじめるモダンJavaScript / ES2015 - Qiita

    春ですね!人の配置がリファクタリングされ、コードもリファクタリングの季節です。 では僕がここでモダンなJavaScriptとES2015の利点を語る役をやるので、みなさんはチームを説得する役をやってください。 JavaScript歴史 まず最初にJavaScript歴史を踏まえることで、今学ぶべきものとその理由を確認しましょう。 なぜ2016年の記事でES2016ではなく、ES2015なのか、と疑問に思った方もいるかもしれません。それは、ES2015がただの年次アップデートではなく、これから始まる毎年のメジャーバージョンアップの起点となるバージョンであり、またES5から飛躍的に仕様が増えたバージョンであるからです。 簡単に(雑な)歴史を紹介します。 ブレンダン・アイクによってNetScapeに実装/搭載された古の時代〜IE6 (1996~2005) ES3: 一時はシェア7割を誇ったレ

    春からはじめるモダンJavaScript / ES2015 - Qiita