GitHub - petehunt/react-howto: Your guide to the (sometimes overwhelming!) React ecosystem.
If you’re new to React (or frontend in general) you may find the ecosystem confusing. There are a few reasons for this. React has historically been targeted at early-adopters and experts Facebook only open-sources what it actually uses, so it doesn’t focus on tooling for smaller-than-Facebook projects There’s a lot of bad marketing masquerading as React guides Throughout this document, I’ll assume
Managing Side Effects In React + Redux Using Sagas
Redux is a Flux-like framework that has exploded in popularity within the React community. It reduces complexity by enforcing a unidirectional data flow, the use of single state atom, and pure reduce functions for state updates. For me, there has always been one thorn in the React+Flux setup, which is that more complicated processes involving coordination of action creators and side-effects are ha
Day 2: Testing React Applications
In this article we’re going to take a look at how we can test React applications. Typically applications built with a frontend framework are difficult to test; it’s tricky to emulate the actions of your users in testing, despite it being one of the most important things to test. If your tests can’t emulate what a user might do, it’s going to be tricky to have full confidence that your application
テストがない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
GitHub - unit-coverage/unit-coverage: Precise, powerful and fast JS Coverage tool
Coverage toolkit designed to collect coverage information separately for each test. Unlike most coverage tools, unit-coverage keeps connection between source file and its test file. For each source file coverage is beeing computed only when its tests are running. This ensures you have correct test coverage for each file beeing tested. For example you have file source.js and its test: source.test.j
Lerna を使って、 Babel や React が採用している monorepo を試してみる - Qiita
monorepo とは 複数の npm package を 単一の git repository で管理すること 例えば Babel では、 100 以上の npm package が単一の git repository で管理されている https://github.com/babel/babel/tree/master/packages package 毎に repository を作る場合と比較した Pros & Cons Babel の repository のドキュメントから抜粋 Pros: lint, build, test, release のプロセスを共通化できる package をまたがった修正が容易になる issue 管理を一元化できる 開発環境の構築が簡単になる テストも package をまたいで実行でき、複数 package が絡む不具合の検知が容易になる Con
JSをbrowserifyでビルドし、ライセンスコメントを適切に残す - $shibayu36->blog;
最近JSを利用するときは、依存モジュールはnpmを利用し、ES6やTypeScriptの仕様を開発には使った上で、ブラウザ用にコンパイルして配信するようになってきている。また同時にネットワークの負荷を下げるためにminifyを行う場合もある。 minifyはライセンスが絡むと少し難しい。例えばコメントを全て削除してしまうとライセンスコメントまで消えてしまう。この問題にはみんながそれぞれの手法で対処しているみたい。1年ほど前の記事でクライアントサイドJavaScriptのライセンス管理 | エンジニアブログ | GREE Engineering というものがあり、いろんなJSのコンパイルのためのライブラリが独自でライセンスの形式を決めていて、それにマッチしないものは消えてしまう、みたいな辛いことが起きてそうだった。 そこで今回は自分の勉強も兼ねて、npmのモジュールを含めてブラウザ用にコンパ
AudioWorker を試してみる - Qiita
2016.09.08 追記 AudioWorkerは編纂中の仕様から削除されました。Web Audio API先生の次回作AudioWorkletにご期待ください！！ Web Audio API には ScriptProcessorNode という、JavaScript で信号処理を記述するための部品があります。Web Audio API で用意されている部品の組み合わせではやりようがない処理をしたいときに重宝するのですが、最新のドラフト仕様では DEPRECATED となっていて将来的には廃止されるようです。 そして廃止される ScriptProcessorNode に変わって提案されているのが AudioWorker という仕組みで、ScriptProcessorNode との大きな違いとしてメインスレッドで行っていた信号処理をワーカースレッドで行うようになります。また、任意の Aud
Mocha + Chai.js unit testing for ES6 with Istanbul code coverage
Testing is very important for finding bugs, verifying the functionality and improving the general stability of a piece of software. Almost all (if not all) developers test their code in some way. One way to test would be to manually run the program and try out all the functions to see if everything is working as expected. Another (and better) way is to write automated tests that are run every time
Managing the private data of ES6 classes
This blog post explains four approaches for managing private data for ES6 classes: Keeping private data in the environment of a class constructor Marking private properties via a naming convention (e.g. a prefixed underscore) Keeping private data in WeakMaps Using symbols as keys for private properties Approaches #1 and #2 were already common in ES5, for constructors. Approaches #3 and #4 are new
The poor, misunderstood innerText — Perfection Kills
Few things are as misunderstood and misused on the web as innerText property. That quirky, non-standard way of element's text retrieval, [introduced by Internet Explorer](https://msdn.microsoft.com/en-us/library/ie/ms533899%28v=vs.85%29.aspx) and later "copied" by both WebKit/Blink and Opera for web-compatibility reasons. It's usually seen in combination with textContent — as a cross-browser way o
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - goessner/g2: A 2d graphics command queue micro-library.
AST explorer
GitHub - evancz/elm-architecture-tutorial: How to create modular Elm code that scales nicely with your app
O'Reilly Media - Technology and Business Training
GitHub - dougwilson/nodejs-depd: Deprecate all the things
exploring-async/exploring_async.md at master · thalesmello/exploring-async
GitHub - narirou/jconv: Pure-JavaScript converter for Japanese character encodings.
GitHub - davglass/lcov-parse: Simple LCOV file parser
GitHub - niwaringo/moji: 半角全角変換ライブラリ
