lodash やめ方 - Qiita
みなさん、 lodash で消耗してますか？ 私は消耗しています。 なぜ lodash で消耗するかというと、とにかく思考停止でインストールされ、 node_modules 下で大量に重複します。サイズが大きいlodashが複数バンドルされてビルドされると、重篤なパフォーマンス上の問題を引き起こします。 lodash には実装上の問題もあり、異様に丁寧に、そして富豪的に作られており、その結果ビルドサイズが無駄に大きいです。丁寧に作られて入るのですが、現代のフロントエンド水準や一般的なポリフィルと噛み合っていません。というわけで、常々やめたいと思っています。 ちゃんとES201xを追ってる人からすると、ほとんどの lodash のメソッドは不要に見えるはずです。本エントリは、思考停止で lodash で実装しようとする人に、ちょっと考え直しては？ と投げつける用の記事になります。 現代におい
react-apollo と next.js を使った最速 GraphQLアプリケーション(+モックサーバー)実装 - Qiita
react-apollo を試しながらガチャガチャやっていると、モックサーバーなどを含め、なかなか体験が良かったので、紹介します。 こっちも参照 世のフロントエンドエンジニアにApollo Clientを布教したい - Qiita 今回書くコードの動いてる例は https://github.com/mizchi-sandbox/graphql-playground を参考にしてください。 git clone して yarn install; yarn start で動くはず。 ゴール 最終的にこんな感じのクライアント実装(next.js)が動くようになります。 import React from "react"; import { Query } from "react-apollo"; import gql from "graphql-tag"; const GET_USER = gql
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(...)
CSS Grid Layout Generator でレイアウト用CSSを生成する - Qiita
最近作ってたものの紹介です。だいたいできたんで公開します。 これは何 ワークフローによりますが、CSS書く際に最初に決めるのは大まかなレイアウト構成だと思います。 で、最近はコンポーネント志向でReactComponentとか書いていくと、各領域が何を占めるかみたいな設計に便利なのが、CSS Grid Layout ですね。たぶんそう。 これからのグリッドレイアウト 第1回 Grid Layout Moduleの概要 CSS Grid だと何がいいかというと、やたらプラガブルなんで、機械的に吐き出しても汚くならない点です。というわけで作りました。 レイアウト設計、毎度結構だるくて、僕みたいなあんまCSS書きたがらないエンジニアだと、GUIでポチポチやって、それっぽいCSSを吐き出してくれるといいな、なんて思ったりしていました。 ただ、自分はこれを作る過程で Grid Layout に対して
React とGUI 設計論、あるいは新世代のホームページビルダー - Qiita
注意。実装はまだないです。思考実験的な意味合いが強いです。 持論 Reactやredux/Rxのデータモデリング手法の発達で、ツリー構造の末端に渡すまでのデータモデリングが主戦場になりつつあります。これはロジックを注入する部分と、プレゼンテーショナルなものが明確に分離されてきたことを意味します。 僕は個人的に、 GUI にまつわるものは、本来GUIで設計したい、という気持ちがあります。そう、僕が作りたいと思っているのは、悪名高きホームページビルダーです。 とはいえ、プログラミング抜きでxxxできる！というものではありません。むしろプログラミングとGUIを横断するイメージで、Unity や UnrealEngine のような開発環境を想定しています。 今やりたい理由 ブラウザの仕様が安定してきた 色々と使えるパーツが増えた JS で複雑なツールを作れるようになり、インブラウザな開発ツールが作
Qiita beta版のフロントエンドパフォーマンス改善案 - Qiita
ふとログインすると beta 版UIってのが使えた。完全に dev.to 意識してて笑った。 実際には自分が残してきたロードマップや、Component が使われているのであろうのがわかって、そうそうこれがやりたかったんだよって感じで、とはいえまだ改善点がたくさんって、今の中の人達もわかってると思うけど、元中の人として dev.to ぐらいやるにはどうすればいいってのを残しておきます。 わかる変更点 CSSの脱bootstrap色が強くなった トップ画面が、ユーザーごとのカスタムフィードから beta版 の人気の投稿が主になった 元々そういう目的で企画を起こした記憶がある… フレンドフィードもうあんまり使われてないよね クエリが重いフレンドフィードより、静的にキャッシュできるランキングがトップにあるのはチューニングしやすい やや無理難題だったり、中の都合も察してるけど、できるだけ目視とDe
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 の機能 リソースの先読み
Expo ではじめる ReactNative 開発環境 - Qiita
某所で調べた資料 Expo とは ReactNative上で、JS のみで ios/android アプリを作る開発/ビルド環境。ネイティブプラグインが使えないという縛りを受け入れることで、アプリをQRコード経由で簡単に公開したり、共有したりできる。 ios/android のコードを書かなくていい、というか一切書けない。 参考: expo.ioを使ってリアルタイムにReact Nativeアプリを開発する http://amagitakayosi.hatenablog.com/entry/2017/04/18/120000 Hello World $ npm install -g exp $ exp init my-native-app $ exp start # 開発用ビルドの開始 $ exp build:ios # 本番用ビルド
Chrome M60 で Native ES Modules + ServiceWorker を試して未来へのマイグレーションを見積もる - Qiita
Chrome M60 で Native ES Modules + ServiceWorker を試して未来へのマイグレーションを見積もるServiceWorkerbabeles2015ESModules 目的 Chrome M60(Canary) でフラグ付きで ES 2015 の ES Modules が動くようになったので、試す。 ServiceWorker と Babel 前提で、エッジな構成で今のバンドル環境を無理矢理シミュレートしてみて、今との比較で現実的なマイグレーションパスを探しておくことにした。 成果物 uupaaさんの WebApp2 をスケルトンとしてお借りしました。 なにができるか まるで browserify/webpack でビルドしてるかのようにこのコードが動く。ブラウザ上だけど babel も動く。 /* @flow */ import { combineRe
Flowtype導入のための指針・実際の運用について - Qiita
このドキュメントの目的 自分は趣味でFlowをずっと使っていて、またプロダクションでも今まで3プロジェクトほどにFlowを導入した。その知見。 「Flow は便利そうだけど、怖い」「いれてみたら色々ハマったからクソ」「わからん、なにもかも…」という人に対し、自分がいままで出くわしたパターンや、聞かれた疑問について、メジャーな解法を提示する。 なぜFlowを導入するか Babel から段階的に導入することが出来る React の JSX にも推論を入れることができる 部分的に適用できる ASTがES準拠であり、ESLintなどがツールが使える(TSは独自AST) それ自身ランタイムに全く影響はないので落とすのも簡単 実際にはReactと一緒に使うのが、エコシステムもユースケースも揃っていて、一番効果を発揮するだろう。それか、小さい npm モジュールを自分で書くとき。 型のメリット/デメリッ
kobito-oss のソースの読み方 - Qiita
メインの開発者として、備忘録を残しておく。 どんなものか試したい人は、 https://mizchi.github.io/kobito-oss/ で、IndexedDBの許す5MBぐらいまでは試せる。 一応言っておくと、これは僕が退職するんでOSS化ってわけではなく、元々あった計画の前倒しです。時期が早まったのはある。 以下、どのようにコードを読むか。 念頭に置くこと 2年前 の技術選定のスタック Mac版Kobitoと仕様が違う。Kobitoと同期しない、Inboxという仮グループがある。 mizchi/arda electron 以前の atom-shell 時代の互換コードが一部残ってる 細々とバグ対応はしつつ、あんまり依存パッケージのメンテ出来てなかった 公開にあたって、個別のタスクの綺麗さより、ビルドできるの優先した とりあえず yarn で固定して yarn upgrade-i
facebook の Reason という言語を調べていた - Qiita
また facebook 製の名前空間を考慮しないシリーズが増えていた。半年ぐらい前から存在は知られていたリポジトリだけど、最近ドキュメントが新しく、わかりやすくなっていた。https://facebook.github.io/reason/ Approachable syntax. Powerful, automatic source code formatting. Adopt incrementally with JavaScript/C interop. Ahead-of-time compilation to assembly - without a language level VM. Rapidly develop and share projects. Why OCaml?OCaml is a great tool for writing highly expressive,
「後付の型システム」の活用についてFlowtypeとReduxから考える - Qiita
FlowtypeやTypeScriptは静的解析によって事前に型違反を検知することができる。JavaScriptは動的型付けの言語であり、本来はランタイムにしか型が出現しない。 FlowtypeとTypeScript、ともに「それ自身がランタイムではない」というのが特徴であり、一種のLintツールだと言うことができる。ランタイムではないがゆえに、嘘の事前条件を与えることでそれらを騙すことができるし、自らに有利な制約を追加できるという柔軟性を持つ。 JavaScriptの現実においての型 例を出そう。 type MyUtil = { foo(v: string): number; }; const util: MyUtil = new HogeUtil(); util.foo(1) //=> type error HogeUtil は何かしらのユーティリティ関数の詰め合わせだが、fooにしか
最強のフロントエンドの雛形作った (2016/12/31) - Qiita
yarn とりあえず yarn install と yarn start だけで動く npm(yarn) scripts babel/webpack での多段ビルド build:js はChromeでだけで動くビルドを吐く（デバッグを容易にするため） build:js:production はIE11+ ava/nyc/istanbul でテストとカバレッジ postcssでCSSのビルド uglify-js/csswring で圧縮 CircleCI eslint, flow, ava release ブランチに push で gh-pages にデプロイ ## やってないこと React も Angular も jQuery も何も入ってない。あくまでそれ以前にやることをまとめた。 参考になるだろうけど、人によっては使わないツールも多いと思われるので、適当に削ってください。 こういうの
WebSocket と ActionCable - Qiita
序 Rails5 Meetup 発表資料 はじめに 学生の頃に Socket.IO でゲームを作ってた Rails は業務でコントローラに API 生やす程度 rspec が全然わからん 無茶振り yuku 「mizchi なら ActionCableでなんか作れるでしょ」 なんか作った 今日の発表内容 WebSocket の現状 ActionCable 既存機能のRails5の拡張については @takashi に任せる 1. WebSocket WebSocketとは Webブラウザで扱えるTCP Socket抽象 HTTP1.1と比べて並列/高頻度イベントの効率が良い プッシュ配信 今までWebSocket が使えなかった背景 昔話 未対応ブラウザが多すぎて、フォールバック必要 まともな Fallback は、ほぼ Socket.IO の特権 ロードバランサが辛い 二度目以降のリクエス
QiitaとMarkdownとコンテンツオーサリング - Qiita
はじめに SIGPX: Special Interest Group on Programming Experience 第二回 (2016年8月7日) での発表資料 今日話す内容 Qiitaでのコンテンツオーサリング Qiita の Markdown について、泥臭い感じで(アカデミックな会なので) Markdownという切り口で、標準化、そのレンダリング、オーサリング、ASTなどについて Markdown の仕様 HTMLに変換されるマークアップ言語の実装。またはその仕様。 Github の躍進とともにメジャーに 同種のマークアップ言語として textile, はてな記法など Markdownの起源 オリジナル実装は John Gruber の markdown.pl というPerl スクリプト(2004) Markdown - Wikipedia, the free encyclop
jQueryで楽になる部分、楽にならない部分、顧客が本当に必要だったもの - Qiita
俺も昔はお前のような jQueryスパゲッティジェネレーターだったのだが、膝にReactを受けてしまってな… 基本的な方針 とくにライブラリ設計者において、小さなモジュールを単機能で分割する以上、ライブラリ設計者は可能な限り依存を減らすことを求められます。node環境ならdependency hellの回避のため、フロントエンド環境ならファイルサイズを減らすためです。 ライブラリ設計者ならずともコードのポータビリティを維持するため、できるだけライブラリに依存しないコードを書くのが望ましいです。 Githubみてる限り、最近書かれるJSのライブラリの多くはjQuery非依存です。ユーザーから見る限りは、jQueryElement渡すかHTMLElement使うかぐらいの違いですけどね。 また、Angular, React等のSPAをスクラッチで設計する場合、気づいたらjQueryを使っていな
春からはじめるモダンJavaScript / ES2015 - Qiita
春ですね！人の配置がリファクタリングされ、コードもリファクタリングの季節です。 では僕がここでモダンなJavaScriptとES2015の利点を語る役をやるので、みなさんはチームを説得する役をやってください。 JavaScriptの歴史 まず最初にJavaScriptの歴史を踏まえることで、今学ぶべきものとその理由を確認しましょう。 なぜ2016年の記事でES2016ではなく、ES2015なのか、と疑問に思った方もいるかもしれません。それは、ES2015がただの年次アップデートではなく、これから始まる毎年のメジャーバージョンアップの起点となるバージョンであり、またES5から飛躍的に仕様が増えたバージョンであるからです。 簡単に(雑な)歴史を紹介します。 ブレンダン・アイクによってNetScapeに実装/搭載された古の時代〜IE6 (1996~2005) ES3: 一時はシェア7割を誇ったレ
テストがないJS環境にモダンなテスト環境を導入していく - Qiita
Qiita:Teamに投げた社内ドキュメントだったけど、特に問題ないのでQiitaにも投げる。 前提として browserify-rails とbabelify が導入されている状況を想定してる。 基本方針 新規コードはES2015で書く 本番はbrowserify(-rails)でコンパイルする。 単体テストは node 環境下で走らせる テスト環境下では jsdom で window, document をモックする 単体テストでは ブラウザ特有の挙動はテストしない 裏側の環境(browserifyやspec-helper)は難しくして良いが、利用者からみえる範囲は複雑にしない(npm install; npm testで走る) Universal JavaScript に寄せることでコードのポータビリティを上げる 事前準備 browserify-railsを導入する。 .babelr
今一番JSで熱いゲームエンジン、RPGツクールMVのランタイムコードを読んでみた - Qiita
一昔前にCanvasが実用段階になった頃、JSのゲームエンジンが大量に出てきたことがありました。それらは大抵DOM/CanvasのFallbackを持っていたのですが、今現在の状況は、実際には非効率なメモリ消費やモバイルのブラウザのフラグメント化で実用に足るものがなかった、という辛い現状があります。 そんな中pixi.jsという描画ライブラリが台頭してきました。このエンジンは webglとcanvasの fallbackを持ち、(いくらかのバグはありつつも)DOMを切ったことで現実的なパフォーマンスの課題をクリアできるのでは？という期待感が高まっています。 Pixi.js - 2D webGL renderer with canvas fallback http://www.pixijs.com/ そして 2015年、RPGツクールMVが発表され、ブラウザ吐き出し対応がアナウンスされました
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
