lodash やめ方 - Qiita
みなさん、 lodash で消耗してますか？ 私は消耗しています。 なぜ lodash で消耗するかというと、とにかく思考停止でインストールされ、 node_modules 下で大量に重複します。サイズが大きいlodashが複数バンドルされてビルドされると、重篤なパフォーマンス上の問題を引き起こします。 lodash には実装上の問題もあり、異様に丁寧に、そして富豪的に作られており、その結果ビルドサイズが無駄に大きいです。丁寧に作られて入るのですが、現代のフロントエンド水準や一般的なポリフィルと噛み合っていません。というわけで、常々やめたいと思っています。 ちゃんとES201xを追ってる人からすると、ほとんどの lodash のメソッドは不要に見えるはずです。本エントリは、思考停止で lodash で実装しようとする人に、ちょっと考え直しては？ と投げつける用の記事になります。 現代におい
webpack 5 の webpack federation という概念について - Qiita
注意: まだHEADにすらマージされていない機能です。 僕の現状の理解で書いてます。細かいニュアンスは見落としてるかも。 今の課題 異なるチームで、異なるビルドプロセスのものを統合するような巨大なフロントエンド、いわゆるマイクロなフロントエンドやってると、同じようなライブラリが内部的に重複するよね webpack build (chunk) 間で、そういう自明なもののを重複を省いたり、一方向ではなく、相互に読み出せるようにしたいよね ScriptedAlchemy氏の提案 異なるWebpackビルド同士が連携する、Federation という概念を作る。 Host と Remote という概念を追加する。既存のものは Host となる(?)。 Remote は、それぞれに要求する chunk (react, vue など)と、他に外側に提供するインターフェースを明示する。 (optimaz
Monaco Editor をハックする - Qiita
for ginza.js#7 @mizchi このスライドツールの作者 今はワケあってこの会場の会社にいる(Plaid) お品書き VSCode をハックしようとして敗北した MonacoEditor をハックしてる フロントエンドの仕事、ブラウザだけで完結するはず、と思ったことないですか？ フロントエンドのおしごと コンポーネントを作る ビルドする テストする ブラウザで確認する フロントエンドのおしごと コンポーネントを作る(ブラウザでできる？) ビルドする(ブラウザでできる?) テストする(ブラウザでできる) ブラウザで確認する(ブラウザでできる) 経緯: コンパイラを作った フロントエンドでフロントエンドをビルドする で、ブラウザ上で動くコンパイラ作った 今日は、このコンパイラを動かすためのエディタを作ってる話 @mizchi/web-compiler (仮)ができること サンプル
Webpack チャンク最適 テクニック - Qiita
ターゲット 巨大なSPAを作ってしまった人へ 巨大なSPAを作らないように気をつけたい人へ 今回はJSだけにフォーカスするが、もっというと、 超速本 を読んでください。 注意：本資料は、webpack チャンクの挙動を概念的に説明することを重視しているので、 webpack の詳細な設定や、出力ファイル名などは実際の処理と一致しない。適宜自分の手元にある設定とすり合わせるように。 昨今のJSビルド問題と、その解決のためのゴール設定 巨大なJS(+最近は in JS された各種SVGやCSS)はダウンロードだけではなく、UIスレッドのCPUをブロックする。 これはとくにCPUが貧弱な端末で体験が悪化する。そしてビルド時間で開発者体験を阻害する。 できれば webpack 推奨の 144kb 以内にしたい…が現実的に難しいので、 せめて 350kb ぐらいに抑えたい。 SPAなら (ローディン
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 とは完全に別系統に進化しつつある。互換があんまりない。 今対応するのは時期尚早でアーリーアダプターだけでよい
20 年代のフロントエンド - Qiita
これはなに 高円寺.dev #3 用の資料 https://koenji.connpass.com/event/160886/ フロントエンド専門じゃない人向けの、フロントエンドの最先端〜やや未来の話です このレイヤーでは Node.js を使うべき/使うと強いという部分がありますが、他言語を否定しているわけではありません。むしろ他言語でこのアーキテクチャを模倣してほしいという話です。 10 年代のフロントエンドのポストモーテム 10 年代まとめ IE が死ななかったので各種ポリフィル、メタ言語からのトランスパイルが発達。しかしモダンとレガシーの乖離が深刻に。 node と npm エコシステムの成立 仮想 DOM がフロントエンドライブラリの標準的な状態管理手法に モジュールシステム需要が ES Modules(ES2015)に結実。しかし webpack は死ねなかった。 モダンとレガ
graphql-codegen で型定義を生成する (React, Apollo, TypeScript) - Qiita
graphql-codegen で型定義を生成する (React, Apollo, TypeScript)TypeScriptReactGraphQLapollo 本記事はこのリポジトリでやったことのまとめです。 GraphQL + TypeScript への課題感 TypeScript(に限らず他の静的型付の言語) と GraphQL を使うと、型の二重定義が発生がちです。折角 GraphQL に通信規約としての型を書いているのに、それを多重定義することで、運用の面倒臭さやバグの温床になりかねない、という懸念がありました。 今回は、graphql のスキーマとクエリを書くと、サーバー向けに resolver の型定義、クライアント向けにクエリの型定義を生成し、それによってできるかぎり型安全なコードを扱うのをゴールとします。 やり方 graphql-code-generator を使います
Flowtype v0.71 で stage1 optional-chaining がサポートされた - Qiita
flow の changelog を週1ぐらいで眺めているのだが、サポートされたときいてマジかとなった Type support for the Stage 1 Optional Chaining proposal. To use this feature, set esproposal.optional_chaining=enable in your .flowconfig. 言われたとおりに、 .flowconfig に esproposal.optional_chaining=enable 追加し、 https://www.npmjs.com/package/babel-plugin-transform-optional-chaining を .babelrc に導入したが、動かない… 調べると optional-chaining は babel7 を使えということになっていたので、
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
2017末時点での React Component 設計のベストプラクティス - Qiita
どう考えているか、というのを聞かれたので、記事に起こしておきます。個人の意見です。 Prettier を使う 気づけばコードの整形を人間がやる時代は終わりました。 細かいコーディングスタイルでレビューの時間を取るぐらいだったら、一貫した自動整形ルールを適用すべきです。 人によっては細かいこだわりがあって prettier の規則が気に食わないかもしれず、僕も最初はそうでしたが、Atomで保存する度に自動整形を走らせる prettier の強烈な開発体験によって、最終的にそれらのこだわりを全て捨てることが出来ました。 生産性を求めるなら、現時点では最優先で導入すべきものです。 React.createClass を使わない v16 で削除されたのでいわずもがな。 同様に、 createClass でしか使えなかった mixin 周辺機能も丸ごと deprecated です。 「可能な限りは」
型なき世界のためのflowtype入門 - Qiita
http://qiita.com/mizchi/items/3bbb3f466a3b5011b509 で紹介したモダンJSスタックの上に、flowtype を導入して型をボトムアップに追加していくアプローチを紹介します。 なぜflowtypeか、そのゴールは 流行っているライブラリのみを組み合わせて使う場合や、バックエンドとの連携において型が十分に提供される環境なら、正直、flowtypeよりtypescriptでいいと思っています。flowtypeが力を発揮する環境は、既存のJSが大量に存在する環境や、railsなどの動的な型のフレームワーク環境で、静的な定義が抽出できない環境だと思います。 よほど品質が低いライブラリを使わないかぎり、バグはほとんど自分が記述したコードによって発生します。なので、まずは「自分が書いたコードのIFを明確にし、その静的なチェックを行なう」、というのを最初の目
Flowtype導入のための指針・実際の運用について - Qiita
このドキュメントの目的 自分は趣味でFlowをずっと使っていて、またプロダクションでも今まで3プロジェクトほどにFlowを導入した。その知見。 「Flow は便利そうだけど、怖い」「いれてみたら色々ハマったからクソ」「わからん、なにもかも…」という人に対し、自分がいままで出くわしたパターンや、聞かれた疑問について、メジャーな解法を提示する。 なぜFlowを導入するか Babel から段階的に導入することが出来る React の JSX にも推論を入れることができる 部分的に適用できる ASTがES準拠であり、ESLintなどがツールが使える(TSは独自AST) それ自身ランタイムに全く影響はないので落とすのも簡単 実際にはReactと一緒に使うのが、エコシステムもユースケースも揃っていて、一番効果を発揮するだろう。それか、小さい npm モジュールを自分で書くとき。 型のメリット/デメリッ
React on 現場 ~ あるいは Modern JavaScript on Rails ~ - Qiita
これは何 JSer.info 5周年記念イベント - connpass (2016/01/16) にて発表した資料。特に理由はないが公開するのを忘れていた。 スライドモードのリリースにあたって公開する 近況(2016/01/16) 昨年9月 Kobito for Windows => Qiita開発チーム モダンなJS(当社比)を導入しようとした モダンなJSとは(mizchi主観2016版) npm/browserifyで依存を解決 Babel/ES2015 React/Flux Testable No More jQuery plugins ※これらの基準について今回は割愛 現実(2015) CoffeeScript Sprockets / グローバル名前空間渡し Backbone JSのテストはjasmineで数件 (※request specは豊富) jQuery plugins
npmにライブラリをアップロードするときに.npmignoreで生成物を公開/制限するパターン - Qiita
やっと理解したのでメモ 何がしたいか npmパッケージを登録する時にcoffeeやtypescriptのコードをコミットせず生成したjsだけをアップロードしたい 自動生成したjsをgitで管理したくない どうやるか src/** にソース、lib/** に実体があるとする .npmignore に npm にアップロードしたくないものを書く
JavaScriptのモジュールシステムの歴史と現状 - Qiita
社内向け資料。自分が書いたコードを説明するために資料作る羽目になった。 昔のことはうろ覚えで雰囲気で書いてる部分もあるので、そこらへん勘弁。 古の時代(~2010) 前提としてJavaScriptは名前空間がwindowの一つしかない。 昔Prototype.jsがあった。もうみんな忘れたけどあの時期はプリミティブなオブジェクトのprototypeを生やしまくって、それが衝突しまくってprototype良くない的な雰囲気が生まれたり生まれなかったりした。 その反省があってか(歴史的に若干微妙な気がするが) jQueryは名前空間を一つに集約した。いわゆる jQueryPlugin は、jQueryのプロトタイプにヘルパを生やしまくっていた。グローバルを汚すのは駄目だけどjQueryの名前空間を汚すのはいいよね、ぐらいの考え。 jQuery非依存なライブラリは、「GoodParts」として、
俺のJSライブラリの世界観(2014末版) - Qiita
http://qiita.com/advent-calendar/2014/frontrend 概論 ここ近年のモダンJSは特に理由がなければcommon.jsのrequireスタイルで記述され、webpack/browserifyでビルド/読み込むことを前提にしてよい。今やビュー層を除いてブラウザとnodeのライブラリの境界は非常に曖昧である。 識者諸君においては常にどちらの環境でも読み込めるようなライブラリを提供するように心がけることを切に願う。 今日はライブラリの名前しか出さないんで各自ググるように。 立場 サーバサイド~ゲームプログラミング出身node寄りフロントエンドエンジニア このサイトのスタッフだけど他のことに手一杯でQiitaのフロントはまだそんなにいじってない すまんな 他ってなんだろうな 言語 CoffeeScript TypeScript 最近DDDっぽい構成を目指し
segmentio/dekuのコード読んで自分でも仮想DOMのdiffアルゴリズムを書いてみた - Qiita
VirtualDOM Advent Calendar 2014 - Qiitaの6日目です。 前回、チラッと紹介したdeku、どんなもんかそこまで詳しく知らなかったのでコード読んでみた。 segmentio/deku Dekuの特徴 APIはほぼReactと一緒 render/renderToString/setState/shouldUpdate 小さい 手元でビルドしたのが23kb(Reactが90kb) 公式が9kb謳ってるのは、昔の名残かな…？gzipかもしれないけど diff即生DOM操作なんでヘッドレスで動くような構造ではない duo.jsに依存して書かれてる まあsegment.io製だし デクだけにシンプル。小さいのが特徴。 アルゴリズムとしての本質はここみればわかる deku/diff.js at master · segmentio/deku dekuを参考に自分で仮想
なぜ仮想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
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
