web-dev-qa-db-ja.com

多くのHTMLテンプレートファイルで大規模なMeteorアプリを構築するためのベストプラクティスは何ですか？

すべての例（リーダーボード、ワードプレイなど）には、1つのHTMLテンプレートファイルがあります。ベストプラクティスの例として使用できる、多くの異なるHTMLテンプレートファイルを含む大規模なオープンソースMeteorプロジェクトはありますか？大きなアプリに必要なものをすべて1つのテンプレートファイルに入れるのは実用的ではないようです。

meteor
166
Andrew Arrow

すべてまとめて！ドキュメントから：

> 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.
16
mdgrech

非公式の流星に関するよくある質問と同様に、大規模なアプリの構成方法はほぼ説明できていると思います。

ファイルはどこに置くべきですか？

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

詳細： 非公式Meteor FAQ

275
yagooar

私はyagooarに同意しますが、代わりに：

client/application.js

つかいます：

client/main.js

main。*ファイルは最後にロードされます。これにより、ロード順序の問題がないことを確認できます。詳細については、Meteorのドキュメント http://docs.meteor.com/#structuringyourapp を参照してください。

36
pwcremin

Meteorは、ほぼあらゆる方法でアプリを構築できるように設計されています。そのため、構造が気に入らない場合は、ファイルを新しいディレクトリに移動するか、1つのファイルを複数の部分に分割して、Meteorにほぼ同じように配置できます。メインドキュメントページで指定されているクライアント、サーバー、およびパブリックディレクトリの特別な扱いに注意してください： http://docs.meteor.com/ 。

1つのHTML塗りつぶしにすべてをひとまとめにすることは、ベストプラクティスとしては決して現れません。

考えられる1つの構造の例を次に示します。アプリの1つであるディスカッションフォーラムで、モジュールまたは「ページタイプ」（ホーム、フォーラム、トピック、コメント）ごとに整理し、それぞれに.css、.html、および.jsファイルを配置します1つのディレクトリにページタイプをまとめます。また、一般的な.cssおよび.jsコードと{{renderPage}}を使用してルーターに応じて他のモジュールの1つをレンダリングするマスターテンプレートを含む「ベース」モジュールもあります。

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

ただし、より具体的なベストプラクティスの構造と命名規則がいくつか出現することを願っています。

26
Jonathan Warden

このトピックをグーグルで探しているすべての人に：

emコマンドラインツール（Ironルーターの背後にいる人EventedMindによる）は、新しいMeteorアプリをリギングするときに非常に役立ちます。 Niceファイル/フォルダー構造を作成します。すでにアプリで作業していて、再編成したい場合は、emを使用して新しいプロジェクトをセットアップするだけで、インスピレーションに使用できます。

参照： https://github.com/EventedMind/em

そしてここ： https://stackoverflow.com/questions/17509551/what-is-the-best-way-to-organize-templates-in-meteor-js

14
Mikael Lirbank

Discover Meteor Bookのファイル構造は非常に優れており、堅実なスタートだと思います。

/app: 
 /client
   main.html
   main.js
 /server 
 /public
 /lib
 /collections
  • / serverディレクトリのコードはサーバーでのみ実行されます。
  • / clientディレクトリのコードはクライアントでのみ実行されます。
  • 他のすべては、クライアントとサーバーの両方で実行されます。
  • / lib内のファイルは、何よりも先にロードされます。
  • Main。*ファイルは、他のすべての後にロードされます。
  • 静的アセット（フォント、画像など）は/ publicディレクトリにあります。
11
Almog Koren

パッケージを作成する

もちろん、すべてがこのアプローチに適合するわけではありませんが、大規模なアプリでは、分離できる多くの機能があります。分離可能で再利用可能なものはすべてパッケージに収まり、残りは他の回答で述べたように通常のディレクトリ構造になります。オーバーヘッドを避けるためにパッケージを作成しなくても、モジュール方式でコードを構造化することは良い考えです（ これらの提案 を参照）

Meteorでは、ファイルのロード方法（ロード順、場所：クライアント/サーバー/両方）およびパッケージのエクスポート内容をきめ細かく制御できます。

特に、関連ファイル間でロジックを共有する簡単な方法は非常に便利です。たとえば、util関数を作成し、別のファイルで使用したいとします。それを「グローバル」（varなし）にすると、Meteorはそれをパッケージの名前空間にラップするため、グローバル名前空間を汚染しません。

ここ は公式ドキュメントです

9
Bogdan D

私たちには大規模なプロジェクトがあります（おそらく1.5年のフルタイム開発であったため、これまでに誰もが作成した最大のMeteorプロジェクトの1つです）。各ビューで同じファイル名のセットを使用します。これは非常に一貫性があり、探しているものに正確にすばやく移動するのに役立ちます。

  • events.js
  • helpers.js
  • templates.html
  • routes.js
  • styles.less
  • 等.

プロジェクトでは次のようになります。

 
├──consolidationRequests
│├──events.js 
│├──helpers.js 
│├──routers.js 
│└──templates.html 
├──customerSpoof 
│└──routers.js 
├──ダッシュボード
│├─ ─events.js 
│├──helpers.js 
│├──onDestroyed.js 
│├──onRendered.js 
│├──ルーター.js 
│└──templates.html 
├──emailVerification 
│├──events.js 
│├──helpers.js 
│├──routers.js 
│└──templates.html 
├──loading 
│├──styles.css 
│└─ ─templates.html 
├──メールボックス
│├──autoform.js 
 │├──ConsolidationRequestConfirmation 
