lodash やめ方 - Qiita
みなさん、 lodash で消耗してますか？ 私は消耗しています。 なぜ lodash で消耗するかというと、とにかく思考停止でインストールされ、 node_modules 下で大量に重複します。サイズが大きいlodashが複数バンドルされてビルドされると、重篤なパフォーマンス上の問題を引き起こします。 lodash には実装上の問題もあり、異様に丁寧に、そして富豪的に作られており、その結果ビルドサイズが無駄に大きいです。丁寧に作られて入るのですが、現代のフロントエンド水準や一般的なポリフィルと噛み合っていません。というわけで、常々やめたいと思っています。 ちゃんとES201xを追ってる人からすると、ほとんどの lodash のメソッドは不要に見えるはずです。本エントリは、思考停止で lodash で実装しようとする人に、ちょっと考え直しては？ と投げつける用の記事になります。 現代におい
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@
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
Firebase Functions 上に GraphQL サーバーを実装する - Qiita
この記事は１ヶ月後の自分のネタ切れにつきアドベントカレンダーの記事ということになりました Why SPA や モバイルアプリ だととりあえず Firebase Functions に graphql エンドポイントを一個マウントして金で殴ってスケールさせるところからスタートするのがいいと思います。金の弾丸というやつです。 この環境は、query と mutation は実装できるけど、 Cloud Functions のライフサイクルの都合上、 wsバックエンドのsubscription は実装できません。そこは Firestore とか使ってなんとかできるんでいいかって感じ。 自分の用途としては、Firestore の write系は一律禁止、 read 系は firebase.rules で制御しつつ subscribe して、リアルタイムではない複雑な問い合わせやロジック検証付きの副
sourcemap を無効化して webpacker の production build を 2000% 速くする - Qiita
TL;DR プロダクションで sourcemap が有効化されていたので、関連オプションを切って回ったら 2000% 高速化した。 問題 NODE_ENV=production bundle exec rake webpacker:compile が致命的に遅かった。 エントリーポイントが17個でビルド時間が合計680s という有様で、プロダクションとはいえ デプロイ を11分遅くさせるのは、ビジネス的に致命的な感じだった。 調査 さしあたり、いつもの経験則で uglify の mangle オプションが遅いんだろう、と思って、webpacker のソースの設定を見に行ったら、うん？？？？となる設定をみつけた。 this.plugins.set('UglifyJs', new webpack.optimize.UglifyJsPlugin({ sourceMap: true, compre
flowtype で typescript の *.d.ts のように型定義 *.js.flowを出力する - Qiita
やりたいこと flowで書かれた npmパッケージを作成する時、webpack/browserifyでバンドルされるのを想定してes5水準までコンパイルしつつ、かつflowの型定義も外部ファイルに頼らず提供したい .babelrc package.json src/ # ソース index.js index.test.js lib/ # コンパイル済み index.js index.js.flow *.test.js はスキップしつつ、コンパイル済みの index.js と index.js.flow を作成したい 方法 babelの設定は省略。yarnを使ってるけどnpmに置き換えれば良いとして、yarn add babel-cli flow-bin -D を前提として { ... 略 "scripts": { "build:flow-gen": "flow gen-flow-files
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 の機能 リソースの先読み
async await に書き換えて、Promiseと 同期による例外の区別でハマった - Qiita
// async function の中 try { load().then(data => { console.log(data) }).catch(e => { // ... }) } catch (e) { // ... 例外処理 } わかりやすく簡単にしている。実際にはもっと複雑なコードだった。Promise にすれば try と catch を一本化して綺麗にできるやん！と思っていた。最初は。 書き換えた // async function の中 try { const data = await load() console.log(data) } catch (e) { // ... 例外処理 } catch が一個減ってリファクタできたーと思っていた。確かに異なる例外処理のブロックが減ってしまっていたが、どうせ何かしらのデッドコードだろと思って消してしまった。 注: 意味的に
Flowtype導入のための指針・実際の運用について - Qiita
このドキュメントの目的 自分は趣味でFlowをずっと使っていて、またプロダクションでも今まで3プロジェクトほどにFlowを導入した。その知見。 「Flow は便利そうだけど、怖い」「いれてみたら色々ハマったからクソ」「わからん、なにもかも…」という人に対し、自分がいままで出くわしたパターンや、聞かれた疑問について、メジャーな解法を提示する。 なぜFlowを導入するか Babel から段階的に導入することが出来る React の JSX にも推論を入れることができる 部分的に適用できる ASTがES準拠であり、ESLintなどがツールが使える(TSは独自AST) それ自身ランタイムに全く影響はないので落とすのも簡単 実際にはReactと一緒に使うのが、エコシステムもユースケースも揃っていて、一番効果を発揮するだろう。それか、小さい npm モジュールを自分で書くとき。 型のメリット/デメリッ
Yarnファーストインプレッション - Qiita
Yarn とは 名前から yet another ... な雰囲気を漂わせてますが、 npm互換 です。(追記: 正確にはnpmの生成するpackage.jsonと互換とのことだった)。各所から node連中はまたツール増やしやがって！という雰囲気を感じるので、ここは明確にした方がいい。(techcrunchの記事とかそういう印象を与える書き方になってる) npm install 時のディレクトリ配置への介入 npm install 時のより賢いローカルキャッシュ yarn.lock ファイルでバージョン固定 yarn 環境下で yarn add, yarn install などを行った場合、 yarn.lock と package.json に同時に書き込み、 その環境で生成されたファイルは yarn なしでも動きます。つまり、yarn はより厳密に npm のバージョンを固定したい人向
2016/05/11時点でWebAssembly関連の情報を整理してみた - Qiita
フロントエンドとしては絶対に避けて通れないWASM、そろそろエッジ環境なら試せるツールが揃ってきたということで、手を出してみた。 自分がどうしてもローレベルに弱いので、たぶん色々間違ってるんだけど、識者各位は指摘お願いします。 現在の仕様はここ https://github.com/WebAssembly/spec Chrome Canary と Firefox Beta で動作可能 WASMのゴール asm.jsに比べてサイズが小さく高速にデコード可能なバイナリフォーマット 将来的な目標として、DOMアクセスとそのGCインテグレーション これが達成されれば、ブラウザにおいて JS がファーストプライオリティな言語という状態ではなくなる とはいえ既存の資産が多いのでなくなることはないだろうが wasmのスペック自体は小さいのでおそらくブレようがないが、DOMの実装とGCは各ベンダごとに別々
jQueryで楽になる部分、楽にならない部分、顧客が本当に必要だったもの - Qiita
俺も昔はお前のような jQueryスパゲッティジェネレーターだったのだが、膝にReactを受けてしまってな… 基本的な方針 とくにライブラリ設計者において、小さなモジュールを単機能で分割する以上、ライブラリ設計者は可能な限り依存を減らすことを求められます。node環境ならdependency hellの回避のため、フロントエンド環境ならファイルサイズを減らすためです。 ライブラリ設計者ならずともコードのポータビリティを維持するため、できるだけライブラリに依存しないコードを書くのが望ましいです。 Githubみてる限り、最近書かれるJSのライブラリの多くはjQuery非依存です。ユーザーから見る限りは、jQueryElement渡すかHTMLElement使うかぐらいの違いですけどね。 また、Angular, React等のSPAをスクラッチで設計する場合、気づいたらjQueryを使っていな
なぜ仮想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
CoffeeScriptが1.9でgenerator構文をサポート - Qiita
追記: タイトル変更。v1.9 でリリースされました(2015/01/30) ES6以降にやや慎重な対応をみせるcoffeescriptですが、やっとgenerator構文がサポートされたようです。 Add yield support · Issue #3073 · jashkenas/coffeescript · GitHub 色々と構文の候補がありましたが、関数ブロックの中にyieldキーワードが存在する場合は自動的にジェネレーター関数になるような仕様に落ち着いたみたいです。 generator概要(知ってる人は読み飛ばしてよい) 関数ブロックの中でyieldを使うと関数がgenerator化されます。yield化された関数は実行されるとgeneratorを返し、 generatorは.next()を叩くと次のyieldキーワードで渡された値が取得できます。もう一度叩くとその位置から次
gulpでbrowserify使ってcoffee-scriptの監視とコンパイル - Qiita
まずnpmから必要な物をいれる。gulpで browserify/coffeeify を使ってビルドする場合、coffee-script も必要になる。 $ mkdir proj-path; cd proj-path $ npm init $ npm install --save-dev gulp gulp-browserify gulp-watch gulp-plumber gulp-rename coffeeify coffee-script gulp-rename リネームタスク gulp-watch 監視タスク gilp-plumber タスクの実行に失敗してもgulpを終了させないパイプ(watchでビルド失敗時に終了させない) gulp-browserify browserify gulpfile.coffee gulp = require 'gulp' browserify
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
JSのコードの自動整形に Prettier が便利だったので、�eslint とAtomから使えるように設定した - Qiita