Angular: 角度のあるテンプレートのようなJSX

これはJSXが好きな人にとっては良いことかもしれませんが、これのほとんどは利益ではなく意見であるため、コアチームではなく外部の貢献者である必要があります。 私の考え：

1＆4：Angular2テンプレートで正常に動作します。 すでにWebStormでこれの開始を示しています。 間もなく他のIDEに登場します。

2：コンパイルはビルドステップとして行われるため、AngularはJSXよりもパフォーマンスが優れている可能性があります（まもなく着陸します）。

5：はい、これは素晴らしいことであり、Fluxスタイルのデータフローを使用している人々にとってはうまくいく可能性があります。 ネイティブのAngular2にはまもなくコンポーネントが増える可能性がありますが、エコシステムへの実際のメリットについてはあまり確信がありません。

一般に、すべてのツールがHTML仕様に準拠したテンプレートで動作し、設計者がそれらを簡単に操作できるため、HTML仕様に準拠したテンプレートが好きです。

@bradlygreen @malekpour
TypeScriptを使用して2つのテクノロジーをシームレスに橋渡しすることで、今日ある程度これを行うことができると私は主張します。 結局、それはただのJavaScriptです...

ここに、Flux / ReactベースのコンポーネントをAngular2.0コンポーネントに統合する例があります。
http://www.syntaxsuccess.com/angular-2-samples/#/demo/react

ここにもいくつかの詳細があります：
http://www.syntaxsuccess.com/viewarticle/integrating-react-with-angular-2.0

@bradlygreen私はあなたのほとんどすべての点に同意します。 現在のAngular2の設計で何も変更したり、私が大ファンであるランタイムテンプレートの解析を削除したりするつもりはありませんでした。 私が何を意味するのかを明確にするために、これら2つのコンポーネントを比較してください。

@Component({
  selector: 'key-up',
  template: `
    <div>    
      <h4>Give me some keys!</h4>
      <div><input (keyup)="onKey($event)"><div>
      <div>{{values}}</div>
    </div>
  `
})
class TestComponent {
  values = '';
  onKey(event) {
  }
}

@Component({
  selector: 'key-up',
  templateJsx: (
    <div>
      <h4>Give me some keys!</h4>
      <div><input (keyup)={ onKey($event) }><div>
      <div>{{values}}</div>
    </div>
  )
})
class TestComponent {
  values = '';
  onKey(event) {
  }
}

最初のテンプレートのonKeyは、別の複数行の文字列内の二重引用符で囲まれた文字列ですが、JSXテンプレートでは、識別子であり、より意味があります。

また、コンパイラーはこれに似たものを生成しますが、実行時にパーサーがこれよりも優れたパフォーマンスを発揮できるかどうかは非常に疑わしいです。 createには、タグ/ディレクティブ名、属性、子の3つのパラメーターがあります。

AngularJsx.create("div", null, 
  AngularJsx.create("h4", null, "Give me some keys!"), 
  AngularJsx.create("div", null, AngularJsx.create("input", {keyup:  onKey($event) })), 
  AngularJsx.create("div", null, {values})
)

私はあなたがあなたのコメント（番号2）で言及した計画を知りませんが、angularがコンパイルされたテンプレートをサポートするならさらに良いです。 したがって、JSXコンパイラは同じものを出力します。

そして、これは、反応するコミュニティメンバーが貢献したり移行したりするための大きな魅力になることを忘れないでください。

そしてこれはおかしいです、私はhttps://angular.io/docs/ts/latest/guide/user-input.htmlページから上記のコンポーネントスニペットをランダムにコピーしました。 JSXテンプレートをコンパイルしようとしたときにのみ、 <div><input (keyup)="onKey($event)"><div>行のdiv要素が閉じられていないことに気付きました。
https://github.com/angular/angular.io/blob/master/public/docs/_examples/user-input/ts/src/app/app.ts#L36
この間違いは、ドキュメントチームによってそのページで少なくとも4回繰り返されます。 この種の間違いは非常に一般的であり、タイプセーフなテンプレートのサポートが大いに役立ちます。

