GitHub Actions で Windows IE11 と Mac Safari を selenium-webdriver で動かす - QiitaDeleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
fly.io で React アプリケーションの SSR を行う - Qiita
import React, { Dispatch, useContext, useReducer, useState, useCallback } from "react"; import { Route, Switch, Link } from "react-router-dom"; import styled, { createGlobalStyle } from "styled-components"; import { Action, reducer, RootState } from "./reducer"; import * as actions from "./reducer"; // RootState context export const RootContext = React.createContext<RootState>(null as any); export
2017末時点での React Component 設計のベストプラクティス - Qiita
どう考えているか、というのを聞かれたので、記事に起こしておきます。個人の意見です。 Prettier を使う 気づけばコードの整形を人間がやる時代は終わりました。 細かいコーディングスタイルでレビューの時間を取るぐらいだったら、一貫した自動整形ルールを適用すべきです。 人によっては細かいこだわりがあって prettier の規則が気に食わないかもしれず、僕も最初はそうでしたが、Atomで保存する度に自動整形を走らせる prettier の強烈な開発体験によって、最終的にそれらのこだわりを全て捨てることが出来ました。 生産性を求めるなら、現時点では最優先で導入すべきものです。 React.createClass を使わない v16 で削除されたのでいわずもがな。 同様に、 createClass でしか使えなかった mixin 周辺機能も丸ごと deprecated です。 「可能な限りは」
React とGUI 設計論、あるいは新世代のホームページビルダー - Qiita
注意。実装はまだないです。思考実験的な意味合いが強いです。 持論 Reactやredux/Rxのデータモデリング手法の発達で、ツリー構造の末端に渡すまでのデータモデリングが主戦場になりつつあります。これはロジックを注入する部分と、プレゼンテーショナルなものが明確に分離されてきたことを意味します。 僕は個人的に、 GUI にまつわるものは、本来GUIで設計したい、という気持ちがあります。そう、僕が作りたいと思っているのは、悪名高きホームページビルダーです。 とはいえ、プログラミング抜きでxxxできる！というものではありません。むしろプログラミングとGUIを横断するイメージで、Unity や UnrealEngine のような開発環境を想定しています。 今やりたい理由 ブラウザの仕様が安定してきた 色々と使えるパーツが増えた JS で複雑なツールを作れるようになり、インブラウザな開発ツールが作
puppeteerでフロントエンドISUCONのためのパフォーマンス計測ツールを作りたい - Qiita
この記事は、 Recruit Engineers Advent Calendar 2017 の2日目です。 リクルートテクノロジーズで パートナーとして働いてる mizchi です。ここでの仕事は、 yosuke_furukawa が忙しくて調べられないことを、勝手に調べてくることです。 今までリクルートでやったことは Next.js, AMP, PWA, Puppeteer って感じ。今回は Puppeteer を使ったE2Eテストの自動化やパフォーマンス評価の話をします。 puppeteer とは リポジトリ名でわかりますが、GoogleChrome チームが公式に提供する Chrome の Headless Driver です。 スペルがとにかく覚えづらい クロスブラウザテスト以外にはかなり万能なツールです。E2Eテスト、スクレイピング、日々の作業の自動化、なんでもござれ。 他のブラ
最強のフロントエンドの雛形作った (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 も何も入ってない。あくまでそれ以前にやることをまとめた。 参考になるだろうけど、人によっては使わないツールも多いと思われるので、適当に削ってください。 こういうの
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
2016/05/11時点でWebAssembly関連の情報を整理してみた - Qiita
フロントエンドとしては絶対に避けて通れないWASM、そろそろエッジ環境なら試せるツールが揃ってきたということで、手を出してみた。 自分がどうしてもローレベルに弱いので、たぶん色々間違ってるんだけど、識者各位は指摘お願いします。 現在の仕様はここ https://github.com/WebAssembly/spec Chrome Canary と Firefox Beta で動作可能 WASMのゴール asm.jsに比べてサイズが小さく高速にデコード可能なバイナリフォーマット 将来的な目標として、DOMアクセスとそのGCインテグレーション これが達成されれば、ブラウザにおいて JS がファーストプライオリティな言語という状態ではなくなる とはいえ既存の資産が多いのでなくなることはないだろうが wasmのスペック自体は小さいのでおそらくブレようがないが、DOMの実装とGCは各ベンダごとに別々
型なき世界のためのflowtype入門 - Qiita
http://qiita.com/mizchi/items/3bbb3f466a3b5011b509 で紹介したモダンJSスタックの上に、flowtype を導入して型をボトムアップに追加していくアプローチを紹介します。 なぜflowtypeか、そのゴールは 流行っているライブラリのみを組み合わせて使う場合や、バックエンドとの連携において型が十分に提供される環境なら、正直、flowtypeよりtypescriptでいいと思っています。flowtypeが力を発揮する環境は、既存のJSが大量に存在する環境や、railsなどの動的な型のフレームワーク環境で、静的な定義が抽出できない環境だと思います。 よほど品質が低いライブラリを使わないかぎり、バグはほとんど自分が記述したコードによって発生します。なので、まずは「自分が書いたコードのIFを明確にし、その静的なチェックを行なう」、というのを最初の目
春からはじめるモダンJavaScript / ES2015 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 春ですね！人の配置がリファクタリングされ、コードもリファクタリングの季節です。 では僕がここでモダンなJavaScriptとES2015の利点を語る役をやるので、みなさんはチームを説得する役をやってください。 JavaScriptの歴史 まず最初にJavaScriptの歴史を踏まえることで、今学ぶべきものとその理由を確認しましょう。 なぜ2016年の記事でES2016ではなく、ES2015なのか、と疑問に思った方もいるかもしれません。それは、ES2015がただの年次アップデートではなく、これから始まる毎年のメジャーバージョンアップの起点
EventEmitterバケツリレースタイル/フレームワークなしで小さくFluxする - Qiita
想定しているシチュエーション 非SPA環境で個別にマウントされるコンポーネントがそれぞれで小さくFluxするような環境。 SPAガッツリ組むのでないなら、Fluxフレームワークは不要だと思っていて、とは言えオレオレ構成も行き過ぎると害になる。 その辺のバランスをとって、次のような構成がいいのではないか、と考えてみた。 考え方 コンテナがEventEmitterを1つ保持する コンテナはEventEmitterの各種イベントをListenする コンテナはpropsとstateを区別して扱い、stateを更新する コンテナはコンポーネントを一つだけ描画する コンポーネントはpropsとして渡されたEventEmitterを発火させる コンポーネントはEventEmitterをListenしない コンポーネントはpropsのみ扱う コード // src/components/header.js
Nightmare v2(Electron) でブラウザ上でES2015のコードを個別にrequireしてユニットテストを書く - Qiita
'use strict'; // nightmare const Nightmare = require('nightmare'); const path = require('path'); const TEST_HTML_PATH = "file://" + path.join(__dirname, "test.html"); // create global.browser = null; let startBrowser = function * (){ global.browser = Nightmare({ show: false, nodeIntegration: true }); yield browser .goto(TEST_HTML_PATH) .wait('body') .evaluate(() => { require("babel-register"); //
Reactサブセット実装の preact で、ライフゲームのアニメーション書いて使い方を確認した
厳密なサブセットかは要確認な気がするが、まあそういうコンセプトのライブラリがある。 で、使ってみた。 preact とは reactのサブセット実装。reactと比較してかなり小さい(圧縮して3kb)。contextとかpropTypesとかはない。いらないと思う。 reactとの互換をもたせるレイヤーは本体を小さくするために外部パッケージに切り出されている。 https://github.com/developit/preact-compat コード量が少ないので、迷ったら元のコード読めるという安心感がある。 個人的にReactは過剰な抽象化の迷宮だと思っていて、あんまり読みたくない。 最初に ライフゲームのアニメーションしたかったわけで、ライフゲームを書きたかったわけではないので、ライフゲームのロジック部分はnpmから適当に持ってきた。 動いてるコードはここ http://mizchi
babel-plugin-typecheck を使って flowtype 文法で書かれたJSをランタイムチェックする - Qiita
https://github.com/codemix/babel-plugin-typecheck を使ってみた。 これは何 babelでflowtypeの構文を使って型エラーのランタイムチェックを行う。静的解析ではない。（自分がドキュメントから見落としてるだけで静的解析を行う方法がある？） 興味を持った理由 既存コードに対してtypescriptを導入するのは大変 flowtypeは既存コードからの乗り換えは簡単だが、型チェッカの挙動が未だに不審 コード上のドキュメントとしての型 + ランタイムチェックというアプローチなら十分では ESdoc等で型を書いてもあくまでドキュメント上の指定だが、flow syntax とこれなら実行可能という点が大きい。最悪動かなくてもランタイムチェックを外せば良い。型指定はドキュメントとして残る。 Install すでにbabel環境があることを想定
テストがない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
app/assets/javascripts以下のJSを全てcommonjsのrequireに書き換える - Qiita
仕事でgulpを使って僕がよくいじる一部のjsを高速でビルドできるようにしてみたのだが、JSをいじらない人の手元でなにかと差分がおかしくなったり、ビルドするタイミングを伝えないことで問題起きたり、その為に呼ばれて治すのがとにかくめんどくさかったため、思い切ってすべてのビルド工程をbrowserify_railsとbrowserify-incrementalと(そのtransform)に押し込んで、gulpを排除してみた。 そんで、browserify_rails は導入しただけだと嬉しさがあまりないので、スクリプトを書いて一気にcommonjsに置き換えることにした。 browserify_rails に関してはhokacchaさんの記事が便利。 モダンJavaScript開発環境 on Rails - クックパッド開発者ブログ 脇道にそれるが、僕は最初、これをbrowserifyを模した
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Next.js を Firebase hosting で動かしてSSRする - Qiita
Expo ではじめる ReactNative 開発環境 - Qiita
JSのコードの自動整形に Prettier が便利だったので、�eslint とAtomから使えるように設定した - Qiita
async await に書き換えて、Promiseと 同期による例外の区別でハマった - Qiita
