JavaScript Advent Calendar 2017 - Qiitaの第一日目です。JavaScriptにおいてメタプログラミングを用いて、エンジニアリングにおける邪悪と闘うという趣旨の記事です。 秋のJavaScript祭 in mixi 2017 - Javascript祭りでこれからのメタプログラミングJavaScriptの正義を語ろうという発表をしてきました。この記事はそれをベースにしています。 技術書典3で頒布した簡単JavaScript AST入門という同人誌ですが、どうも電子版を求める声が多いので、簡単JavaScript AST入門 - 東京ラビットハウス - BOOTH で電子版を販売しています。 結論から メタプログラミングを活用すればこの三つを達成できます。 コーディングタイムコンパイルという新しい概念・技術 暖かみ溢れる手作業を根絶 生産性を向上して、相対

idやclassを使ってテストを書くのは、もはやアンチパターンである 上記の記事を書いたところ、様々な反応があり非常に勉強になりました。 中でも気になったのが、class名に規約を設け、test-というプレフィックスを付けるものです。 個人的には、カスタムデータ属性の方が分離する際の見通しが良く、またCSSinJSにも適用できるのでこちらを推しますが、チーム内で共通の理解がある場合は、クラス名で制約を付けるのは良い解決作だと思います😆 さらに言えば、この問題の本質は、いかにチーム内で同意が得られるかに尽きます(data-testを書いたところで共通認識がなければ意味がないですから) さて、class名のよるtest-プレフィックスについて、ちょっと見たところプロダクション時に取り除くプラグインはないようでした。 なのでちょっと作ってみました。 akameco/babel-plugin-r

いきなり結論を書くと、idやclassはスタイルのためのものなので、テストでそれを使うのはやめましょう。そして、カスタムデータ属性を使いましょう。(idやclassはスタイルのためだけではないという意見はごもっともです！しかし、主にとしてスタイルに使われるということでご了承頂いて以下の駄文に付き合って頂けると幸いです🙇) 先に断っておくと主にreactについての話で、JSXを前提とします。(手法はReactに限りませんが理由は後述) 2020/03/23 追記 この記事は1年以上前に書かれた記事なのでテストフレームワークとしてenzymeを使っていますが、現時点ではTesting Libraryの使用をオススメします。data-testid に対応するクエリを備えています。 React Testing Library · Testing Library はじめに ご存知の通り、ロジックと

ツイッターが英語で280文字書けるようになりました🎉 つまり、ツイッター上でコードを書くのが現実的になったということですね。 せっかくなので、ツイートをライブラリとして使ってみましょう。適当に呟いて、import hello from 'twitter:あなたのツイート'と書いたら、Babelをつかってツイートをコンパイルして実行です。 How to Use babel-plugin-twitterをインストールして、create-babelrcで.babelrcを生成します。 $ yarn add --dev babel-{cli,preset-env,plugin-twitter} $ npx create-babelrc -o Created .babelrc { presets: [ 'env' ], plugins: [ 'twitter' ] }

リーダーと呼びましたが、いわばアンテナアプリ側です。複数のSSまとめサイトの SS リンクリストを表示します。 このアプリの一つ目の特徴は検索です。作品タグ + キャラ名で絞り込み、検索クエリをタブ化して保存できます。 もう一つの特徴は複数のサイトをあつかっていながらSSの重複がないことです。タイトルをある程度正規化して集約しています。 データは Rails で実装した API からとってきています。記事データは SS アンテナサイトの RSS を収集しています。SSをRSSで非SSRです。 実はこのアプリのコアはサーバーサイドで、収集やタグ整理、管理の自動化に力を入れています。 React Native で作っていた個人開発アプリを PWA に移行しました。(1から) 作っているものが Native である必要がないこと、アプリストア管理やリリース準備などの手間を感じていたこと、デバッグ

グローバルからコンポーネントベースのid管理へ サービスを海外展開したい場合、国際化対応を行う必要性があります。これをi18n対応と呼びます。Reactでフロントエンドを構築する場合、i18nのための多くのライブラリがありますが、ダウンロード数的にyahoo製のreact-intl が最も使われているライブラリです。react-intlを実際に使っている例としては、スター15000を超えるReactボイラープレートであるreact-boilerplate やSNSの マストドンがあります。 react-boilerplate/react-boilerplate: A highly scalable, offline-first foundation with the best developer experience and a focus on performance and best