@malekpourテンプレートコンパイラの設計ドキュメントを勧めしますhttps ：//docs.google.com/document/d/11r8IuS4xDyhVSEBp7fDYo7aiLYsLEXKs4lPd36umUGM/edit

そうは言っても、これをサードパーティのレンダリングプラグインとして実装することは確かに可能です-実際、私たちはあなたが始めるかもしれないreact-nativeレンダラーを持っています： https ：

ちなみに@thelgevoldの超クールなデモ-あなたのコンポーネントページは素晴らしいです！

ありがとう@robwormaldありがとうございます！

JavaScriptでのXMLのアイデアは好きではありませんでした。 私が見ることができる唯一の利点は、テンプレートHTML文字列の静的分析です。 ただし、これらのHTML文字列をリントする静的アナライザーを作成することは可能です。 次のようなタグ関数でテンプレート文字列をマークすることができます

html`<div>...</div>`

または、どういうわけかTypeScript型システムを使用して文字列がHTMLであることを示唆します...

templateJsxが好きです。

+1 templateJsx
@ mohsen1 「JavaScriptでのXMLのアイデアは好きではありませんでした」：

• XMLをJavaScriptに配置せず、別のファイルに保存します。 ただし、すべてのAtomまたはVisual Studio IDEの利点（すべてのシンボル参照の検索、シンボルの名前変更、構文の強調表示、自動インデントなど）を含めて、タイプしてください。
• CSSデザイナが誤ってHTMLテンプレートのJavaScriptフラグメントを破損した場合、Typescriptコンパイラが通知します。
• NS。

この問題はTypescriptプロジェクトで解決されています。＃7100の

TypeScriptを使用する場合、テンプレートは強く型付けされます（TSX）。これは、エラーを防ぎ、TSXテンプレートサポート用のより良い開発エクスペリエンスを提供するのに役立ちます。

：スマイリー：

政治家とは異なり、私はJSXについて考えを変えたと言うことを恐れません！

TypeScriptとJSX（TSX）を使用することは、私の最近の反応プロジェクトでの喜びです。 型付きHTMLは本当に素晴らしいです！

_実際にはHTML_である型付きHTMLについては、以下を参照してください。まもなくお近くのAngularに登場します。

これは素晴らしい。 これは、templateurlを介してリンクされたhtmlテンプレートでも可能ですか？

他の号の締めくくりがわかりません。 これはjsxよりもタイピングのことですか？

@robwormaldjsxよりも素晴らしいです。

TSXおよび一般的なJSXの利点は、エディターのインテリセンスと構文の色付けに限定されません。

私は個人的に、現在のAngular 2テンプレートの解析や将来のビルド時のテンプレートのコンパイルと比較して、JSXがランタイム解析とAST生成を自然に排除する方法が好きです。

jsx !== React 、Reactチームによって発明されたものであることを忘れないでください。 Angularチームは、Reactコミュニティが移行するためのインセンティブとしてこれをサポートできると思います。 ここに提案されたJSX仕様がありますhttps://facebook.github.io/jsx/

TypeScriptの拡張性がどこに行くのかが好きで、いつの日かtypescriptがJSXのものをすべて削除して、拡張機能に移動するのを見ることができます。 上記の問題で私が見たものは、実際にはJSXよりも優れています。 JSXには、 classキーワードの競合などの独自の落とし穴があります。 どのtypescriptチームが取り組んでいるのかが改善されると確信しており、AngularチームにJSXのサポートを依頼するべきではありません。

@ mohsen1 TypeScript Extensibilityがとてもクールだということに同意しますが、なぜ

AngularチームにJSXのサポートを依頼するべきではありません

@malekpourはプログラミング言語レベルで解決できるので？