│││──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>

ビューが多くの部分で複雑になる場合、サブフォルダーを使用します。

├──cart 
│├──addItem 
│││─autoform.js 
│││──events.js 
 ││├──helpers.js 
│││─onRendered.js 
│││├──routers.js 
││├──styles.less 
││└──templates.html 
│├──checkout 
│││─autoform.js 
│││──events.js 
││├──helpers.js 
│││──onRendered.js 
│││─routers.js 
││└──templates.html 
│└──view 
│├──autoform.js 
│├──deleteItem 
│││──events.js 
││ ├──helpers.js 
││└── templates.html 
│├──editItem 
││├─autoform.js 
││├──events.js 
│││──ヘルパー.js 
│││──templates.html 
│├──events.js 
│├──helpers.js 
│├──onDestroyed。 js 
│├──onRendered.js 
│├──routers.js 
│├──styles.less 
│└──templates.html

また、Meteor開発用の非常に強力で柔軟なエディターであるWebStormを使用して開発しています。コードを検索して整理し、生産的に作業するときに非常に役立ちます。 Webstorm view

リクエストに応じて詳細をお知らせください。

6
Max Hodges

Meteorjsコーディングをしばらくしてから、かなり複雑なオンラインゲームの構築に専念できるようになりました。アプリの構造は私の最初の懸念の1つであり、非常に優れたプログラマーがアプリを構造化するパッケージのみの方法を支持しているようです。これにより、機能的に異なるパッケージを疎結合できます。このアプローチには他にも利点があり、このアプローチを説明する2つの非常に優れた記事がここにあります。

http://www.matb33.me/2013/09/05/meteor-project-structure.htmlhttp://www.manuel-schoebel.com/blog/meteorjs- package-only-app-structure-with-mediator-pattern

6
lukenofurther

Iron-cli scaffolding 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
5
ravish.hacker

私はすでにmattdeomボイラープレート形式に従っていますが、これには既に鉄のルーターとモデル（Collection2）が含まれています。下記参照 ：

client/                 # Client folder
    compatibility/      # Libraries which create a global variable
    config/             # Configuration files (on the client)
    lib/                # Library files that get executed first
    startup/            # Javascript files on Meteor.startup()
    stylesheets         # LESS files
    modules/            # Meant for components, such as form and more(*)
    views/              # Contains all views(*)
        common/         # General purpose html templates
model/                  # Model files, for each Meteor.Collection(*)
private/                # Private files
public/                 # Public files
routes/                 # All routes(*)
server/                 # Server folder
    fixtures/           # Meteor.Collection fixtures defined
    lib/                # Server side library folder
    publications/       # Collection publications(*)
    startup/            # On server startup
meteor-boilerplate      # Command line tool
4
Rudy

Evented Mind と呼ばれる新しいクラスがあります Set Up Meteor Projects これに対処しますが、プロジェクトの構成と開発環境のセットアップについても話します。

クラス内の Application Structure ビデオから：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は、Routerを拡張します。これはIron Routerに付属しています。

上記のemツールも今すぐに大きな更新を取得しており、次の場所でより良く利用できるはずです。 https://github.com/EventedMind/em

3
katogeaver

アプリの構造化にはさまざまなアプローチがあります。たとえば、ルーターとさまざまなページテンプレートがあり、各ページテンプレートの内部に多くのページパーツなどがある場合、上位>下位レベルのセマンティクスに応じて構造化します。

例えば：

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ファイルのみを使用します。

私はそれが少し役立つことを願っています

3
Boris Kotov

また、よく考えられたアーキテクチャを通じてアプリを強化および拡張するためのベストプラクティスも探しています。上記のプラクティスはすべて、中小規模のアプリで機能しますが、より大きなチームで作業すると失敗します。私が試したいくつかの方法があります。

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>

これを行う方法についての良いブログ投稿があります： http://blog.east5th.co/2015/01/13/custom-block-helpers-and-meteor-composability/ と同様にここ： http://meteorpedia.com/read/Blaze_Notes

2）これはとても有望に見えますが、最近更新されていません。これは、コーヒースクリプトで記述されたパッケージです。 MeteorのBlazeコンポーネント（ https://github.com/peerlibrary/meteor-blaze-components ）は、Meteorアプリで再利用する必要がある複雑なUI要素を簡単に開発するためのシステムです。 CoffeeScript、Vanilla JavaScript、ES6で使用できます。最も良いのは、コンポーネントがOOPであるということです。以下に例を示します。

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）既に述べたように、パッケージを使用してスケーリングできます。それには、優れた抽象的な考え方が必要です。それは望遠鏡で動作するようです： 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をTypeScriptに移植しています。これは、Glpを使用していないときにMeteorで動作するようにコンパイラパッケージを調整する必要がないためです。

Meteorを使用する適切な方法を見つけるのは依然として困難です。自分でそれを把握する必要があります。そうしないと、うまく整理されたフォルダー構造になりますが、すべてがどこにあるのかわかりません。ハッピーコーディング。

1
MichelH