タグ

2017年2月8日のブックマーク (8件)

  • Resolve | webpack

    These options change how modules are resolved. Webpack provides reasonable defaults, but it is possible to change the resolving in detail. Have a look at Module Resolution for more explanation of how the resolver works. resolve object Configure how modules are resolved. For example, when calling import 'lodash' in ES2015, the resolve options can change where webpack goes to look for 'lodash' (see

    Resolve | webpack
    kitokitoki
    kitokitoki 2017/02/08
    resolve.alias に挫折。eslint-import なんちゃらか、babel経由からか?
  • webpackのビルド高速化の効果を測ってみた - Qiita

    webpackによるビルドを高速化するための設定がいくつかあるのでそれらの効果を(雑にですが)測ってみました。 なお、ビルド時間の測定には手前味噌ですが、React.js用のGridコンポーネントであるGriddleをBootstrapデザインにするgriddle-react-bootstrapのexamplesアプリを使用しています(動いている物はこちらから見れます)。使用ライブラリは下記のpackage.jsonの通り。TypeScriptで書いているので、webpack + ts-loaderでビルドしています。Babelは使用していませんが傾向はたぶん同じになるかと思います。 "devDependencies": { "cross-env": "^1.0.7", "ts-loader": "^0.7.2", "typescript": "^1.8.2", "webpack": "^

    webpackのビルド高速化の効果を測ってみた - Qiita
  • GitHub - mcmath/ejs-html-loader: Webpack loader for rendering HTML from EJS templates

  • webpack-rev-replace-plugin

    kitokitoki
    kitokitoki 2017/02/08
    Rewrite occurrences of filenames which have been renamed by webpack.
  • サーバーサイドレンダリング不要論 - Qiita

    サーバーサイドレンダリング、Isomorphic、Universal JavaScriptなどの言葉をよく見かけます。なるほどね、良さそうだね、外部公開するサービスを書くことがあったら挑戦してみたいね、Mithrilにもisomorphic-mithrilってのをがんばっている人がいるし、みたいなことを漠然と思っていたのですが、最近ASCII.jpのシステムコールプログラミングの連載を書いていて、あらためてHTTPの仕様を見返してみて、逆にサーバーサイドレンダリングをしない方がいいのではないか、と思い始めました。 追記(23:30): サーバーサイドレンダリングと書いていますがUniversal JavaScriptみたいな凝ったビューの更新の意味です。 サーバーサイドレンダリングの欠点 サーバーサイドレンダリングのメリットとしてあげられるのは次の2点です。 検索エンジンのクローラー向け

    サーバーサイドレンダリング不要論 - Qiita
  • domaindoc でドメインモデルをドキュメントする - Qiita

    この記事は CureApp Advent Calendar 2016 18日目の記事です。 今日はドメインモデルのドキュメンテーションの話です。 さて、DDD を実践していくと、成果物としてドメインモデルの定義が上がってきます。最終的には、それをソースコードに落とし込むというのが、DDD の目標ですが、その前に一旦、これこれのドメインモデルが定義された、ということを記録する必要が必ず生じます。 その定義をどうやって保存するかというのはチームによってまちまちなのではないかと思いますが、自分の経験上、どこにどういう形でドメインモデルのドキュメントを残すかはわりと意見が分かれるトピックです。 自分が今までやってきた手段としては、wiki (コンフルーエンス) に残す、Google スプレッドシートに残す、ホワイトボードに手書きしたものを写真でとるなどの手法をやってきましたが、どれも一長一短でした

    domaindoc でドメインモデルをドキュメントする - Qiita
  • クライアント主権時代にJSのモデルはどう共有すればいいのか - Qiita

    SPA、スマートフォンアプリの隆盛。時代はクライアントサイドに主権が移ってきている。 これからの時代はクライアントサイドにロジックを持たねばならぬだろう。 一方サーバーは、「ユーザー1人でも完結するサービス」に限れば、 DOA(Data Oriented Architecture)的な立ち位置のもの(≒mBaaSとか)と、BFF(Backend for Frontend)的な立ち位置のものがあればよくなる。 モデル定義がダブる いままでモデルはサーバーのものだった。 クライアントでは「JSON」というデータになってやってきて、 それをなんとなく成形して表示してた。 でも来るべきクライアント主権時代においては、 やっぱりクライアントでもJSONじゃなくてドメインモデルを扱いたい。 そうするとサーバー/クライアントの2つの環境でモデル定義を書かなくてはならないではないか。 多くのサービスは実は

    クライアント主権時代にJSのモデルはどう共有すればいいのか - Qiita
    kitokitoki
    kitokitoki 2017/02/08
    decorator も HOC も似たようなものなのになんで評価(主観)がわかれてるのか??
  • Externals | webpack

    The externals configuration option provides a way of excluding dependencies from the output bundles. Instead, the created bundle relies on that dependency to be present in the consumer's (any end-user application) environment. This feature is typically most useful to library developers, however there are a variety of applications for it. externals string object function RegExp [string, object, fun

    Externals | webpack
    kitokitoki
    kitokitoki 2017/02/08
    externals, todo