なぜreducerのテストが重要か？ flow環境で型によって返るStateが担保されていたとしても、依然としてreducerのテストは重要です。 簡単な例をあげると、INCREMENTでcountが+1されるロジックがあるとき、number型であると保証されていたとしても、+1されているのか-1されているのか、はたまた+100000されているのかについては保証されていないからです。 そのロジックを担保するのがテストの役割です。 reducerのテストの書き方 flow環境とそれ以外でテストの書き方が違います。 トラディショナルなテストだと{type: ACTION}の形式でテストを書くことが多いと思いますが、flow環境だとActionが型で担保されているためアクションクリエイターをそのまま実行して書きます。 トラディショナルな書き方でもいいですが、この方が補完も効くのでオススメします。

はじめに JavaScriptで文字列の有無を調べるにはindexOfではなくtestを使う | iwb.jp という、謎タイトルの記事をみました。 なんだか、indexOfより、testの方が、可読性が高いらしい... いやいやそれは無いわー うーん、なんかJS界隈では有名なブログっぽい気がする。何回か見たことある。 しかし、これは、ちょっと同意できないな。 indexOfは、たいていどんな言語でもindexOfとして作られているのだから、可読性は低くない。というか、自分にとっては、読みやすい。 むしろ正規表現パターンを記載するほうが、めんどくさいし、読みにくいわ.... 極力、正規表現は自分のプログラムに入れ込みたくない。Perlしかない時代じゃあるまいし....正規表現を使いたいときは明示的に正規表現を使います。って場面だけで使う。これ鉄則ですわ。 これって、可読性低くないかなあ。

まだアクションクリエイターを自分で書いているの？ reduxとflowtypeを使ってフロントエンドアプリケーションを構築していると、ボイラープレートが多く、面倒だと感じることがありませんか？ しかし、もはや、このAST時代の前には過去の悩みでしかありません。 型を書く。それが全てです。 型を書いて、定数を書いて、アクションクリエイターを書いて、一つ変更したら全て変更して、もしくはなんらかのハックを行って型付けして、なんてものは過去のことです。 これからは、アクションクリエイターの作成に5秒以上時間をかけたら怠惰でありましょう。そして、これはs2sの1プラグインでしかありません。 プラグインを組み合わせると以下のようなこともできます。 s2s (Source to Source) これを実現している仕組みをSource to Source(s2s)といいます。 ソースコードからソースコード

// @flow import { Actions, type Action } from './actions' export type State = { count: number, other: string, } const initialState: State = { count: 0, other: 'test' } export default function(state: State = initialState, action: Action): State { switch (action.type) { case Actions.INCREMENT: return { ...state, counter: state.count + 1 } default: return state } } 一見正しいように見えます。 flowの型エラーはでません。 しかし、よ

'use strict' const parse = require('mri') // or require('minimist') // node cli.js --name tj const { name } = parse(process.argv.slice(2)) // 適当なJSON const jsers = { tj: ['express', 'koa', 'mocha', 'stylus', 'co'], sindersorhus: ['ava', 'chalk', 'xo', 'yaomen'], rauchg: ['socket.io', 'next.js'], kittens: ['babel', 'yarn'], gaearon: ['redux', 'creaet-react-app'], substack: ['browserify', 'tape'], }

async/awaitのエラーハンドリングはtry/catchで行うのが一般的です。 しかし、これは複数のawaitを使い、それぞれ別のエラーハンドリングを行いたい場合など、冗長になりがちです。 そして、特に気に入らないのが、tryのスコープ外で非同期関数の戻り値を使う場合、letを使う必要があるところです。

最新版=>フロントエンドのテストについて考える 背景 フロントエンドのテストは、テストランナー、フレームワーク、Node.js、ブラウザ、Selenium、WebDriverなど、登場人物が多い。また、UIと密接に絡むのも特徴である。 これまで社内では、テスト種別によって、それぞれ解決したい事柄が明示的に示されていなかった。それぞれのテスト種別にどんな意味があり、何を目的とするかを明確にすることで、機能に対して、どのようなテストを実装すればよいのか共通認識を持っておくために、この記事を作成した。 フロントエンドのテスト4象限 今回この記事で紹介するテストは、Unit Testing、UI Testing、E2E Testing、Integration Testingの4つがあるが、それぞれ、上のグラフのような関係になっている。これらを考えることで、バランスの取れたテスト環境を確立したい。ポ