@ mohsen1あなたはそれがプログラミング言語レベルで解決できるということは正しいです。 実際、それはすでにTSXによって解決されており、しばらくの間TypeScriptによってサポートされています。

かかわらず、活字体拡張は開発時間に助けることができるかの、の値型template残りますstring実行時に解析され、分析される必要があるが、値templateJsx意志オブジェクトまたは関数を使用する準備をします。

テンプレートの値型は文字列のままであり、実行時に解析および分析する必要があります

本当じゃない。 実行時ではなくビルドステップの一部としてテンプレートをコンパイルするPRオープンがすでにありますhttps://github.com/angular/angular/pull/7155

本当じゃない。 すでにPRがあります...

@ MikeRyan52つまり、追加のビルドステップでテンプレートをポストコンパイルしない限り、これは単純に当てはまります。

TypeScriptの拡張性がAngularでどのように機能するかは正確にはわかりませんが、TSXよりも優れていることを願っています。 新しい提案で修正されると思うTSXの2つの問題：

• これ以上classNameの代わりにclass
• テンプレート内で<Type>構文を許可します。 現在TSXではreturn (<div>{(<Foo>bar).baz}</div>)ようなことをすることは不可能です

TSXでは、 (<Foo>bar).baz代わりに(bar as Foo).baz使用できます。

この10行のjsbinは、TSXテンプレートがいかに簡単に機能するかを示しています
http://jsbin.com/yodiwid/edit?js、output

はい、私はそれを知っています。 でも要点はありがとう！

多分私は何かを逃しました-この場合、次のことを申し訳ありません…

私の見解では、Angularランタイムは、コンポーネントツリーを合成するために、template-stringとtemplateUrl-fileの両方を分析する必要があります。 「分析」とは、文字列を任意のJavaScript表現（オブジェクトツリーなど）に変換することを意味します。

TSX（コンパイル時にTypeScriptによってJavaScriptオブジェクトツリーに解析される）は、Angularテンプレートの別の表現である可能性があります。 私は間違っているかもしれませんが、Microsoft / TypeScript＃6508の問題を解決することは、JavaScriptオブジェクトツリーを別のAngularテンプレート表現として使用するよりもはるかに難しいはずです。 その上、
Microsoft / TypeScript＃6508は理想的なソリューションでその機能的性質：

• 「関数としてのテンプレート」は他のテンプレートの可能性を開きます
• Typescriptにバインドされていません

「関数としてのテンプレート」は「AngularのJSXのようなテンプレート」とは少し違うと思うので、新しい＃7339号を作成しました。

TypescriptでのAngular2の向き（「Angular-1つのフレームワーク」の概念とともに）は、ReactをAngularに任せた主な理由の1つでした。 私が今欠けているのは、厳密に型付けされた機能テンプレートだけです。

TSX / JSX /機能テンプレートのアイデアをサポートする多くの優れた議論をしてくれた@malekpourに感謝します。 Angularチームがそれらに耳を傾けると思います。

@bradlygreen 、どこでもっと知ることができますか：
「2：コンパイルはビルドステップとして行われるため、AngularはJSXよりもパフォーマンスが優れている可能性があります（まもなく着陸します）。」

コンパイルされたテンプレートはどのようになりますか？

私の興味は、条件付きロジックがテンプレートに存在する場合のE2Eテストのコードカバレッジに関連しています。
Angular 1.x文字列ベースのテンプレートでは、コンパイルされたJSXとは異なり、すべてのコードパスが実行されたかどうかを判断する方法はありませんでした。

最終的な目標は、100％のカバレッジで一連のE2Eテストを実行し、未使用のスタイルを削除できるようにすることです。
https://github.com/addyosmani/grunt-uncssを参照して

私が最初の中型のng2アプリを完成させたとき、Jsxがdirectivesとselectorを提供する必要性を排除できることに気づきました。

@malekpourは＃7339を参照してください：「JSX ...それは（Angular）チームがサポートすることに興味を持っているものではありません」。

