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

  • なぜ仮想DOMという概念が俺達の魂を震えさせるのか - Qiita

    追記: 情報が色々と古くなったため、2020年に書き直した版へのリンクを張っておきます。 この記事は VirtualDOM Advent Calendar 2014 - Qiita の初日です。 初日ということで、基調講演風に、Virtual DOMとはなにか、なぜ僕はこんな興奮しているのか!という話から。 Virtual DOMとはなにか 既存の概念で当てはめると、JavaScriptのMVC, MVW(Whatever)フレームワークのViewに位置します。が、その程度では終わりません。仮想DOMとは世界を革命する力であり、このjQueryのDOM操作で汚れきったフロントエンドを救う救世主なのです。 現時点で自分が知っている限りは、以下の実装を指します。 facebook/react 最も使われてるFacebookの実装 Matt-Esch/virtual-dom Altenative

    なぜ仮想DOMという概念が俺達の魂を震えさせるのか - Qiita
    l08084
    l08084 2022/02/03
  • Webpack チャンク最適 テクニック - Qiita

    ターゲット 巨大なSPAを作ってしまった人へ 巨大なSPAを作らないように気をつけたい人へ 今回はJSだけにフォーカスするが、もっというと、 超速 を読んでください。 注意:資料は、webpack チャンクの挙動を概念的に説明することを重視しているので、 webpack の詳細な設定や、出力ファイル名などは実際の処理と一致しない。適宜自分の手元にある設定とすり合わせるように。 昨今のJSビルド問題と、その解決のためのゴール設定 巨大なJS(+最近は in JS された各種SVGCSS)はダウンロードだけではなく、UIスレッドのCPUをブロックする。 これはとくにCPUが貧弱な端末で体験が悪化する。そしてビルド時間で開発者体験を阻害する。 できれば webpack 推奨の 144kb 以内にしたい…が現実的に難しいので、 せめて 350kb ぐらいに抑えたい。 SPAなら (ローディン

    Webpack チャンク最適 テクニック - Qiita
    l08084
    l08084 2020/02/25
  • Berry(yarn v2) + TypeScript + PnP + Workspace でプロジェクトを作ってみた感想 - Qiita

    Berry(yarn v2) + TypeScript + PnP + Workspace でプロジェクトを作ってみた感想npmYARNyarnpkg berry(yarn v2) がそろそろリリースということで、使い込んでみた。その感想や yak-shaving などについて。 このリポジトリ https://github.com/mizchi/berry-typescript-project 日語での網羅的な解説はこちらの記事がくわしい https://qiita.com/dojineko/items/6f65fde3c47aed8b6318 記事は pnp の仕組みと webpack, jest, typescript を設定する泥臭い話がメイン。 使ってみた感想 npm とは完全に別系統に進化しつつある。互換があんまりない。 今対応するのは時期尚早でアーリーアダプターだけでよい

    Berry(yarn v2) + TypeScript + PnP + Workspace でプロジェクトを作ってみた感想 - Qiita
  • lodash やめ方 - Qiita

    みなさん、 lodash で消耗してますか? 私は消耗しています。 なぜ lodash で消耗するかというと、とにかく思考停止でインストールされ、 node_modules 下で大量に重複します。サイズが大きいlodashが複数バンドルされてビルドされると、重篤なパフォーマンス上の問題を引き起こします。 lodash には実装上の問題もあり、異様に丁寧に、そして富豪的に作られており、その結果ビルドサイズが無駄に大きいです。丁寧に作られて入るのですが、現代のフロントエンド水準や一般的なポリフィルと噛み合っていません。というわけで、常々やめたいと思っています。 ちゃんとES201xを追ってる人からすると、ほとんどの lodash のメソッドは不要に見えるはずです。エントリは、思考停止で lodash で実装しようとする人に、ちょっと考え直しては? と投げつける用の記事になります。 現代におい

    lodash やめ方 - Qiita
    l08084
    l08084 2019/12/23
  • GitHub Actions で Windows IE11 と Mac Safari を selenium-webdriver で動かす - Qiita

    GitHub Actions で Windows IE11 と Mac Safari を selenium-webdriver で動かすSeleniumselenium-webdriver 最近得た天啓で、 「GitHub Actions はコンテナを windows / mac / ubuntu から選べるということは、 物の safari と ie11 を selenium-webdriver で動かすことができるのでは?」 と思ってガチャガチャやってみたら、なんとできてしまったので、紹介します。 今回は node で。 name: xbrowser on: [push] jobs: e2e-ie: runs-on: windows-latest steps: - uses: actions/checkout@v1 - uses: warrenbuckley/Setup-Nuget@

    GitHub Actions で Windows IE11 と Mac Safari を selenium-webdriver で動かす - Qiita
    l08084
    l08084 2019/09/20
  • 俺が考えた最強の Reactのステートレスコンポーネントの書き方 - Qiita

    最近自分はこう書いてるという例。意見が欲しい。 この記事に redux は出てこない。 参考: https://qiita.com/mizchi/items/bcb1aef8d1f14f8d0b4a 構成要素 React flow styled-components recompose 以下 SFC = Stateless Functional Component /* @flow */ import React from "react" import styled from "styled-components" import pure from "recompose/pure" type Props = {| value: string |} export default pure(function Example(props: Props) { const { value } = p

    俺が考えた最強の Reactのステートレスコンポーネントの書き方 - Qiita
    l08084
    l08084 2018/04/06
  • 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
    l08084
    l08084 2018/03/15
  • 真に Universal な ReactComponent を書く - Qiita

    ややお気持ち多め。 前置き 最近の個人的な考えとして、React 書く人は ReactNative 側にスキルを寄せたほうが良いのではないか、と思っている。 ReactNative の需要の高まりは凄い。最初はプロトタイピング採用だったのが、徐々にプロダクションに出始めている。今年末には新規プロジェクトの10~20%は ReactNative になるんじゃないか?という感すらある。 僕はデスクトップのブラウザは好きだけども、残念ながら、世の中の趨勢はモバイル側にある。その上でフロントエンドにロックインすることをリスクに感じている。PWAのアプリケーションも来そうではあるが、直近の需要を賄うためにやはりReactNativeに習熟しておきたい。 大事なのは、「考え方として」 ReactNative に軸足を移したほうが色々といいということだ。 Web は基的に動きが少ない。見栄えをよくした

    真に Universal な ReactComponent を書く - Qiita
    l08084
    l08084 2018/03/01
  • 2017末時点での React Component 設計のベストプラクティス - Qiita

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

    2017末時点での React Component 設計のベストプラクティス - Qiita
    l08084
    l08084 2017/12/17
  • Qiita beta版のフロントエンドパフォーマンス改善案 - Qiita

    ふとログインすると beta 版UIってのが使えた。完全に dev.to 意識してて笑った。 実際には自分が残してきたロードマップや、Component が使われているのであろうのがわかって、そうそうこれがやりたかったんだよって感じで、とはいえまだ改善点がたくさんって、今の中の人達もわかってると思うけど、元中の人として dev.to ぐらいやるにはどうすればいいってのを残しておきます。 わかる変更点 CSSの脱bootstrap色が強くなった トップ画面が、ユーザーごとのカスタムフィードから beta版 の人気の投稿が主になった 元々そういう目的で企画を起こした記憶がある… フレンドフィードもうあんまり使われてないよね クエリが重いフレンドフィードより、静的にキャッシュできるランキングがトップにあるのはチューニングしやすい やや無理難題だったり、中の都合も察してるけど、できるだけ目視とDe

    Qiita beta版のフロントエンドパフォーマンス改善案 - Qiita
    l08084
    l08084 2017/11/29
  • フロントエンドエンジニアのための webpacker - Qiita

    webpacker:install:react とかはしない。Rails上で素の webpack がほしい人のためのガイド。 rails new ~ で webpacker が生成されるのは v5.1 以降らしいが、 Rails 4.2 以上ならインストール可能。 モチベーションとして、アセットサーバーとかダイジェストの生成とかを rails 側に投げたい。あわよくばいい感じに code splitting にも載せたい。そのための下調べ(この記事では code splitting までいかない。結局 digest の問題がある) プロジェクトを生成

    フロントエンドエンジニアのための webpacker - Qiita
    l08084
    l08084 2017/09/06
  • 1