Reduxを採用しているアプリケーション向けの記事です。 Reduxの副作用処理で使われるMiddlewareといえば、公式サンプルではredux-thunkが使われていて、redux-sagaもよく使われているという印象があります。 redux-thunkよりredux-sagaが選ばれる理由の１つは、副作用処理を分離でき、ActionCreatorを純粋関数（副作用のない関数）に保てるところかと思います。 redux-thunkではこういうActionCreatorになり、redux-sagaだとこういうActionCreatorになり、加えてこういうSagaを作ります。 redux-thunkでテストを書くとActionCreatorはこういう非同期処理をモックしたコードになり、mapDispatchToPropsはこういうコードになります。 redux-sagaだとActionCr

前置き 会社の勉強会資料になります（6/16発表） フロントエンドの未来の話というか、色々なライブラリの紹介です ほとんどが5月上旬くらいに書いた資料なので、 それ以降に変化があったライブラリについては、追記という形で資料の中にコメント入れてます モジュールバンドラーの未来 モジュールバンドラーとは簡単に言うと、JavaScriptのビルドツールのことです 最近はフロントエンドでも、機能ごと・共通化などの理由によって、JSファイルを分けてコーディングをするので、 最終的にそれをまとめて、1個のJSにする必要がある その時に使われるのが、モジュールバンドラー 有名どころのツール みんな大好きwebpack 後は、rollupとかbrowserifyとか ですが、、 これからの時代は fuse-box fuse-boxとは webpackと同様なモジュールバンドラー 設定ファイルがシンプル w

Register as a new user and use Qiita more conveniently You get articles that match your needsYou can efficiently read back useful informationYou can use dark themeWhat you can do with signing up

prettierとはコードフォーマッタである。 コードのフォーマットを完全に自動化してくれる恩恵は大きく、現状prettierを使わない理由はない。 go fmtみたいなものでユーザが設定を書くのではなくライブラリ側で一意に決まる。 Atomの設定をしていれば、保存するたびに修正されるので何も考えずに導入すればいいと思う。 Reactのjsxやflowも対応している。 すでにeslintよりもgithubのスターが多いのは驚くが。 prettier/prettier: Prettier is an opinionated JavaScript formatter. しかし、問題はeslintと役割が一部かぶることだ。 prettierが直すそばからeslintがそれを直すようにエラーを出し、そのeslintのruleを無効化したり見直したりする作業を繰り返すのはしんどい。 そこでeslin

成果物 https://github.com/ktrkmk/rrrmaebwea 詳しくはリポジトリ側の README.md も御覧ください。 きっかけ Web アプリケーションにおけるバックエンド側をそれなりにやってきていましたが、とある日「10年のツケを支払ったフロント界隈におけるJavaScript開発環境（2016年4月現在）。」という記事を読み、フロントエンド界隈に少し興味を持ったのがきっかけになった感じです。 試そうとしたのはいいが… 早速その「React + Redux + react-router + material-ui + axios + ES2015 + Babel + webpack + ESLint + Airbnb JavaScript Style Guide」を試してみようじゃないか、と思ったものの、これだけ色々並ぶと何がなにやら状態。そもそも一番最初に必要

// 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 が一個減ってリファクタできたーと思っていた。確かに異なる例外処理のブロックが減ってしまっていたが、どうせ何かしらのデッドコードだろと思って消してしまった。 注: 意味的に

ちょっと他に今までの記事を移行したいと思った時は、以下のコマンドでバックアップするとよい。 認証すれば、http://qiita.com/api/v2/docs#get-apiv2authenticated_useritems を見ればわかるとおりGET /api/v2/authenticated_user/itemsで自分の記事を取得できる。 しかし、認証は面倒なので、/api/v2/itemsでユーザ名を指定することで、上記と同等の結果を認証せずに取得できる。