ビルドステップとしてコンパイルが行われるため、AngularはJSXよりもパフォーマンスが優れている可能性があります

JSXもビルドステップではなかったかのように...

@cmelionまあ、私たちはそれについて見る必要があります。 :)これの前半は数週間で着陸します。 それが起こったとき、私たちはそれについて大したことをします。

JSXスタイルのものよりもテンプレートが好きな理由については、 http： //angularjs.blogspot.com/2016/03/why-angular-renders-components-with.htmlも参照して

+1：+1：templateJsx

Reactから来て、ng2を調べていると、JSXがネイティブJSforループなどを使用できることはキラー機能であると言わなければなりません。 また、コンパイルエラーが発生することも重要です。 何らかの理由で、チュートリアルを実行してテンプレートにタイプミスを作成しても、例外はスローされません。 実行時でもコンパイル時でもありません。 あなたはちょうどいくつかのコードをレンダリングするHTMLを残されていますか？

heroes.map（hero => ...）;の上に* ngFor = "let hero ofheroes"と書くテンプレート言語で座っています。 直感的ではありません。 JS / TSを自由に使える方が優れています。

テンプレートは、実際にHTMLを記述しているという意味で優れています。 classNameとclassを学ぶ必要がないので、私はそれが本当に好きです。 ここでテンプレートが輝いています。

@robwormald ：ファンシーエディターのサポートに関する更新はありますか？ 私はVScodeを使用していて、Atomを試したところ、豊富なhtml + tsオートコンプリートを備えた優れたテンプレートエクスペリエンスを持っているものはないようです。 Atomは、HTMLタンプレート文字列を強調表示します。 また、これは個別のHTMLファイルでも機能しますか？

私はtypescriptとrxが本当に好きです。 Webコンポーネントアーキテクチャを持つこともプラスです。 しかし、現在テンプレートにあるようなng-forなどは使いたくありません。 JSXは、JavaScriptのみを使用するため、はるかに優れています。

だから私にとって、今のところjsxを持っていないことはショーストッパーです。 多くの人が同じように感じていると思います。

[アップデート]
私は間違っていたと思います。 ngコンパイラを使用すると、基本的に同じ種類の機能を利用できます。
私はまだng-forディレクティブが好きではありませんが、robwormaldからのステートメントを読んだ後、その理由を理解しました。

別のReactとJSXの愛好家がチャイムを鳴らします。onClick、onBlur、その他のevのカスタム属性を備えた「古き良き」HTMLテンプレートが登場するまで、NG2に関するすべてが問題ありません。 ハンドラー、基本的なマップ関数など。

聞きたいのですが-なぜですか？ なぜNG2テンプレートには、ループを実行するために文字列を受け入れるいくつかのあいまいなHTMLのような属性が含まれている必要があるのですか？ なぜEV。 ハンドラーには何らかのプレフィックスが必要ですか？ フロントエンド開発者が使用する通常のHTMLと一貫性がないのはなぜですか？

JSXを見てください。 とても簡単です。 非常にクリーンで、親しみやすく、明確に定義された構文を備えています。 スコープは、中括弧の正しい使用法によって非常に明確に定義されます。 プレーンなJSです。 NG2テンプレートのように車輪の再発明を試みません。

そして、デザイナーがレンダリングされたコンテンツ（HTMLとJSX）を簡単に変更できると言えば、私の経験から、デザイナーが能力を持っていれば、奇妙な* ngIfなどのHTML属性の代わりに、JSXがどのように機能するかを説明するのは非常に簡単です。 。

私にとって、個人的には、JSXがここでの明確な勝者です。 もちろん、それは議論の余地があり、一般的には習慣の問題ですが、少なくとも双方が発言して物事を比較することは許可されています:)

@Inlescoは、デザイナーが*ngForを含むHTMLよりも、JSが関与するJSXテンプレートを変更する方が良いとは思えないことに注意する必要があります。

