24

私は browserify-rails + babelifyを使用して、react + rails プロジェクトで jsx をトランスパイルしています。

jsxトランスパイルが機能するために（reactのマウントポイントである）// require('');が必要な理由に非常に困惑しています。components.js

コメント行を削除する // require('');と、「SyntaxError: Unexpected token import」が表示されます

現在、コメント行がトランスパイルに影響を与える理由について、私には手がかりがありません。これがreact、babelify、browserify、browserify-rails、またはrailsアセットパイプラインの問題なのかについても困惑しています。

完全なコード ベースについては、 https://github.com/sidazhou/react_rails_skeleton/tree/v0.0.1を参照してください。

components.js

// require(''); // somehow this is necessary, why?! Otherwise we get: "SyntaxError: Unexpected token import"
import React from 'react';
import ReactDOM from 'react-dom';
import Widgets from './components/Widgets.jsx';

ReactDOM.render( <Widgets />, document.getElementById('react_component') );

パッケージ.json

{
  "name": "react-sample",
  "dependencies": {
    "babel-preset-es2015": "^6.3.13",
    "babel-preset-react": "^6.3.13",
    "babelify": "^7.2.0",
    "browserify": "^12.0.1",
    "browserify-incremental": "^3.0.1",
    "history": "^1.13.1",
    "material-ui": "^0.13.4",
    "react": "^0.14.3",
    "react-dom": "^0.14.3",
    "react-router": "^1.0.2",
    "react-tap-event-plugin": "^0.2.1"
  },
  "engines": {
    "node": ">= 0.10"
  }
}

アプリケーション.rb

config.browserify_rails.commandline_options = "-t [ babelify --presets [ es2015 react ] ]"
4

1 に答える 1

3

それについて未解決の問題がありますbrowserify-rails：

#124 変換は、でロードされたファイルにのみ適用されますrequire()。

関連すると思われるcymenの投稿をいくつか引用して、スレッドを要約しようとしています (彼は browserify-rails の作成者です)。

cymenは 2015 年 12 月 10 日にコメントしました:

// requireそれをデバッグしようとする 1 つのハックは、ソースにorというコメントを入れることです// module.exports。それで解決しますか？もちろん、es6 を検出するための適切な修正 (インポートなど) を追加したいと考えています。

cymenが 2015 年 12 月 18 日にコメントしました

最初の投稿を読み直した後、簡単な解決策は、application.js にアプリケーションを要求させて開始することです。ES6 などを使用しないでください。これにより、多くのことをいじることなく、必要な場所に移動できます。後でアセット パイプラインから離れたときに (理想的には)、コンパイルをより詳細に制御できるようになり、必要に応じてメイン ファイルにリファクタリングすることができます。しかし、なぜそのような小さな問題と戦うのでしょうか?

mockdeep (彼は問題を開いた)は 2015 年 12 月 18 日にコメントしました:

ええ、私たちはそれをやっています。この時点で、application.js にいくつかのグローバルが定義されています。これは単なる驚くべき問題であり、Chrome または Firefox でテストしても必ずしも表面化するとは限りません。どちらも多数の ES6 機能をサポートしているためです。

では、なぜアセット パイプラインから離れたいのでしょうか。アセットをプリコンパイルするという点では、かなり確かな価値があるようです。

cymenは 2015 年 12 月 18 日にコメントしました:

アセット パイプラインがアンチパターンになりつつあるためです。browserify-rails が存在する唯一の理由は、アセット パイプラインによって JavaScript 開発が現在のベスト プラクティスから約 5 年ほど遅れているためです。browserify-rails は機能しますが、ある時点で、browserify または webpack に直接移動する方がはるかに簡単です。

したがって、私の見解では、古い JavaScript から CommonJS に移行し、アセット パイプラインから飛び出すには、browserify-rails が最適です。

しかし、当然のことながら、誰でも自由に使用できます。ページの更新をアセットのビルドに接続すると、いくつかの利点があります。Rails での作業に慣れている Ruby 開発者にとって、単純な「これが機能する方法」というのは理にかなっています。Procfile を使用すると、webpack/browserify を開始してアセットを監視し、必要に応じて再コンパイルすることは難しくありません。そのため、さまざまなユースケースがあることを理解しています。

cymenは 2015 年 12 月 18 日にコメントしました:

私は雇用主を切り替え、現在は webpack を直接使用しています (これが気に入っています。以前のエンジニアがその選択を行っており、正常に動作しています。browserify も良いと思います)。しかし、私はクライアント側の Web アプリケーションに取り組んでいるので、バックエンドは通常、Sinatra を実行する Ruby ベースの API です (サービス側のレンダリングを行う NodeJS を使用)。

私の以前の雇用主はしばらくの間 browserify-rails を使用していましたが、資産パイプラインから飛び出したと思います。よくわかりません (まだそのプロジェクトに取り組んでいる人たちと詳しく話す機会がありませんでした)。

問題の 1 つは、特にローエンドの MacBook (Airs、13 より古い) で browserify-rails の実行に時間がかかっていたことです。browserify-rails 2.x では、(browserify-rails 1.x のように) Tilt を仲介として使用する代わりに、Sprockets を直接使用して問題を回避できれば、パフォーマンスを高く維持できる可能性がはるかに高くなると思います。 . 実際、Sprockets のキャッシングは、browserify-incremental (パフォーマンスを維持するために browserify ビルドをキャッシングすること) を取り除くことができるほど十分に優れているはずですが、現在 2.x では、Sprockets でのキャッシングと browserify でのキャッシングがあります。複雑すぎる可能性があります）。

これが、この問題に関する彼の最後のコメントでした (3 か月前)。したがって、すでに持っている回避策が、現時点で利用可能な最良のソリューションです (誰かが browserify-rails に ES6 検出を実装するまで)。

于 2016-03-05T19:07:33.567 に答える