すべての例 (リーダーボード、ワードプレイなど) には、1 つの HTML テンプレート ファイルがあります。ベスト プラクティスの例として使用できる、さまざまな HTML テンプレート ファイルを含む大規模なオープン ソース Meteor プロジェクトはありますか? 大規模なアプリに必要なすべてを 1 つのテンプレート ファイルにまとめるのは現実的ではないようです。
質問する
47893 次
14 に答える
274
非公式の流星に関するよくある質問のように、私はそれが大きなアプリを構築する方法をかなり説明していると思います：
ファイルはどこに置くべきですか？
meteorのサンプルアプリは非常にシンプルで、多くの洞察を提供しません。これがそれを行うための最良の方法についての私の現在の考えです:(どんな提案/改善も大歓迎です！）
lib/ # <- any common code for client/server. lib/environment.js # <- general configuration lib/methods.js # <- Meteor.method definitions lib/external # <- common code from someone else ## Note that js files in lib folders are loaded before other js files. collections/ # <- definitions of collections and methods on them (could be models/) client/lib # <- client specific libraries (also loaded first) client/lib/environment.js # <- configuration of any client side packages client/lib/helpers # <- any helpers (handlebars or otherwise) that are used often in view files client/application.js # <- subscriptions, basic Meteor.startup code. client/index.html # <- toplevel html client/index.js # <- and its JS client/views/<page>.html # <- the templates specific to a single page client/views/<page>.js # <- and the JS to hook it up client/views/<type>/ # <- if you find you have a lot of views of the same object type client/stylesheets/ # <- css / styl / less files server/publications.js # <- Meteor.publish definitions server/lib/environment.js # <- configuration of server side packages public/ # <- static files, such as images, that are served directly. tests/ # <- unit test files (won't be loaded on client or server)大規模なアプリケーションの場合、個別の機能をサブディレクトリに分割して、それ自体が同じパターンを使用して編成することができます。ここでの考え方は、最終的には機能のモジュールを別のスマートパッケージに分解し、理想的には共有できるようにすることです。
feature-foo/ # <- all functionality related to feature 'foo' feature-foo/lib/ # <- common code feature-foo/models/ # <- model definitions feature-foo/client/ # <- files only sent to the client feature-foo/server/ # <- files only available on the server
于 2012-10-23T21:35:41.850 に答える
36
私はyagooarに同意しますが、代わりに：
client/application.js
使用する：
client/main.js
main.* ファイルは最後にロードされます。これにより、読み込み順序の問題が発生しないようにすることができます。詳細については、Meteor のドキュメント ( http://docs.meteor.com/#structuringyourapp ) を参照してください。
于 2013-05-29T15:12:43.980 に答える
26
Meteor は、アプリを自由に構成できるように設計されています。したがって、構造が気に入らない場合は、ファイルを新しいディレクトリに移動するか、1 つのファイルを多くの部分に分割することもできます。Meteor への移行はほとんど同じです。メインのドキュメント ページhttp://docs.meteor.com/で指定されているように、クライアント、サーバー、およびパブリック ディレクトリの特別な扱いに注意してください。
すべてを 1 つの HTML フィルにまとめるだけでは、ベスト プラクティスとは言えません。
考えられる構造の例を次に示します。私のアプリの 1 つであるディスカッション フォーラムでは、モジュールまたは「ページの種類」(ホーム、フォーラム、トピック、コメント) ごとに整理し、それぞれに .css、.html、および .js ファイルを配置します。ページ タイプを 1 つのディレクトリにまとめます。また、共通の .css および .js コードと、ルーターに応じて他のモジュールの 1 つをレンダリングするために {{renderPage}} を使用するマスター テンプレートを含む「ベース」モジュールもあります。
my_app/
lib/
router.js
client/
base/
base.html
base.js
base.css
home/
home.html
home.js
home.css
forum/
forum.html
forum.js
forum.css
topic/
topic.html
topic.js
topic.css
comment/
comment.html
comment.js
comment.css
機能別に整理することもできます
my_app/
lib/
router.js
templates/
base.html
home.html
forum.html
topic.html
comment.html
js/
base.js
home.js
forum.js
topic.js
comment.js
css/
base.css
home.css
forum.css
topic.css
comment.css
ただし、より具体的なベスト プラクティスの構造と命名規則が登場することを願っています。
于 2013-07-11T17:04:08.683 に答える
16
ひとまとめに！ドキュメントから：
> HTML files in a Meteor application are treated quite a bit differently
> from a server-side framework. Meteor scans all the HTML files in your
> directory for three top-level elements: <head>, <body>, and
> <template>. The head and body sections are seperately concatenated
> into a single head and body, which are transmitted to the client on
> initial page load.
>
> Template sections, on the other hand, are converted into JavaScript
> functions, available under the Template namespace. It's a really
> convenient way to ship HTML templates to the client. See the templates
> section for more.
于 2012-04-13T22:22:55.023 に答える
6
私たちには大規模なプロジェクトがあります (1.5 年間フルタイムで開発されていたため、おそらくこれまでに構築された中で最大の Meteor プロジェクトの 1 つです)。各ビューで同じファイル名のセットを使用します。これは非常に一貫性があり、探しているものに正確にすばやく移動するのに役立ちます。
- events.js
- helpers.js
- templates.html
- ルート.js
- スタイル.レス
- 等
プロジェクトでは次のようになります。
├──連結依頼 │ ├──events.js │ ├── helpers.js │ ├── routers.js │ └── templates.html ├──お客様なりすまし │ └── routers.js ├──ダッシュボード │ ├──events.js │ ├── helpers.js │ ├── onDestroyed.js │ ├── onRendered.js │ ├── routers.js │ └── templates.html ├──メール認証 │ ├──events.js │ ├── helpers.js │ ├── routers.js │ └── templates.html ├──読み込み中 │ ├──styles.css │ └── templates.html ├── メールボックス │ ├── autoform.js │ ├── 連結依頼確認 │ │ ├──events.js │ │ ├── helpers.js │ │ ├── onCreated.js │ │ ├── onRendered.js │ │ └── templates.html │ ├──events.js │ ├── helpers.js
関連するテンプレートは、同じファイルにまとめて保存されます。view/order/checkout/templates.htmlここに折りたたまれて表示される内容:
<template name="orderCheckout"></template>
<template name="paymentPanel"></template>
<template name="orderCheckoutSummary"></template>
<template name="paypalReturnOrderCheckout"></template>
ビューが多くのパーツで複雑になる場合は、サブフォルダーを使用します。
├──カート │ ├── addItem │ │ ├── autoform.js │ │ ├──events.js │ │ ├── helpers.js │ │ ├── onRendered.js │ │ ├── routers.js │ │ ├── style.less │ │ └── templates.html │ ├── チェックアウト │ │ ├── autoform.js │ │ ├──events.js │ │ ├── helpers.js │ │ ├── onRendered.js │ │ ├── routers.js │ │ └── templates.html │ └── 見る │ ├── autoform.js │ ├──deleteItem │ │ ├──events.js │ │ ├── helpers.js │ │ └── templates.html │ ├── editItem │ │ ├── autoform.js │ │ ├──events.js │ │ ├── helpers.js │ │ └── templates.html │ ├──events.js │ ├── helpers.js │ ├── onDestroyed.js │ ├── onRendered.js │ ├── routers.js │ ├── style.less │ └── templates.html
また、Meteor 開発用の非常に強力で柔軟なエディターである WebStorm を使用して開発しています。コードを検索して整理し、生産的に作業するときに非常に役立ちます。
リクエストに応じて詳細を共有させていただきます。
于 2015-08-26T09:27:41.197 に答える
6
meteorjs のコーディングからしばらく離れた後、かなり複雑なオンライン ゲームの作成に専念できる時間を持てたことをうれしく思います。アプリの構造は私の最初の関心事の 1 つでした。何人かの非常に優れたプログラマーが、アプリを構造化するパッケージのみの方法を支持しているようです。これにより、機能的に異なるパッケージを疎結合することができます。このアプローチには他にも利点があり、アプローチを説明する 2 つの非常に優れた記事がここにあります。
http://www.matb33.me/2013/09/05/meteor-project-structure.html http://www.manuel-schoebel.com/blog/meteorjs-package-only-app-structure-with-mediator -パターン
于 2014-04-05T01:36:58.713 に答える
5
iron-cli スキャフォールディング CLI を使用します。物事を非常に簡単にします。
https://github.com/iron-meteor/iron-cli
一度インストール。を使用iron create my-appして新しいプロジェクトを作成します。次の構造が作成されます。これは、既存のプロジェクトでも使用できます。iron migrateプロジェクトディレクトリで使用します。
my-app/
.iron/
config.json
bin/
build/
config/
development/
env.sh
settings.json
app/
client/
collections/
lib/
stylesheets/
templates/
head.html
lib/
collections/
controllers/
methods.js
routes.js
packages/
private/
public/
server/
collections/
controllers/
lib/
methods.js
publish.js
bootstrap.js
于 2015-07-21T08:50:14.180 に答える
3
アプリの構造化にはさまざまなアプローチがあります。たとえば、ルーターとさまざまなページ テンプレートがあり、各ページ テンプレートの内部に多くのページ パーツがある場合などは、上位 > 下位レベルのセマンティクスに応じて構造化します。
例えば：
client
views
common
header
header.html
header.js
header.css
footer
footer.html
footer.js
footer.css
pages
mainPage
mainPage.html
mainPage.js
mainPage.css
articles
articles.html
articles.js
articles.css
news
news.html
news.js
news.css
...
もちろん、ニュース テンプレートを別のページで使用できるので、ニュース テンプレートを共通フォルダーに配置することもできます。
快適な方法でアプリを構成するのが最善だと思います。
私はここに小さなアプリを書きました: http://gold.meteor.com そしてそれはとても小さいので、私は 1 つの html ファイルと 1 つの template.js ファイルのみを使用します.. :)
少しでもお役に立てば幸いです
于 2014-01-05T13:51:37.183 に答える
3
これに対処するだけでなく、プロジェクトの構成と開発環境のセットアップについても説明する、Setting Up Meteor ProjectsというEvented Mindの新しいクラスがあります。
クラスのアプリケーション構造ビデオから: Meteor は、アプリケーションをどのように構造化すべきかについてあまり強い意見を持っていませんが、いくつかのルールがあります:
1) ロード順 - Meteor は最初にファイル ディレクトリの最も深い場所に移動し、ファイルをアルファベット順に処理します。
2) クライアントとサーバーは、Meteor が認識する特別なフォルダーです。
構造は次のようになります。
both/
collections/
todos.js
controllers/
todos_controller.js
views/
todos.css
todos.html
todos.js
app.js - includes routes
client/
collections/
views/
app.js
server/
collections/
views/
app.js
packages/
public/
todos_controller は RouteController を拡張したもので、Iron Router に付属しています。
上記のツールも現在大きなアップデートを受けており、はるかに改善されており、 httpsem ://github.com/EventedMind/em で入手できるはずです。
于 2015-02-12T22:46:54.753 に答える
1
また、よく考えられたアーキテクチャを通じてアプリを拡張およびスケーリングするためのベスト プラクティスも探しています。上記のプラクティスはすべて、小規模から中規模のアプリで機能しますが、大規模なチームで作業する場合は失敗します。私が試したいくつかの方法があります：
1) 私は次の戦略に従いました: https://github.com/aldeed/meteor-autoformでテンプレートをスケーリングして再利用しました。著者は、コンポーネントとフィールドの設計について非常に優れたアイデアを持っています。コミュニティがほぼすべてのケースをカバーする 36 個のパッケージを開発し、開発段階でTypeScriptを使用してタイプ セーフにすることができるため、私は現在それを実装しています。
<template name="autoForm">
{{#unless afDestroyUpdateForm this.id}}
{{! afDestroyUpdateForm is a workaround for sticky input attributes}}
{{! See https://github.com/meteor/meteor/issues/2431 }}
<form {{atts}}>
{{> Template.contentBlock ..}}
</form>
{{/unless}}
</template>
これを行う方法についての良いブログ投稿は次のとおりです。.com/read/Blaze_Notes
2) これは非常に有望に見えますが、最近更新されていません。というコーヒースクリプトで書かれたパッケージです。Meteor のBlaze コンポーネント ( https://github.com/peerlibrary/meteor-blaze-components ) は、Meteor アプリで再利用する必要がある複雑な UI 要素を簡単に開発するためのシステムです。それらは、CoffeeScript、vanilla JavaScript、および ES6 で使用できます。一番いいのは、コンポーネントが OOP であることです。以下はその例の 1 つです。
class ExampleComponent extends BlazeComponent {
onCreated() {
this.counter = new ReactiveVar(0);
}
events() {
return [{
'click .increment': this.onClick
}];
}
onClick(event) {
this.counter.set(this.counter.get() + 1);
}
customHelper() {
if (this.counter.get() > 10) {
return "Too many times";
}
else if (this.counter.get() === 10) {
return "Just enough";
}
else {
return "Click more";
}
}
}
ExampleComponent.register('ExampleComponent');
{{> ExampleComponent }}
3) いつどこで問題が発生するかを教えてくれる型とトランスパイラーが好きです。私は TypeScript を使用して Meteor を操作しており、次のリポジトリを見つけました: https://github.com/dataflows/meteor-typescript-utils作成者が MVC アプローチを達成しようとしたようです。
class MainTemplateContext extends MainTemplateData {
@MeteorTemplate.event("click #heybutton")
buttonClick(event: Meteor.Event, template: Blaze.Template): void {
// ...
}
@MeteorTemplate.helper
clicksCount(): number {
// ...
}
}
class MainTemplate extends MeteorTemplate.Base<MainTemplateData> {
constructor() {
super("MainTemplate", new MainTemplateContext());
}
rendered(): void {
// ...
}
}
MeteorTemplate.register(new MainTemplate());
<template name="MainTemplate">
<p>
<input type="text" placeholder="Say your name..." id="name">
<input type="button" value="Hey!" id="heybutton">
</p>
<p>
Clicks count: {{ clicksCount }}
</p>
<p>
<ul>
{{#each clicks }}
<li> {{ name }} at <a href="{{pathFor 'SingleClick' clickId=_id}}">{{ time }}</a></li>
{{/each}}
</ul>
</p>
</template>
残念ながら、このプロジェクトは維持されておらず、積極的に開発されていません。
4) すでに述べたと思いますが、パッケージを使用してスケーリングできます。それには、優れた抽象的な考え方が必要です。Telescope で動作するようです: https://github.com/TelescopeJS/Telescope
5) meteor-template-extension – テンプレート ヘルパー、イベント ハンドラー、およびフックをテンプレート間でコピーするさまざまな方法を提供し、コードの再利用を可能にします。欠点は、すべてのコピーを開発者が何度も何度も処理する必要があることです。これは、コードベースが大きくなるにつれて問題になります。さらに、明確に定義された API コミュニティがなければ、コンポーネントを構築して共有することはできません。
6)フロー コンポーネント– フロー コンポーネントは API 設計において React に近く、Blaze コンポーネントはデータ コンテキストやテンプレート ヘルパーなどのなじみのある概念を維持しています。一方、フロー コンポーネントは引き続きテンプレート ベースのイベント ハンドラーを使用しますが、Blaze コンポーネントはそれらをクラス メソッドにするため、継承による拡張やオーバーライドが容易になります。一般に、Blaze コンポーネントはより OOP 指向のようです。フロー コンポーネントはまだ正式にリリースされていません ( #5 と #6 のテキスト クレジットhttps://github.com/peerlibrary/meteor-blaze-components#javascript-and-es6-support )
2 番と 3 番も慣れが必要ですが、時間の経過とともに開発速度が向上します。4 番目は、コンポーネントをビルドおよびテストして、コードをより安定させることができます。3 番目には、Typescript の完全な型安全性という利点があります。これは、ドキュメントが貧弱なチームで開発する場合に大きなプラスとなります。ただし、現在、2 番目を TypeScript に移植しています。これは、非常に快適に作業でき、Gulp を使用していないときに Meteor で動作させるためにコンパイラ パッケージを微調整する必要がないためです。
Meteor で作業する正しい方法を見つけるのはまだ難しいです。自分でそれを理解する必要があります。そうしないと、適切に配置されたフォルダー構造になってしまいますが、すべてがどこにあるのか見当がつきません。ハッピーコーディング。
于 2015-09-15T23:20:23.407 に答える