@gioraguttデザイナーは、Androidアプリのxmlテンプレートを変更するのが難しいと感じています。 これは、Androidアプリの構築にHTMLを使用する正当な理由ではありません

@ m3l7はこれを考慮してください：

マットさん、テキストボックスをtrade-form.component.html揃えるのを手伝ってくれませんか。

対

マットさん、テキストボックスをTradeFormComponent.tsx揃えるのを手伝っていただけませんか。 ええ、レンダリング関数を探すだけで、クラスの代わりにclassNameを使用する必要があることを忘れないでください

等々。 もちろん、これは意見が分かれています。一方のアプローチがもう一方のアプローチよりも絶対的に優れていると言っているわけではありません。 私がいつもReact開発者から聞いていることとは異なり、 Ha we do data.map(...) so it's so much better than *ngFor 。 これは何の意味もありません。 あなたはどちらの方法でもたわごとを成し遂げるつもりです。 今日、 AngularもReactを選択する理由、またはその逆を選択する唯一の理由は、人々の意見です。 あなた/あなたのceo /あなたのcto /あなたがAngularよりもReactを愛するものなら、あなたはReactをするつもりです。 逆も同様です。

これは、他のすべてのフレームワーク/ライブラリにも当てはまります。 このすべてのVue / Aureliaまたは他の数十のフレームワーク。 誰がそのたわごとを必要としています。 コミュニティはいくつかの良いもの（別名React / Angular ）を選び、それらから生き地獄を改善する必要があります。 これらの数十のライブラリをすべて公開しても、進展はありません。

@gioraguttそれは意見ではありません。 テンプレートでの型チェックは大きな前進です。

2番目のポイント：正解です。そのため、多くの人が角度を付けて改善しようとします（つまり、jsx / tsxを追加することによって）

@ m3l7はい、タイプチェックは重要であり、typescript言語サービスを備えたAngularテンプレートで可能です。 一方、テンプレートに無制限の表現力があると、ツールのサポートが妨げられ、テンプレートファイルの理解に費やす必要のあるエネルギー量などの他の影響があります。 その上で、同じ言語を持つことの力と一貫性に値するかどうかについて意見を持つことができます。

@ m3l7 @egagaが言ったように、一般的にhtmlテンプレートでタイプチェックと*ngForをitems.map(item => ...)と比較することは、 *ngIf場合と同様に、その背後にforだけではないものがあるため、行う価値がない可能性があることを言及する価値があると思います。 mapようにコレクションを処理します。

また、例を見てみましょう： pipes 。 パイプの使用のしやすさ、表現力の高さ、テンプレートへの統合のしやすさ。 Linuxとbashを毎日使用している人として、 pipesの概念は非常に明確で直感的であり、構成可能であることは言うまでもありません。 それを行うには、純粋なJSではもう少し時間がかかります。

参照-https：//github.com/angular/vscode-ng-language-service

これに対する私たちの立場は変わっていませんし、変わる可能性もありません。 もちろん、ReactまたはJSXベースのライブラリをAngularに統合することは大歓迎です。自分で行うのは簡単です。 Angularコアではこれをサポートしません。

次に、Vueの市場を開きます

@robwormald強い型のhtmlをtypescriptと統合し、参照を見つけ、この参照に基づいて機能をリファクタリングする方法が必要です。 コンポーネントのセレクターについても同じです。セレクター名の文字列ベースを使用するのではなく、コンポーネントのクラス名を使用する必要があります。これにより、セレクターの代わりにクラスに基づいて参照を検索し、検索と置換の代わりにクイックリファクタリングを実行できます。 C'mon guysangularはこれでもっとうまくやれるでしょう。手遅れになる前にすぐに決断してください。

@bradlygreenこれを実現さ

現在、これを実現できるサードパーティのライブラリはありますか？

@ John0xネイティブの機能/選択肢なしでAngularを使用するのは逆効果です：rose：

これを実現させてください:)

