
Intro 長いこと議論になっていた ES Modules の Node における扱いに一応の決着が付き、 .mjs という拡張子が採択された。 この拡張子の意味と、今後ブラウザと合わせて Universal JS を実装していく上での作法が見えてきたことになる。 合わせてエコシステムが対応していくことで、長年の夢だった JS のモジュール化を進めていくことができるだろう。 ES Modules 徐々に揃いつつある ES Modules(ESM) の仕様は TC39 で行われており、その仕様については主に以下のような部分になる。 import や export と行った構文 module 内はデフォルト strict mode module でスコープを閉じる module 内の this は undefined etc 逆に以下は TC39 での策定範囲外となる どう Module を読
で完了 なければ nodeのバージョンをnで管理する などを読みつつnodeとnpmをインストールしてください 準備するもの コンソール db.json ブラウザ(動作確認用) やること db.json ファイルを作成する bashの touch コマンドやWindowsなら右クリックからなどでお好きなようにファイルを作ってください db.json にリソースを登録する ここでモックサーバから返して欲しいデータリストを列挙します 最上位の階層の key がエンドポイントになります { "users": [ {"id": 1, "name": "hoge"}, {"id": 2, "name": "fuga"} ], "tweets": [ {"id": 1, "contents": "あー眠い", "user-id": 1}, {"id": 2, "contents": "ファビュラス!"
はじめに こんにちは、普段はPawooの開発を担当している新卒エンジニアのabcangです。 最近話題のHeadless Chromeを使って魚拓を作ってみましたので、その話をします。 結論から言うと、こういうものができました。 以下、詳しくお話していきます。 日々行われるデザイン変更をどう把握するか pixivには毎日新機能やUIの変更がデプロイされており、どんどんページが変わっていきます。 ある日、ディレクターから「デザインの変更履歴を追うための魚拓ツールがほしい」と相談されました。魚拓ツールがあると、なにか数値の変動があったときにデザインの崩れを確認したり、過去のデザインを振り返ったりするときに便利とのことです。 ちょうどそのタイミングでHeadless Chromeが利用できるGoogle Chrome 59がリリースされていたので、試すいい機会だと思い引き受けました。 Headl
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 私 「ねぇ、Service Workerってあなた何者?」 Service Worker 「プログラム可能なネットワークプロキシです」 私 「.....(´Α`lll)o0(イミフ)」 (この記事は元々英語で投稿した記事の翻訳版です。挿絵に入っているテキストが英語のままなのはご了承ください🙏) Service Workerってなんかカッコ良さそうだけど、実際問題なんなのかよくわからない 2015年7月、私はテキサス州オースティンで開催されたJavaScriptのカンファレンスに参加していた。ステージに立っていたのはJake Archi
const fsbx = require('fuse-box'); const fuseBox = fsbx.FuseBox.init({ homeDir: 'src/', sourcemaps : true, outFile: './dist/app.js', plugins: [ [ fsbx.SassPlugin({ outputStyle: 'compressed' }), fsbx.CSSPlugin({}) ], fsbx.TypeScriptHelpers(), fsbx.JSONPlugin(), fsbx.HTMLPlugin({ useDefault: false }) ] }); fuseBox.devServer('>main.ts **/*.html', { port: 4445 }); シンプル!! fuse-boxの特徴として ・TypeScriptはデフォル
ESDoc v1.0をリリースするために、機能をプラグイン化してコアと周辺機能を分離しています。 https://github.com/esdoc/esdoc-plugins この作業は大体終わり、現在はよりadvancedなプラグインのPoCを作成しています。 そこで、今回はFlowとTypeScriptをESDocで扱うための2つのプラグインを紹介します。 ESDoc v1.0自体ついては正式リリース後に紹介する予定です。 FlowをESDocで使用する esdoc-flow-type-plugin Flowで書かれたコードをESDocで使用可能にするプラグインです。 このプラグインはPoCなので、実現可能性を確かめるためだけの最小実装となっています。 ドキュメントコメントに型情報が書かれていない場合、Flowの型アノテーションから型を取得する 型推論による型情報の取得は未実装 このプ
npmの方もbetaが取れて、2.2.1が公式に配布となりました。 www.npmjs.com 公式サイト webpackのversion:2のために公式サイトが作られました。 webpack 移行の手順 詳しくはこちらを確認してください。 Migrating from v1 to v2 Medium medium.com medium.com 移行における変更点 フィールドバリデータ 設定ファイルのフィールドを検証します。 v1ではwebpack-validatorが必要でしたが、v2ではデフォルトで入っています。 ローダー リネーム module.loaders -> module.rules loaders -> use query -> options { rules: [ { test: /\.js$/, use: ['babel-loader'], options: { } }
最近悩んでいる React/Redux でそれなりの規模のアプリケーションを作るための良い設計について、 日頃ネットで気になる記事を漁っていたんだけど、積読がたまってきた&Twitter やら Pocket やら Qiita に散らばってしまったのでここらで一旦整理します。 (★ はその中でも特に読みたいもの) Redux の設計 ★ React Redux Real World Examples 〜先人から学ぶReact Reduxの知恵〜 実際に GitHub にあるソースコードを読んで得られた知見について。 「Storeはどんな具合に構成すべきか」「Store初期化(hydration)用データの定義はどうすべきか」「Componentはどう整理すべきか」と目次だけ見ても非常に実用的な内容。 ★ erikras/ducks-modular-redux: A proposal for
このドキュメントの目的 自分は趣味でFlowをずっと使っていて、またプロダクションでも今まで3プロジェクトほどにFlowを導入した。その知見。 「Flow は便利そうだけど、怖い」「いれてみたら色々ハマったからクソ」「わからん、なにもかも…」という人に対し、自分がいままで出くわしたパターンや、聞かれた疑問について、メジャーな解法を提示する。 なぜFlowを導入するか Babel から段階的に導入することが出来る React の JSX にも推論を入れることができる 部分的に適用できる ASTがES準拠であり、ESLintなどがツールが使える(TSは独自AST) それ自身ランタイムに全く影響はないので落とすのも簡単 実際にはReactと一緒に使うのが、エコシステムもユースケースも揃っていて、一番効果を発揮するだろう。それか、小さい npm モジュールを自分で書くとき。 型のメリット/デメリッ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く