trans-loader: node/webpack なしではじめるフロントエンドプロジェクト - Qiita
フロントエンドはツールチェイン多くて大変ですね。何から初めていいかわからないと思います。 というわけで、 babel や webpack, というかもはや node の インストールすら不要でフロントエンドを始めることができるプロジェクトを作りました。 git clone git@github.com:mizchi/frontend-starter.git --depth 1 --single-branch master cd frontend-starter ruby -run -e httpd . -p 8000 # 好きな静的サーバー This is App を何か書き換えてリロードしてみてください。適用されるはずです。 最後に一つ注意。裏側はとても富豪的に動いているので、本番環境では使わないでください ここで動くコードはちょっと微調整を加えると webpack でビルドできます。
prisma - 最速 GraphQL Server実装
react-apollo の調査で GraphQL サーバーをさっくり実装する必要があり、 今 graphqool どうなってるんだっけ、と見に行ったら prisma が推奨されていました。 日本語情報がまったくなかったので、調査した結果をまとめておきます。 prisma とはなにか GraphQL の形をした ORM MySQL/Postgre への マイグレーションヘルパー付き モデル定義からインデックス自動生成 CRUD自動生成 graphqoolの次期版? PaaS に依存せず、自分でデプロイ可能なマイクロサービス 自分も最初よくわからなかったのですが、 使ってみた感じでは、 GraphQL の形をとった ORM + Migration Helper です。 $ npm i -g prisma $ prisma init my-graphql-server # REPL で実装を選
真に Universal な ReactComponent を書く - Qiita
ややお気持ち多め。 前置き 最近の個人的な考えとして、React 書く人は ReactNative 側にスキルを寄せたほうが良いのではないか、と思っている。 ReactNative の需要の高まりは凄い。最初はプロトタイピング採用だったのが、徐々にプロダクションに出始めている。今年末には新規プロジェクトの10~20%は ReactNative になるんじゃないか？という感すらある。 僕はデスクトップのブラウザは好きだけども、残念ながら、世の中の趨勢はモバイル側にある。その上でフロントエンドにロックインすることをリスクに感じている。PWAのアプリケーションも来そうではあるが、直近の需要を賄うためにやはりReactNativeに習熟しておきたい。 大事なのは、「考え方として」 ReactNative に軸足を移したほうが色々といいということだ。 Web は基本的に動きが少ない。見栄えをよくした
2017末時点での React Component 設計のベストプラクティス - Qiita
どう考えているか、というのを聞かれたので、記事に起こしておきます。個人の意見です。 Prettier を使う 気づけばコードの整形を人間がやる時代は終わりました。 細かいコーディングスタイルでレビューの時間を取るぐらいだったら、一貫した自動整形ルールを適用すべきです。 人によっては細かいこだわりがあって prettier の規則が気に食わないかもしれず、僕も最初はそうでしたが、Atomで保存する度に自動整形を走らせる prettier の強烈な開発体験によって、最終的にそれらのこだわりを全て捨てることが出来ました。 生産性を求めるなら、現時点では最優先で導入すべきものです。 React.createClass を使わない v16 で削除されたのでいわずもがな。 同様に、 createClass でしか使えなかった mixin 周辺機能も丸ごと deprecated です。 「可能な限りは」
MobXでReactのステート管理をする - Qiita
MobXはSimple, scalable state management を謳うステート管理マネージャ。 最近Hacker NewsやEchoJSで、にわかにMobXがフィーチャーされている。 3 Reasons why I stopped using React.setState — Medium この記事を読んで、そんなにいいもんかなと思い、試してみることにした。 mobxjs/mobx: Simple, scalable state management. カウンター 簡単なカウンターを作ってみる。一秒で1インクリメンタルされるやつ。 import ReactDOM from "react-dom"; import React from "react"; import {observable} from "mobx"; import {observer} from 'mobx-r
Yarnファーストインプレッション - Qiita
Yarn とは 名前から yet another ... な雰囲気を漂わせてますが、 npm互換 です。(追記: 正確にはnpmの生成するpackage.jsonと互換とのことだった)。各所から node連中はまたツール増やしやがって！という雰囲気を感じるので、ここは明確にした方がいい。(techcrunchの記事とかそういう印象を与える書き方になってる) npm install 時のディレクトリ配置への介入 npm install 時のより賢いローカルキャッシュ yarn.lock ファイルでバージョン固定 yarn 環境下で yarn add, yarn install などを行った場合、 yarn.lock と package.json に同時に書き込み、 その環境で生成されたファイルは yarn なしでも動きます。つまり、yarn はより厳密に npm のバージョンを固定したい人向
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
春ですね！人の配置がリファクタリングされ、コードもリファクタリングの季節です。 では僕がここでモダンな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
gulp-typescript で --target es6 から babel に通しつつ Incremental Buildする - Qiita
gulp-typescript で --target es6 から babel に通しつつ Incremental BuildするTypeScriptgulp ivogabe/gulp-typescript 元々typescriptなんてtscを生で叩けばいいじゃん派だったのだが、--target es6 で吐いたのをさらにbabelに通す必要があって、一旦書きだしたものをさらにbabelを通そうとすると、tmpなディレクトリが必要になるし、ファイルIOに負荷がかかるので、gulpのストリームの中で変換したかった。 やりたいこと node / electron で走らせたかったので browserify せずに src -> lib に書き出す。lib は es5 仕様。 ブラウザ用に書き出すときは必要に応じてbrowserifyする。debug中はElectronで走らせることでbrow
ES async/awaitを全力で使ってみて発見したイディオム - Qiita
// 注意: 最初のバージョン、async function がundefinedを返すと思い込んでて、色々間違えてた 手元の趣味コード(諸事情により未公開)に向けて全力で適用してみた結果学びがあった。以下babel。 事前に確認 async/await は Promise と Generator の糖衣構文である await は Promiseのインスタンスの式を与えると(見た目上)停止する await するには async functionで囲う必要がある async function は必ず非同期で実行され undefinedPromise を返す 以下イディオム とりあえず実行したい (async () => { await new Promise(done => { setTimeout(1000, done); }) })(); 解説: async ブロック作ってからの即時実行
TypeScript の async/await をいますぐ使う - Qiita
$ npm install -g typescript@next $ tsc -v message TS6029: Version 1.6.0-dev.20150907 $ npm install -g babel "use strict"; let wait = function(n: number){ return new Promise(done => setTimeout(() => done(n), n)); }; let main = async function(){ await wait(50); console.log('await done'); } // async promise nomally wait(100).then(() => console.log('promise normally done')); main(); "use strict"; var
Real World Electron Development - Qiita
~ Case of the Kobito, Markdown Editor for YAPC Hackathon! @mizchi / Koutaro Chikuba, Increments Inc About Node.js / Frontend Engineer Single Page Application Specialist Kobito for Windows Developper Increments Inc (Providing qiita.com / Qiita:Team) Sorry, my English is not so good. YAPC::Asia 2015 Hackathon | Peatix の発表資料 ここで喋ることは一昨日急に決まったので(YAPC回るし)スライド作る時間なかった。ゆるして。 発表中に @benogle 氏に何度か質問しながら進行しま
npm v3.x 試してみた & 注意する点 - Qiita
ふと思い立って npm install -g npm@3 した。3.1.2 は VERY BETA とのこと(ニュアンスがよくわからん。アルファとの対比なのか、アルファ相当なのか) ので、そのうち出るでしょう。 node_modulesのフラットな展開 npm@3 だとnode_modulesの依存がパッケージ間のバージョンが衝突しない限り、トップレベルのnode_modulesにフラットに展開される。これによって同一のモジュールを依存ツリー間でモジュールが重複した時にnode_modules以下のサイズが膨らむのを抑えることができる。 衝突した場合はそのモジュールの子のnode_modulesに格納されて衝突は回避される。 気になるrequireの仕様 とはいえ、requireの仕様が変わってるわけじゃないので、トップレベルから子だけじゃなく孫モジュールも直接requireできてしまう。
IndexedDbをActiveRecord+Promiseっぽく扱えてJSONSchemaでバリデーションできてnodeでもオンメモリで動いてくORMみたいな何か作ってみた - Qiita
IndexedDbをActiveRecord+Promiseっぽく扱えてJSONSchemaでバリデーションできてnodeでもオンメモリで動いてくORMみたいな何か作ってみたJavaScriptStoneSkin タイトル盛りすぎた。 mizchi/stone-skin です。 npm install stone-skin で入るんでbrowserifyと一緒に使ってください。 命名は、時間があったらFF14やるんだけどなという気持ちを込めて。(ナイトだけLv50にしてから1年以上触ってない) この前紹介したArdaと一緒で、本番環境でドッグフーディングしつつ開発したので、使い物になるはず。今さっきドキュメント書いてv0.1.0にしたので紹介。 サンプルコード 非同期APIはPromiseを返すので、この前書いた JavaScript - Babelのasync/await試してみた(+中
Babelのasync/await試してみた(+中の処理をちょっと追ってみた) - Qiita
npm install babel -g experimentalオプション必須なので コンパイルは babel -e foo.es6 > foo.js みたいな感じ 適当に試してみた。 import "babel/polyfill"; let wait = function(n: number){ return new Promise(done => setTimeout(() => done(n), n)); }; let main = async function(){ await wait(50); console.log('await done'); } // async promise nomally wait(100).then(() => console.log('promise normaly done')); // await main(); 最初awaitブロックがa
Riot.js試してみた - Qiita
Reactで消耗しているmizchiです。 とりあえず一通り動かしてみた。webpack上でtag-loader使ってtagを動的にコンパイルすると便利だった。 https://github.com/mizchi-sandbox/webpack-riot-skeleton Overview 軽量仮想DOM実装 Vue風の独自文法 riotが軽量なのは独自の文法に対してプリコンパイラを持っててパーサがランタイムから切り離されてることと、仮想DOM実装が本当に最低限で結構サボってるようにみえる。 仮想DOMの実装部分はここ https://github.com/muut/riotjs/blob/master/riot.js#L348-L413 一通り書いてみた結果、独自シンタックスが最大の特長で、イベントハンドラ周りで基本的にDOMべったりのコードを要求されるといった印象。 JSとHTMLを並
ブラウザ環境でcommonjs/requireを可能にするrequire1k - Qiita
$ wget https://raw.githubusercontent.com/Stuk/require1k/master/require1k.min.js <html> <head> <title>try require1k</title> <script src="require1k.min.js" data-main="./main"></script> </head> <body> </body> </html> data-mainで指定したパスがエントリポイントになる。 main.jsではlodashは読み込んでみた。 どうやら、外部モジュールを呼び出す際にpackage.jsonのmainを見てないっぽくて、直接指定しなければならなかった。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
node_modules以下でbrowserifyされる側が自分のtransformを指定する - Qiita