人々が実際にclassName引数を使用して、JSXの利点を却下しているという事実は笑えます。 私の意見では、この問題は、開発者の経験の観点から、フロントエンドフレームワークとしてのAngularの最大の失敗であり、この自己満足は、Angularを他の主要なフレームワークにますます失うことになるでしょう。

@KamiShikkaku ... JSXがとても好きなら、 @ trotylによって導入されたNG-VDOMに興味があるかもしれません...参照：
https://blog.angularindepth.com/introducing-to-ng-vdom-a-new-way-to-write-angular-application-60a3be805e59

これを忘れないでください
https://github.com/angular/angular/issues/21224

Angular開発者が市場で入手可能なさまざまなテンプレート言語に反対している理由がよくわかりません。 特にJSXのように考え抜かれた、強力でTS互換の何かである場合は、持っているほど良いです。

JSXが発生し、おそらく大成功を収めた場合、NgJのHTMLテンプレートを引き続き使用するものもあれば、ジャンプしてアプリをJSXに移行するものもあります。 ここで問題はどこにありますか？ 間違いなくどこにも、私がそれを見る方法。

@Inlesco ...それが本当かどうかわからない。

持っているほど良い...

@InlescoはおそらくJSXがReactの署名であるのに対し、 HtmlはAngular署名の1つです。

子コンポーネント（コンテキストメニュー）内から構成したい動的ドロップダウンメニューを備えたコンポーネントがあります。 これはReactでの5分間の作業ですが、Angularはどうですか？

@mitevdev ...動的ドロップダウンを備えたコンポーネントには、通常、その構成を含む入力があります。 子コンポーネント（コンテキストメニュー）が何であるか、およびそれがドロップダウンコンポーネントの子である理由がまったくわかりません。

コンポーネントB（子）のラッパーであるコンポーネントA（親）があります。 Aには、コンポーネントBでカスタマイズできるツールバーがあります。Bにはさまざまな実装がありますが、Aは常に同じです。 そのツールバーの内容は、Bの実装によって異なる場合があります。

もちろん、可能なすべての組み合わせを「予測」して* ngIfまたは* ngSwitchを使用することはできますが、これは、コンポーネントBがビューおよびコールバックハンドラーとして構成されたコンテンツ（要素）を送信できるほどエレガントではありません（これはまさにReactです）サポート）。

@mitevdev <ng-content> / slotsがあなたのケースで機能するはずだと思います、それはReactのprops.childrenように機能します

@khaledosmanの良い点、 <ng-content>を探しています<ng-container>に関連して*ngTemplateOutlet <ng-container>を見つけました。これは、私の場合の解決策のようです。

背後にある考え方は、子コンポーネントB内でツールバーの要素を定義することです。

...
<ng-template #element1>...</ng-template>
...

コンポーネントAは、その要素のIDをフェッチして使用しますBで定義された要素をレンダリングします。

<ng-container *ngTemplateOutlet="element1"></ng-container>

テストする必要があるのは、デフォルトのコンポーネントカプセル化を無効にすることなく、要素IDがグローバルスコープで使用できるかどうかだけです。

更新：それは動作します....！

私は助けを求める人々に反対しているわけではありませんが、 @ mitevdevの問題は、AngularでのJSXのサポートの問題と

@ John0x 「

私のgoogle-fuは、この現在実験的なライブラリng-vdomを見つけました。

私はまだそれをテストしていませんが、Angular内のJSXでReactスタイルのrender（）メソッドのサポートを提供すると主張しています

https://blog.angularindepth.com/introducing-to-ng-vdom-a-new-way-to-write-angular-application-60a3be805e59

https://github.com/trotyl/ng-vdom

この問題の最善の解決策は、Reactを使用することです。

この問題は、非アクティブのために自動的にロックされています。
同様の問題または関連する問題が発生した場合は、新しい問題を提出してください。

自動会話ロックポリシーの詳細をご覧ください。

_{_このアクションはボットによって自動的に実行されました。_}