{"id":15013323,"url":"https://github.com/peerlibrary/meteor-blaze-components","last_synced_at":"2025-08-17T16:55:03.342Z","repository":{"id":29426250,"uuid":"32962054","full_name":"peerlibrary/meteor-blaze-components","owner":"peerlibrary","description":"Reusable components for Blaze","archived":false,"fork":false,"pushed_at":"2020-10-25T08:48:28.000Z","size":531,"stargazers_count":355,"open_issues_count":30,"forks_count":26,"subscribers_count":18,"default_branch":"master","last_synced_at":"2025-03-30T21:08:34.386Z","etag":null,"topics":["blaze","meteor","meteor-package"],"latest_commit_sha":null,"homepage":"http://components.meteorapp.com/","language":"CoffeeScript","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"bsd-3-clause","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/peerlibrary.png","metadata":{"files":{"readme":"README.md","changelog":"HISTORY.md","contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2015-03-27T01:49:03.000Z","updated_at":"2024-11-26T10:35:38.000Z","dependencies_parsed_at":"2022-09-15T12:30:35.903Z","dependency_job_id":null,"html_url":"https://github.com/peerlibrary/meteor-blaze-components","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/peerlibrary%2Fmeteor-blaze-components","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/peerlibrary%2Fmeteor-blaze-components/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/peerlibrary%2Fmeteor-blaze-components/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/peerlibrary%2Fmeteor-blaze-components/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/peerlibrary","download_url":"https://codeload.github.com/peerlibrary/meteor-blaze-components/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":247557767,"owners_count":20958047,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["blaze","meteor","meteor-package"],"created_at":"2024-09-24T19:44:05.652Z","updated_at":"2025-04-06T22:11:00.575Z","avatar_url":"https://github.com/peerlibrary.png","language":"CoffeeScript","funding_links":[],"categories":[],"sub_categories":[],"readme":"Meteor Blaze Components\n=======================\n\nBlaze Components for [Meteor](https://meteor.com/) are a system for easily developing complex UI elements\nthat need to be reused around your Meteor app. You can use them in [ES2015, vanilla JavaScript, and\nCoffeeScript](#javascript-and-coffeescript-support).\n\nSee [live tutorial](http://components.meteor.com/) for an introduction.\n\nAdding this package to your Meteor application adds `BlazeComponent` and `BlazeComponentDebug` classes into the\nglobal scope.\n\nBoth client and server side.\n\nTable of contents\n-----------------\n\n* [Installation](#installation)\n* [Additional packages](#additional-packages)\n* [Components](#components)\n* [JavaScript and CoffeeScript support](#javascript-and-coffeescript-support)\n* [Accessing data context](#accessing-data-context)\n* [Passing arguments](#passing-arguments)\n* [Life-cycle hooks](#life-cycle-hooks)\n* [Handling events](#handling-events)\n* [Component-based block helpers](#component-based-block-helpers)\n* [Animations](#animations)\n* [Mixins](#mixins)\n* [Namespaces](#namespaces)\n* [Server side rendering](#server-side-rendering)\n* [Use with existing classes](#use-with-existing-classes)\n* [Reference](#reference)\n  * [Class methods](#class-methods)\n  * [Instance methods](#instance-methods)\n    * [Event handlers](#event-handlers)\n    * [DOM content](#dom-content)\n    * [Access to rendered content](#access-to-rendered-content)\n    * [Access to data context and components](#access-to-data-context-and-components)\n    * [Life-cycle hooks](#life-cycle-hooks-1)\n    * [Utilities](#utilities)\n    * [Low-level DOM manipulation hooks](#low-level-dom-manipulation-hooks)\n    * [Mixins](#mixins-1)\n* [Debugging](#debugging)\n* [Related projects](#related-projects)\n\nInstallation\n------------\n\n```\nmeteor remove blaze-html-templates\nmeteor remove templating\nmeteor add peerlibrary:blaze-components\n```\n\nIf you get an error that two packages are trying to handle `*.html` files, you have to make sure that your app\nor a package does not depend on the `templating` packages (often through the `blaze-html-templates` package).\nBlaze Components supersedes the `templating` package and provides its functionality as well.\n\nBlaze Components compile HTML template files both on the client and server side. If you have previously been adding\nHTML files on the server side as well, you might want to limit those to the client side only.\n\nAdditional packages\n-------------------\n\n* [peerlibrary:blaze-layout-component](https://github.com/peerlibrary/blaze-layout-component) – A\n  simple [Blaze Component](https://github.com/peerlibrary/meteor-blaze-components) for use with\n  [Flow Router](https://github.com/peerlibrary/flow-router)'s [layout manager](https://github.com/kadirahq/blaze-layout)\n* [peerlibrary:blaze-common-component](https://github.com/peerlibrary/meteor-blaze-common-component) – An\n  extended base Blaze Component with common features\n\nComponents\n----------\n\nWhile Blaze Components are built on top of [Blaze](https://www.meteor.com/blaze), Meteor's a powerful library\nfor creating live-updating user interfaces, its public API and semantics are different with the goal of providing\nextensible and composable components through unified and consistent interface.\n\nThis documentation assumes familiarity with Blaze and its concepts of\n[templates, template helpers, data contexts](http://docs.meteor.com/#/full/livehtmltemplates), and\n[reactivity](http://docs.meteor.com/#/full/reactivity), but we will also turn some of those concepts around.\nFor a gentle introduction to Blaze Components see the [tutorial](http://components.meteor.com/).\n\nA Blaze Component is defined as a class providing few methods Blaze Components system will call to render a\ncomponent and few methods which will be called through a lifetime of a component. See the [reference](#reference)\nfor the list of all methods used and/or provided by Blaze Components.\n\nA basic component might look like the following (using the\n[reactive-field](https://github.com/peerlibrary/meteor-reactive-field)) package as well).\n\n```javascript\nclass ExampleComponent extends BlazeComponent {\n  // Life-cycle hook to initialize component's state.\n  onCreated() {\n    // It is a good practice to always call super.\n    super.onCreated();\n    this.counter = new ReactiveField(0);\n  }\n\n  // Mapping between events and their handlers.\n  events() {\n    // It is a good practice to always call super.\n    return super.events().concat({\n      // You could inline the handler, but the best is to make\n      // it a method so that it can be extended later on.\n      'click .increment': this.onClick\n    });\n  }\n\n  onClick(event) {\n    this.counter(this.counter() + 1);\n  }\n\n  // Any component's method is available as a template helper in the template.\n  customHelper() {\n    if (this.counter() \u003e 10) {\n      return \"Too many times\";\n    }\n    else if (this.counter() === 10) {\n      return \"Just enough\";\n    }\n    else {\n      return \"Click more\";\n    }\n  }\n}\n\n// Register a component so that it can be included in templates. It also\n// gives the component the name. The convention is to use the class name.\nExampleComponent.register('ExampleComponent');\n```\n\n```handlebars\n\u003c!-- By default a template with the component's name will be used for the content. --\u003e\n\u003ctemplate name=\"ExampleComponent\"\u003e\n  \u003cbutton class=\"increment\"\u003eClick me\u003c/button\u003e\n  {{! You can include subtemplates to structure your templates. }}\n  {{\u003e subTemplate}}\n\u003c/template\u003e\n\n\u003c!-- We use camelCase to distinguish it from the component's template. --\u003e\n\u003ctemplate name=\"subTemplate\"\u003e\n  {{! You can access component's properties. }}\n  \u003cp\u003eCounter: {{counter}}\u003c/p\u003e\n  {{! And component's methods. }}\n  \u003cp\u003eMessage: {{customHelper}}\u003c/p\u003e  \n\u003c/template\u003e\n```\n\nYou can see how to [register a component](#user-content-reference_class_register), define a\n[template](#user-content-reference_instance_template), define a [life-cycle hook](#life-cycle-hooks),\n[event handlers](#user-content-reference_instance_events), and a custom helper as a component method.\n\nAll template helpers, methods, event handlers, life-cycle hooks have `this` bound to the component.\n\nJavaScript and CoffeeScript support\n-----------------------------------\n\nWhile documentation is in ES2015, Blaze Components are designed to be\nequally easy to use with vanilla JavaScript and CoffeeScript classes as well.\n\nExample above in vanilla JavaScript:\n\n```javascript\nvar ExampleComponent = BlazeComponent.extendComponent({\n  onCreated: function () {\n    Object.getPrototypeOf(ExampleComponent).prototype.onCreated.call(this);\n    this.counter = new ReactiveField(0);\n  },\n\n  events: function () {\n    return Object.getPrototypeOf(ExampleComponent).prototype.events.call(this).concat({\n      'click .increment': this.onClick\n    });\n  },\n\n  onClick: function (event) {\n    this.counter(this.counter() + 1);\n  },\n\n  customHelper: function () {\n    if (this.counter() \u003e 10) {\n      return \"Too many times\";\n    }\n    else if (this.counter() === 10) {\n      return \"Just enough\";\n    }\n    else {\n      return \"Click more\";\n    }\n  }\n}).register('ExampleComponent');\n```\n\nExample in CoffeeScript:\n\n```coffee\nclass ExampleComponent extends BlazeComponent\n  @register 'ExampleComponent'\n\n  onCreated: -\u003e\n    super\n    @counter = new ReactiveField 0\n\n  events: -\u003e\n    super.concat\n      'click .increment': @onClick\n\n  onClick: (event) -\u003e\n    @counter @counter() + 1\n\n  customHelper: -\u003e\n    if @counter() \u003e 10\n      \"Too many times\"\n    else if @counter() is 10\n      \"Just enough\"\n    else\n      \"Click more\"\n```\n\nAccessing data context\n----------------------\n\nBlaze Components are designed around the separation of concerns known as\n[model–view–controller](https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller) (MVC).\nController and its logic is implemented through a component. View is described through a template. And model is provided\nas a data context to a controller, a component.\n\nData context is often reactive. It often comes from a database using Meteor's reactive stack. Often as data context\nchanges, components stays rendered and just how it is rendered changes.\n\nWhen accessing values in a template, first component methods are searched for a property (with possible\n[mixins](#mixins-1)), then global template helpers, and lastly the data context.\n\nYou can provide a data context to a component when you are including it in the template.\n\nExamples:\n\n```handlebars\n{{\u003e MyComponent}}\n\n{{#with dataContext}}\n  {{\u003e MyComponent}}\n{{/with}}\n\n{{#each documents}}\n  {{\u003e MyComponent}}\n{{/each}}\n\n{{\u003e MyComponent dataContext}}\n\n{{\u003e MyComponent a='foo' b=helper}}\n```\n\n`dataContext`, `documents` and `helper` are template helpers, component's methods. If they are reactive, the data\ncontext is reactive.\n\nYou can access provided data context in your component's code through reactive\n[`data`](#user-content-reference_instance_data) and [`currentData`](#user-content-reference_instance_currentData)\nmethods. There is slight difference between those two. The former always returns component's data context, while\nthe latter returns the data context from where it was called. It can be different in template helpers and event\nhandlers.\n\nExample:\n\n```handlebars\n\u003ctemplate name=\"Buttons\"\u003e\n  \u003cbutton\u003eRed\u003c/button\u003e\n  {{color1}}\n  {{#with color='blue'}}\n    \u003cbutton\u003eBlue\u003c/button\u003e\n    {{color2}}\n  {{/with}}\n\u003c/template\u003e\n```\n\nIf top-level data context is `{color: \"red\"}`, then `currentData` inside a `color1` component method (template helper)\nwill return `{color: \"red\"}`, but inside a `color2` it will return `{color: \"blue\"}`. Similarly, click event handler on\nbuttons will by calling `currentData` get `{color: \"red\"}` as the data context for red button, and `{color: \"blue\"}` for\nblue button. In all cases `data` will return `{color: \"red\"}`.\n\nBecause [`data`](#user-content-reference_instance_data) and [`currentData`](#user-content-reference_instance_currentData)\nare both component's methods you can access them in a template as well. This is useful when you want to access\na data context property which is shadowed by a component's method.\n\nExample:\n\n```handlebars\n\u003ctemplate name=\"Colors\"\u003e\n  {{color}}\n  {{#with color='blue'}}\n    {{! If \"color\" is the component's method, this would resolve to the method, and not to the data context. }}\n    {{color}}\n    {{! If you want to make sure you are calling the component's method. }}\n    {{component.color}}\n    {{! To access the component's data context from an inner data context, use \"data\". }}\n    {{data.color}}\n    {{! Or first access the component. }}\n    {{component.data.color}}\n    {{! To access the current data context through the component method. }}\n    {{currentData.color}}\n    {{! Alternatively, you can also use keyword \"this\". }}\n    {{this.color}}\n  {{/with}}\n\u003c/template\u003e\n```\n\n*See [Spacebars documentation](https://github.com/meteor/meteor/blob/devel/packages/spacebars/README.md) for more\ninformation how to specify and work with the data context in templates.*\n\n*Specifying a data context to a component in the code will be provided through the\n[`renderComponent`](#user-content-reference_instance_renderComponent) method which is not yet public.*\n\nPassing arguments\n-----------------\n\nBlaze Components automatically instantiate an instance of a component when needed. In most cases you pass data to\na component as its data context, but sometimes you want to pass arguments to component's constructor. You can do\nthat as well with the special `args` syntax:\n\n```handlebars\n{{\u003e MyComponent args 'foo' key='bar'}}\n```\n\nBlaze Components will call `MyComponent`'s constructor with arguments `foo` and `Spacebars.kw({key: 'bar'})`\nwhen instantiating the component's class. Keyword arguments are wrapped into\n[`Spacebars.kw`](https://github.com/meteor/meteor/blob/devel/packages/spacebars/README.md#helper-arguments).\n\nCompare:\n\n```handlebars\n{{\u003e MyComponent key='bar'}}\n```\n\n`MyComponent`'s constructor is called without any arguments, but the data context of a component is set to\n`{key: 'bar'}`.\n\n```handlebars\n{{\u003e MyComponent}}\n```\n\n`MyComponent`'s constructor is called without any arguments and the data context is kept as it is.\n\nWhen you want to use a data context and when arguments depends on your use case and code structure. Sometimes your class\nis not used only as a component and requires some arguments to the constructor.\n\nA general rule of thumb is that if you want the component to persist while data used to render the component is changing,\nuse a data context. But if you want to reinitialize the component itself if your data changes, then pass that data\nthrough arguments. Component is always recreated when any argument changes. In some way arguments configure the\nlife-long properties of a component, which then uses data context reactively when rendering.\n\nAnother look at it is from the MVC perspective. Arguments configure the controller (component), while data\ncontext is the model. If data is coming from the database, it should probably be a data context.\n\n*Passing arguments to a component method which returns a component to be included, something like\n`{{\u003e getComponent args 'foo' key='bar'}}` is\n[not yet possible](https://github.com/peerlibrary/meteor-blaze-components/issues/12).*\n\nLife-cycle hooks\n----------------\n\nThere are multiple stages in the life of a component. In the common case it starts with a class which is\ninstantiated, rendered, and destroyed.\n\nLife-cycle hooks are called in order:\n\n1. Class [`constructor`](#user-content-reference_instance_constructor)\n2. [`mixinParent`](#user-content-reference_instance_mixinParent) (mixins only) – called on a mixin after it has been\ncreated to associate it with its component\n3. [`onCreated`](#user-content-reference_instance_onCreated) – called once a component is being created before being\ninserted into DOM\n4. [`onRendered`](#user-content-reference_instance_onRendered) – called once a rendered component is inserted into DOM\n5. [`onDestroyed`](#user-content-reference_instance_onDestroyed) – called once a component was removed from DOM and is\nbeing destroyed\n\nThe suggested use is that most of the component related initialization should be in\n[`onCreated`](#user-content-reference_instance_onCreated) and [`constructor`](#user-content-reference_instance_constructor)\nshould be used for possible other uses of the same class. [`constructor`](#user-content-reference_instance_constructor)\ndoes receive [optional arguments](#passing-arguments) though.\n\n[Mixins](#mixins-1) share life-cycle with the component and their life-cycle hooks are called automatically\nby Blaze Components.\n\n*Life-cycle of a component is is the common case linked with its life in the DOM. But you can create an instance of\na component which you can keep a reference to and reuse it multiple times, thus keeping its state between multiple\nrenderings. You can do this using the [`renderComponent`](#user-content-reference_instance_renderComponent) method\nwhich is not yet public.*\n\nHandling events\n---------------\n\nThere are two ways to handle DOM events in Blaze Components. The first is by using\n[event maps](#user-content-reference_instance_events) in a similar way how you would bind event handlers in Blaze\nor jQuery.\n\nThe issue is that using event maps is error prone. Your selector can match too much, or too\nlittle, especially when component's template is changed in the future. Furthermore, event maps invert the relationship\nbetween templates and components. Observe how components provide template helpers to templates and how you define\nin the template itself how those template helpers are mapped to the template. Logic stays in the component, but\nwhere exactly the template helper is used is defined in the template. If you are modifying the template, you can\neasily see how you have to move template helpers around to keep the template working. With event maps this is\ninverted. You often have to define custom CSS classes to allow event handlers to be bound to the DOM element\nand later on is unclear how those CSS classes are connected to the event handlers. If you are modifying the template\nyou have to be careful to maintain correct mapping of event handlers.\n\nBlaze Components provide an alternative approach. You can define event handlers as component's methods and they\nare available to you to bind them to DOM elements in the template directly. The recommended approach is to name event\nhandlers based on which element they are handling and not what they are doing:\n\n```handlebars\n\u003ctemplate name=\"ExampleComponent\"\u003e\n  \u003cbutton onClick={{onButtonClick}}\u003eClick me\u003c/button\u003e\n\u003c/template\u003e\n```\n\n```javascript\nclass ExampleComponent extends BlazeComponent {\n  onCreated() {\n    super.onCreated();\n    this.counter = new ReactiveField(0);\n  }\n\n  onButtonClick(event) {\n    this.counter(this.counter() + 1);\n    this.callFirstWith(this, 'onButtonClick', event);\n  }\n\n  customHelper() {\n    if (this.counter() \u003e 10) {\n      return \"Too many times\";\n    }\n    else if (this.counter() === 10) {\n      return \"Just enough\";\n    }\n    else {\n      return \"Click more\";\n    }\n  }\n}\n```\n\nBlaze Components will recognize as an event binding attribute any element attribute beginning with `on` followed by a event name starting with a capital letter.\nIn these examples, `onClick` is recognized as a binding for the `click` event, but `onclick` would be passed on as it is as an attribute to the DOM. `onKeyup` would be recognized as a binding for the `keyup` event, and so on.\n\nMoreover, observe the [`callFirstWith`](#user-content-reference_instance_callFirstWith) call. This allows\n[mixins](#mixins-1) to hook into the same event. Only the first resolved event handler with a given name is\ncalled and any other event handlers with the same name are not called automatically for events bound in templates.\n\nWhile it is recommended that you define only one event handler per event per element and then do multiple actions\ninside the component's code, you can still use the following syntax to bind multiple event handlers:\n\n```handlebars\n\u003ctemplate name=\"ExampleComponent\"\u003e\n  \u003cbutton onClick=\"{{onClick1}} {{onClick2}}\"\u003eClick me\u003c/button\u003e\n\u003c/template\u003e\n```\n\nIf you do not provide the name of the event handler, the name of the event is used instead. This will call `onClick`\nmethod on the component for every `click` event on the button:\n\n```handlebars\n\u003ctemplate name=\"ExampleComponent\"\u003e\n  \u003cbutton onClick\u003eClick me\u003c/button\u003e\n\u003c/template\u003e\n```\n\nFurthermore, when using a template helper to return a\n[dynamic set of attributes](https://github.com/meteor/meteor/blob/devel/packages/spacebars/README.md#dynamic-attributes),\nif any of those attributes are named like an event, the value will be bound as a event handler (or multiple of those\nif the value is an array):\n\n```handlebars\n\u003ctemplate name=\"ExampleComponent\"\u003e\n  \u003cbutton {{attrs}}\u003eClick me\u003c/button\u003e\n\u003c/template\u003e\n```\n\n```javascript\nclass ExampleComponent extends BlazeComponent {\n  /* ... */\n  \n  attrs() {\n    return {\n      onClick: this.onButtonClick,\n      title: \"Button title\"\n    }\n  }\n}\n```\n\nYou can also pass custom arguments to the event handlers:\n\n```handlebars\n\u003ctemplate name=\"ExampleComponent\"\u003e\n  \u003cbutton onClick={{onButtonClick 'first'}}\u003eClick me\u003c/button\u003e\n  \u003cbutton onClick={{onButtonClick 'second'}}\u003eClick me\u003c/button\u003e\n\u003c/template\u003e\n```\n\n```javascript\nonButtonClick(event, argument) {\n  this.counter(this.counter() + 1);\n  this.callFirstWith(this, 'onButtonClick', event, argument);\n}\n```\n\nThose arguments can even be reactive.\n\nComponent-based block helpers\n-----------------------------\n\nYou can use Blaze Components to define block helpers as well.\n\nExample:\n\n```handlebars\n\u003ctemplate name=\"TableWrapperBlockComponent\"\u003e\n  \u003ctable\u003e\n    \u003cthead\u003e\n      \u003ctr\u003e\n        \u003cth\u003eName\u003c/th\u003e\n        \u003cth\u003eEmail\u003c/th\u003e\n      \u003c/tr\u003e\n    \u003c/thead\u003e\n    \u003ctbody\u003e\n      {{\u003e Template.contentBlock}}\n    \u003c/tbody\u003e\n    \u003ctfoot\u003e\n      \u003ctr\u003e\n        \u003ctd colspan=\"2\"\u003e\n          {{\u003e Template.elseBlock}}\n        \u003c/td\u003e\n      \u003c/tr\u003e\n    \u003c/tfoot\u003e\n  \u003c/table\u003e\n\u003c/template\u003e\n```\n\n```handlebars\n{{#TableWrapperBlockComponent}}\n  {{#each customers}}\n    \u003ctd\u003e{{name}}\u003c/td\u003e\n    \u003ctd\u003e{{email}}\u003c/td\u003e\n  {{/each}}\n{{else}}\n  \u003cp class=\"copyright\"\u003eContent available under the CC0 license.\u003c/p\u003e\n{{/TableWrapperBlockComponent}}\n```\n\nYou can use [`Template.contentBlock` and `Template.elseBlock`](https://github.com/meteor/meteor/blob/devel/packages/spacebars/README.md#custom-block-helpers)\nto define \"content\" and \"else\" inclusion points.\n\nYou can modify just block helpers data context by passing it in the tag:\n\n```handlebars\n\u003ctemplate name=\"TableWrapperBlockComponent\"\u003e\n  \u003ctable class=\"{{color}}\"\u003e\n...\n```\n\n```handlebars\n{{#TableWrapperBlockComponent color='red'}}\n...\n```\n\nNotice that block helper's data context is available only inside a block helper's template, but data context where\nit is used (one with `customers`) stays the same. On the other hand, wrapping template content with a block\nhelper component does change what [`currentComponent`](#user-content-reference_instance_currentComponent) returns:\nit returns the block helper component instance. In a way you can still access the block helper's data context\nthrough its component's instance (and [`data`](#user-content-reference_instance_data)).\n\nWhen working with block helper components it is important to remember: block helper's data context is hidden\nwhen traversing the tree of data contexts, but the block helper's component is available in the component tree\nas the parent of any components included inside the block helper's content, both the content of the\nblock helper's component itself, and the content wrapped with the block helper.\n\nYou can also [pass arguments](#passing-arguments) to a component:\n\n```handlebars\n{{#TableWrapperBlockComponent args displayCopyright=false}}\n...\n```\n\nFor when to use a data context and when arguments the same rule of thumb from the [Passing arguments](#passing-arguments)\nsection applies.\n\nBlaze provides up to two inclusion points in block helpers. If you need more you should probably not use a component\nas a block helper but move the logic to the component's method, returning a rendered Blaze Component instance or template\nwhich provides any content you want. You can provide content (possibly as Blaze Components themselves) to the component\nthrough your component arguments or data context.\n\nExample:\n\n```handlebars\n\u003ctemplate name=\"CaseComponent\"\u003e\n  {{\u003e renderCase}}\n\u003c/template\u003e\n\n\u003ctemplate name=\"useCaseTemplate\"\u003e\n  {{\u003e CaseComponent args left='LeftComponent' middle='MiddleComponent' right='RightComponent'}}\n\u003c/template\u003e\n```\n\n```javascript\nclass CaseComponent extends BlazeComponent {\n  constructor(kwargs) {\n    super();\n\n    this.cases = kwargs.hash;\n  }\n\n  renderCase() {\n    let caseComponent = this.cases[this.data().case];\n    if (!caseComponent) return null;\n    return BlazeComponent.getComponent(caseComponent).renderComponent(this.currentComponent());\n  }\n}\n\nCaseComponent.register('CaseComponent');\n```\n\nIf you use `CaseComponent` now in the `{case: 'left'}` data context, a `LeftComponent`\ncomponent will be rendered. If you want to control in which data context `LeftComponent`\nis rendered, you can specify data context as `{{\u003e renderCase dataContext}}`.\n\n*Example above is using [`renderComponent`](#user-content-reference_instance_renderComponent) method which is not yet public.*\n\nAnimations\n----------\n\nBlaze Components provide [low-level DOM manipulation hooks](#low-level-dom-manipulation-hooks) you can use to\nhook into insertion, move, or removal of DOM elements. Primarily you can use this to animate manipulation of\nDOM elements, but at the end you have to make sure you do the requested DOM manipulation correctly because Blaze\nwill expect it done.\n\nHooks are called only when DOM elements themselves are manipulated and not when their attributes change.\n\nA common pattern of using the hooks is to do the DOM manipulation as requested immediately, to the final state, and\nthen only visually instantaneously revert to the initial state and then animate back to the final state. For example,\nto animate move of a DOM element you can first move the DOM element to the new position, and then use CSS translation\nto visually move it back to the previous position and then animate it slowly to the new position. The DOM element itself\nstays in the new position all the time in the DOM, only visually is being translated to the old position and animated.\n\nOne way for animating is to modify CSS, like toggling a CSS class which enables animations. Another common way\nis to use a library like [Velocity](http://julian.com/research/velocity/).\n\nAnimations are best provided as [reusable mixins](#mixins-1). But for performance reasons the default\nimplementation of [`insertDOMElement`](#user-content-reference_instance_insertDOMElement),\n[`moveDOMElement`](#user-content-reference_instance_moveDOMElement), and\n[`removeDOMElement`](#user-content-reference_instance_removeDOMElement) just performs the manipulation and does not\ntry to call mixins. So for components where you want to enable mixin animations for, you should extend those methods\nwith something like:\n\n```javascript\ninsertDOMElement(parent, node, before, next) {\n  next = next || () =\u003e {\n    super.insertDOMElement(parent, node, before);\n    return true;\n  }\n\n  if (!this.callFirstWith(this, 'insertDOMElement', parent, node, before, next)) {\n    return next();\n  }\n\n  // It has been handled.\n  return true;\n}\n\nmoveDOMElement(parent, node, before, next) {\n  next = next || () =\u003e {\n    super.moveDOMElement(parent, node, before);\n    return true;\n  }\n\n  if (!this.callFirstWith(this, 'moveDOMElement', parent, node, before, next)) {\n    return next();\n  }\n\n  // It has been handled.\n  return true;\n}\n\nremoveDOMElement(parent, node, next) {\n  next = next || () =\u003e {\n    super.removeDOMElement(parent, node);\n    return true;\n  }\n\n  if (!this.callFirstWith(this, 'removeDOMElement', parent, node, next)) {\n    return next();\n  }\n\n  // It has been handled.\n  return true;\n}\n```\n\nYour method should return `true` if it has handled insertion/move/removal of the DOM element.\n\n*See [Momentum Meteor package](https://github.com/percolatestudio/meteor-momentum) for more information on how to\nuse these hooks to animate DOM elements.*\n\nMixins\n------\n\nBlaze Components are designed around the [composition over inheritance](http://en.wikipedia.org/wiki/Composition_over_inheritance)\nparadigm. JavaScript is a single-inheritance language and instead of Blaze Components trying to force fake\nmultiple-inheritance onto a language, it offers a\n[set of utility methods](https://github.com/peerlibrary/meteor-blaze-components/#mixins-1) which allow the component to\ninteract with its mixins and mixins with the component. The code becomes more verbose because of the use of methods\ninstead of overloading, overriding or extending the existing elements of the language or objects, but we believe that\nresults are easier to read, understand, and maintain.\n\nEach mixin becomes its own JavaScript object with its own state, but they share a life-cycle with the component.\nMost commonly mixin is an instance of a provided mixin class.\n\nA contrived example to showcase various features of mixins:\n\n```javascript\nclass MyComponent extends BlazeComponent {\n  mixins() {\n    return [FirstMixin, new SecondMixin('foobar')];\n  }\n\n  alternativeName() {\n    return this.callFirstWith(null, 'templateHelper');\n  }\n\n  values() {\n    return 'a' + (this.callFirstWith(this, 'values') || '');\n  }\n}\n\nMyComponent.register('MyComponent');\n\nclass FirstMixinBase extends BlazeComponent {\n  templateHelper() {\n    return \"42\";\n  }\n\n  extendedHelper() {\n    return 1;\n  }\n\n  onClick() {\n    if (this.values() !== this.valuesPrediction) throw new Error();\n  }\n}\n\nclass FirstMixin extends FirstMixinBase {\n  extendedHelper() {\n    return super.extendedHelper() + 2;\n  }\n\n  values() {\n    return 'b' + (this.mixinParent().callFirstWith(this, 'values') || '');\n  }\n\n  dataContext() {\n    return EJSON.stringify(this.data());\n  }\n\n  events() {\n    return super.events().concat({\n      'click': this.onClick\n    });\n  }\n\n  onCreated() {\n    super.onCreated();\n    this.valuesPrediction = 'bc';\n  }\n}\n\nclass SecondMixin {\n  constructor(name) {\n    super();\n\n    this.name = name;\n  }\n\n  mixinParent(mixinParent) {\n    if (mixinParent) this._mixinParent = mixinParent;\n    return this._mixinParent;\n  }\n\n  values() {\n    return 'c' + (this.mixinParent().callFirstWith(this, 'values') || '');\n  }\n}\n```\n\n```handlebars\n\u003ctemplate name=\"MyComponent\"\u003e\n  \u003cp\u003ealternativeName: {{alternativeName}}\u003c/p\u003e\n  \u003cp\u003evalues: {{values}}\u003c/p\u003e\n  \u003cp\u003etemplateHelper: {{templateHelper}}\u003c/p\u003e\n  \u003cp\u003eextendedHelper: {{extendedHelper}}\u003c/p\u003e\n  \u003cp\u003ename: {{name}}\u003c/p\u003e\n  \u003cp\u003edataContext: {{dataContext}}\u003c/p\u003e\n\u003c/template\u003e\n```\n\nWhen this component is rendered using the `{top: '42'}` as a data context, it is rendered as:\n\n```html\n\u003cp\u003ealternativeName: 42\u003c/p\u003e\n\u003cp\u003evalues: abc\u003c/p\u003e\n\u003cp\u003etemplateHelper: 42\u003c/p\u003e\n\u003cp\u003eextendedHelper: 3\u003c/p\u003e\n\u003cp\u003ename: foobar\u003c/p\u003e\n\u003cp\u003edataContext: {\"top\":\"42\"}\u003c/p\u003e\n```\n\nWe can visualize class structure and mixins.\n\n![Example mixins visualization](https://cdn.rawgit.com/peerlibrary/meteor-blaze-components/master/mixins.svg)\n\nFull lines represent JavaScript inheritance. Dashed lines represent mixins relationships based\non the order of mixins specified.\n\nLet's dissect the example.\n\nAs we can see all methods become template helpers and they are searched for in the normal order, first the\ncomponent, then mixins. On the diagram from left to right. First implementation found is called. If the\nimplementation wants to continue with the traversal it can do it by itself, probably using\n[`callFirstWith`](#user-content-reference_instance_callFirstWith).\n\n```javascript\nmixins() {\n  return [FirstMixin, new SecondMixin('foobar')];\n}\n```\n\nWe can see that mixins can be also already made instances. And that mixins do not have to extend\n`BlazeComponent`. You get some methods for free, but you can use whatever you want to provide your features.\n\n```javascript\nalternativeName() {\n  return this.callFirstWith(null, 'templateHelper');\n}\n```\n\nWa call [`callFirstWith`](#user-content-reference_instance_callFirstWith) with `null` which makes it traverse\nthe whole structure, the component and all mixins, when searching for the first implementation of `templateHelper`.\n\nThis allows us to not assume much about where the `templateHelper` is implemented. But be careful, if `templateHelper`\nwould do the same back, calling the `alternativeName` on the whole structure, you might get into an inifinite loop.\n\nOn the diagram of our example, this starts traversal on `MyComponent`, checking for the `templateHelper` on\nits instance through JavaScript inheritance. Afterwards it moves to `FirstMixin`, looking at its\ninstance and its inheritance parent, where it finds it.\n\n```javascript\nvalues() {\n  return 'a' + (this.callFirstWith(this, 'values') || '');\n}\n```\n\n`values` method is passing `this` to [`callFirstWith`](#user-content-reference_instance_callFirstWith), signaling that only\nmixins after the component should be traversed.\n\nThis is a general pattern for traversal which all `values` methods in this example use. Similar to how you would use\n`super` call in inheritance. `values` methods add their own letter to the result and ask later mixins for possible\nmore content.\n\nCalling [`callFirstWith`](#user-content-reference_instance_callFirstWith) in this way traverses the structure from\nthe left to the right on the diagram of our example, one implementation of `values` after another. First, `values`\nmethod from `MyComponent` component is found. This method calls [`callFirstWith`](#user-content-reference_instance_callFirstWith)\nwhich continues searching on `FirstMixin`, where it is found again. That method calls\n[`callFirstWith`](#user-content-reference_instance_callFirstWith), which now finds `values` again, this time on\n`SecondMixin`. Call from the `SecondMixin` does not find any more implementations. The result is thus:\n\n```javascript\n'a' + ('b' + ('c' + ''))\n```\n\n```javascript\nonClick() {\n  if (this.values() !== this.valuesPrediction) throw new Error();\n}\n```\n\nEvent handlers (and all other methods) have `this` bound to the mixin instance, not the component. Here we can see\nhow the event handler can access `values` and `valuesPrediction` on mixin's instance and how normal JavaScript\ninheritance works between `FirstMixinBase` and `FirstMixin`.\n\nEvent handlers are independent from other mixins and the component's event handlers. They are attached to DOM in the\nnormal traversal order, first the component's, then mixins'. \n\nTo control how events are propagated between the component and mixins you can use `event` object methods like\n[`stopPropagation`](https://api.jquery.com/event.stopPropagation/) and\n[`stopImmediatePropagation`](https://api.jquery.com/event.stopImmediatePropagation/).\n\n```javascript\nextendedHelper() {\n  return super.extendedHelper() + 2;\n}\n```\n\nYou can use normal JavaScript inheritance in your mixins. On the diagram of our example `super` traverses\nupwards.\n\n```javascript\ndataContext() {\n  return EJSON.stringify(this.data());\n}\n```\n\nThe method to access the data context used for the component automatically first finds the mixin's component and\nthen accesses its data context. All Blaze Components methods which can operate only on components and not mixins\nautomatically assure that they are called on the mixin's component. For methods which can operate on both components\nand mixins this is not done automatically. You should first call [`component`](#user-content-reference_instance_component)\nto get an instance of the mixin's component and then call the method on it.\n\n```javascript\nonCreated() {\n  super.onCreated();\n  this.valuesPrediction = 'bc';\n}\n```\n\nMixin's life-cycle matches that of the component and mixin's life-cycle hooks are automatically called by Blaze\nComponents when the component is [created](#user-content-reference_instance_onCreated),\n[rendered](#user-content-reference_instance_onRendered), and [destroyed](#user-content-reference_instance_onDestroyed).\n`this` is bound to the mixin instance.\n\n```javascript\nmixinParent(mixinParent) {\n  if (mixinParent) this._mixinParent = mixinParent;\n  return this._mixinParent;\n}\n```\n\nBecause `SecondMixin` does not extend `BlazeComponent` we have to provide the\n[`mixinParent`](#user-content-reference_instance_mixinParent) method ourselves. It is called by the Blaze Components\nas a setter to tell the mixin what its component instance is.\n\n[`mixinParent`](#user-content-reference_instance_mixinParent) is a good place to add any dependencies to the\ncomponent your mixin might need. Extend it and your additional logic.\n\nExample:\n\n```javascript\nmixinParent(mixinParent) {\n  if (mixinParent) mixinParent.requireMixin(DependencyMixin);\n  return super.mixinParent(mixinParent);\n}\n```\n\nDon't forget to call `super`.\n\n*See the [tutorial](http://components.meteor.com/#the-cooperation) for a more real example of mixins.*\n\nNamespaces\n----------\n\nAs your project grows and you are using more and more components, especially from 3rd party packages, flat\nstructure of components (and templates) might lead to interference. To address this issue Blaze Components\nprovide multi-level namespacing, with `.` character as a separator.\n\nExample:\n\n```javascript\nclass Buttons {}\n\nButtons.Red = class Red extends BlazeComponent {}\n\nButtons.Red.register('Buttons.Red');\n\nButtons.Blue = class Blue extends BlazeComponent {}\n\nButtons.Blue.register('Buttons.Blue');\n```\n\n```handlebars\n{{\u003e Buttons.Red}}\n```\n\nYou do not have to export `Buttons` from your package for components to be available in templates throughout your\nproject. The registry of components is shared between all packages and the project. Even if you need to access a\ncomponent's class in your code, you can use `BlazeComponent.getComponent('Buttons.Red')` to access it.\n\nSometimes you want some non-component logic to be available together with your components. You can export\none symbol and nest components under it like in the example above, having access to both non-component logic\nthrough that symbol, and components through Blaze Components registry.\n\nOn the other hand, you do not even have to [register](#user-content-reference_class_register) components to use them.\nBut then you have to get them into templates through some other means, for example, using some other component's\ntemplate helper (method). Remember though that Meteor has a global namespace for all template names, so probably you\nwant to use namespaced template names in large projects or packages you publish even if you are not registering\ncomponents.\n\nLet's imagine thar your package exports `Buttons` class above. Then you could do:\n\n```handlebars\n\u003ctemplate name=\"OtherComponent\"\u003e\n  {{\u003e renderButton}}\n\u003c/template\u003e\n```\n\n```javascript\nclass OtherComponent extends BlazeComponent {\n  renderButton() {\n    return Buttons.Red.renderComponent(this.currentComponent());\n  }\n}\n\nOtherComponent.register('OtherComponent');\n```\n\nIf you would leave your components registered, you could still do:\n\n```javascript\nrenderButton() {\n  return BlazeComponent.getComponent('Buttons.Red').renderComponent(this.currentComponent());\n}\n```\n\nYou do not even have to create a namespacing class in your code like we did in the example above. It does make the\ncode more readable and uniform, though.\n\nHow exactly you structure your code and components depends on various factors. Blaze Components provide multiple\nways to keep your components structured, tidy, and reusable.\n\n*Example above is using [`renderComponent`](#user-content-reference_instance_renderComponent) method which is not yet public.*\n\nServer side rendering\n---------------------\n\nBlaze Components support rendering on the server side as well. You can use\n[`renderComponentToHTML`](#user-content-reference_instance_renderComponentToHTML) method to render the Blaze Component\nto a HTML string. For Blaze Components to work well on the server side they have to use pure Blaze reactivity\nto render its content, and do not manipulate rendered DOM in the [`onRendered`](#user-content-reference_instance_onRendered)\nlife-cycle hook (the hook is not even called when using `renderComponentToHTML`). Such Blaze Components are recommended\nanyway: use instance-bound reactive variables to keep the component's state and manipulate those variables to change how\nthe component is rendered by Blaze. For animations and other special effects, use Blaze Components'\n[support for animations](#animations) (animations are not called when rendering to a HTML string, too).\n\nBecause it is possible to use Blaze Components on both client and server side it is important to be conscious\nto which target(s) you add HTML template file and Blaze Component code file for your Blaze Component. In general\nit is not a problem if you add files to the server side even if you do not plan to use Blaze Components on the server\nside, but be careful to not expose server side only components to your clients.\n\nAs a [reminder](http://docs.meteor.com/#/full/structuringyourapp), put files into the `client` directory in your app if\nyou want them to be available only on the client side, into the `server` directory if you want them to be available only\non the server side, and elsewhere (like `lib` directory) if you want them to be available both on the client and server\nside. For packages, use `architecture` argument to your [`addFiles`](http://docs.meteor.com/#/full/pack_addFiles) calls\nto control where are added files available, `'client'`, `'server'`, and `['client', 'server']`, respectivelly.\n\nUse with existing classes\n-------------------------\n\nBlaze Components are designed to work with existing class hierarchies. There are no restrictions on class constructor,\nfor example. In fact, Blaze Components can be seen simply as an API a class or object has to provide to be compatible\nwith the system. The easiest way to bootstrap your class hierarchy is to copy default implementations from\n`BlazeComponent` to your class.\n\nExample:\n\n```javascript\nfor (let property in BlazeComponent) {\n  if (!(property in YourBaseClass)) continue;\n  YourBaseClass[property] = BlazeComponent[property];\n}\n\nfor (let property in BlazeComponent.prototype) {\n  if (!(property in YourBaseClass.prototype)) continue;\n  YourBaseClass.prototype[property] = BlazeComponent.prototype[property];\n}\n```\n\nReference\n---------\n\n### Class methods ###\n\n\u003ca name=\"reference_class_register\"\u003e\u003c/a\u003e\n```javascript\nstatic register(componentName, [componentClass])\n```\n\nRegisters a new component with the name `componentName`. This makes it available in templates and elsewhere\nin the component system under that name, and assigns the name to the component. If `componentClass`\nargument is omitted, class on which `register` is called is used.\n\n\u003ca name=\"reference_class_getComponent\"\u003e\u003c/a\u003e\n```javascript\nstatic getComponent(componentName)\n```\n\nRetrieves the component class with `componentName` name. If such component does not exist, `null` is returned.\n\n\u003ca name=\"reference_class_getComponentForElement\"\u003e\u003c/a\u003e\n```javascript\nstatic getComponentForElement(domElement)\n```\n\nReturns a component instance used to render a particular DOM element, if it was rendered using Blaze Components.\nOtherwise `null`.\n\n\u003ca name=\"reference_class_currentData\"\u003e\u003c/a\u003e\n```javascript\nstatic currentData([path], [equalsFunc])\n```\n\nThis is a complementary class method to the [`currentData`](#user-content-reference_instance_currentData)\ninstance method. Use it when you do not have a component instance available.\n\n\u003ca name=\"reference_class_currentComponent\"\u003e\u003c/a\u003e\n```javascript\nstatic currentComponent()\n```\n\nThis is a complementary class method to the [`currentComponent`](#user-content-reference_instance_currentComponent)\ninstance method. Use it when you do not have a component instance available.\n\n\u003ca name=\"reference_class_componentName\"\u003e\u003c/a\u003e\n```javascript\nstatic componentName([componentName])\n```\n\nWhen called without a `componentName` argument it returns the component name.\n\nWhen called with a `componentName` argument it sets the component name.\n\n*Setting the component name yourself is needed and required only for unregistered classes because\n[`register`](#user-content-reference_class_register) sets the component name automatically otherwise. All component\nshould have a component name associated with them.*\n\n\u003ca name=\"reference_class_extendComponent\"\u003e\u003c/a\u003e\n```javascript\nstatic extendComponent([constructor], methods)\n```\n\nA helper method to extend a component into a new component when using vanilla JavaScript. It configures\nprototype-based inheritance and assigns properties and values from `methods` to the prototype of the new component.\nIt accepts an optional `constructor` function to be used instead of a default one which just calls the constructor\nof the parent component.\n\nInside a method you can use `this.constructor` to access the class. Parent class prototype is available at\n`Object.getPrototypeOf(this.constructor).prototype`. You can use it to do `super` calls.\n\nExample (in vanilla JavaScript):\n\n```javascript\nvar OurComponent = MyComponent.extendComponent({\n  values: function () {\n    return '\u003e\u003e\u003e' + Object.getPrototypeOf(OurComponent).prototype.values.call(this) + '\u003c\u003c\u003c';\n  }\n});\n```\n\nIn ES2015 and CoffeeScript you do not have to use `Object.getPrototypeOf(this.constructor).prototype` but can use\nlanguages' `super`.\n\n\u003ca name=\"reference_class_renderComponent\"\u003e\u003c/a\u003e\n```javascript\nstatic renderComponent([parentComponent])\n```\n\nThis is a complementary class method to the [`renderComponent`](#user-content-reference_instance_renderComponent)\ninstance method. It automatically instantiates the component before calling `renderComponent` on it.\n\n*Despite being documented, `renderComponent` method is not yet considered public and is subject to change.*\n\n\u003ca name=\"reference_class_renderComponentToHTML\"\u003e\u003c/a\u003e\n```javascript\nstatic renderComponentToHTML([parentComponent], [parentView], [data])\n```\n\nThis is a complementary class method to the [`renderComponentToHTML`](#user-content-reference_instance_renderComponentToHTML)\ninstance method. It automatically instantiates the component before calling `renderComponentToHTML` on it.\n\n### Instance methods ###\n\n#### Event handlers ####\n\n\u003ca name=\"reference_instance_events\"\u003e\u003c/a\u003e\n```javascript\nevents()\n```\n\nExtend this method and return event hooks for the component's DOM content. Method should return an array of event maps,\nwhere an event map is an object where the properties specify a set of events to handle, and the values are the\nhandlers for those events. The property can be in one of several forms:\n\n* `eventtype` – Matches a particular type of event, such as `click`.\n* `eventtype selector` – Matches a particular type of event, but only when it appears on an element that matches a\ncertain CSS selector.\n* `event1, event2` – To handle more than one type of event with the same function, use a comma-separated list.\n\nThe handler function receives one argument, a [jQuery event object](https://api.jquery.com/category/events/event-object/),\nand optional extra arguments for custom events. The common pattern is to simply pass methods as event handlers to allow\nsubclasses to extend the event handlers logic through inheritance.\n\nBy default the method returns [preexisting event handlers](http://docs.meteor.com/#/full/template_events) defined on the\ntemplate returned from the [`template`](#user-content-reference_instance_template) method call.\n\nExample:\n\n```javascript\nevents() {\n  return super.events().concat({\n    'click': this.onClick,\n    'click .accept': this.onAccept,\n    'click .accept, focus .accept, keypress': this.onMultiple\n  });\n}\n   \n// Fires when any element is clicked.\nonClick(event) {\n}\n\n// Fires when any element with the \"accept\" class is clicked.\nonAccept(event) {\n}\n\n// Fires when 'accept' is clicked or focused, or a key is pressed.\nonMultiple(event) {\n}\n```\n\nBlaze Components make sure that event handlers are called bound with the component itself in `this`.\nThis means you can [normally access data context and the component itself](#access-to-data-context-and-components)\nin the event handler.\n\nWhen extending this method make sure to not forget about possible ancestor event handlers you can get through\nthe `super` call. Concatenate additional event handlers in subclasses and/or modify ancestor event handlers before\nreturning them all. This is also the reason why the method has to return an array. There might be multiple handlers\nfor the same event specification (eg., multiple handlers to handle `click` event) and we do not want them to be\nclobbered.\n\nReturned values from event handlers are ignored. To control how events are propagated you can use `event` object\nmethods like [`stopPropagation`](https://api.jquery.com/event.stopPropagation/) and\n[`stopImmediatePropagation`](https://api.jquery.com/event.stopImmediatePropagation/).\n\nIt is a good practice to always call parent class method using `super`.\n\nWhen [mixins](#mixins-1) provide event handlers, they are attached in order of mixins, with the component first.\n\n*For more information about event maps, event handling, and `event` object, see [Blaze documentation](http://docs.meteor.com/#/full/eventmaps)\nand [jQuery documentation](https://api.jquery.com/category/events/event-object/).*\n\n#### DOM content ####\n\n\u003ca name=\"reference_instance_template\"\u003e\u003c/a\u003e\n```javascript\ntemplate()\n```\n\nExtend this method and return the name of a [Blaze template](http://docs.meteor.com/#/full/templates_api) or template\nobject itself. By default it returns the [component name](#user-content-reference_class_componentName).\n\nTemplate content will be used to render component's DOM content.\n\nAll component methods (properties, more precisely) are available in the template as template helpers. Template helpers\nare bound to the component itself in `this`.\n\nIt is recommended that you use templates only to specify DOM content and that you do not define any template helpers,\nevent handlers, and life-cycle hooks on the template itself but instead define it at the component level. But to support\nwrapping existing templates into Blaze Components so that you can extend or override their behavior, Blaze Components\nreuse template helpers, event handlers, and life-cycle hooks from the template in a backwards compatible way. Preexisting\ntemplate helpers are searched if the component does not have a property with the requested helper name. Preexisting\nevent handlers are returned from the default [`events`](#user-content-reference_instance_events) method.\nDefault [life-cycle hooks](#life-cycle-hooks-1) methods call template's preexisting life-cycle hooks as well.\n\nYou can include other templates (to keep individual templates manageable) and components.\n\nConvention is to name component templates the same as components, which are named the same as their classes.\nAnd because components are classes, they start with an upper-case letter, TitleCase.\n\nWhen [mixins](#mixins-1) provide `template` method, the component's default implementation first calls them\nand only if mixins do not provide a template, [component name](#user-content-reference_class_componentName) is used\ninstead.\n\n*See [Spacebars documentation](http://docs.meteor.com/#/full/templates_api) for more information about the template\nlanguage.*\n\n#### Access to rendered content ####\n\n\u003ca name=\"reference_instance_$\"\u003e\u003c/a\u003e\n```javascript\n$(selector)\n```\n\nFinds all DOM elements matching the `selector` in the rendered content of the component, and returns them\nas a [JQuery object](https://api.jquery.com/Types/#jQuery).\n\nThe component serves as the document root for the selector. Only elements inside the component and its\nsub-components can match parts of the selector.\n\n*Wrapper around [Blaze's `$`](http://docs.meteor.com/#/full/template_$).*\n\n\u003ca name=\"reference_instance_find\"\u003e\u003c/a\u003e\n```javascript\nfind(selector)\n```\n\nFinds one DOM element matching the `selector` in the rendered content of the component, or returns `null`\nif there are no such elements.\n\nThe component serves as the document root for the selector. Only elements inside the component and its\nsub-components can match parts of the selector.\n\n*Wrapper around [Blaze's `find`](http://docs.meteor.com/#/full/templƒate_find).*\n\n\u003ca name=\"reference_instance_findAll\"\u003e\u003c/a\u003e\n```javascript\nfindAll(selector)\n```\n\nFinds all DOM element matching the `selector` in the rendered content of the component. Returns an array.\n\nThe component serves as the document root for the selector. Only elements inside the component and its\nsub-components can match parts of the selector.\n\n*Wrapper around [Blaze's `findAll`](http://docs.meteor.com/#/full/template_findAll).*\n\n\u003ca name=\"reference_instance_firstNode\"\u003e\u003c/a\u003e\n```javascript\nfirstNode()\n```\n\nReturns the first top-level DOM node in the rendered content of the component.\n\nThe two nodes `firstNode` and `lastNode` indicate the extent of the rendered component in the DOM. The rendered\ncomponent includes these nodes, their intervening siblings, and their descendents. These two nodes are siblings\n(they have the same parent), and `lastNode` comes after `firstNode`, or else they are the same node.\n\n*Wrapper around [Blaze's `firstNode`](http://docs.meteor.com/#/full/template_firstNode).*\n\n\u003ca name=\"reference_instance_lastNode\"\u003e\u003c/a\u003e\n```javascript\nlastNode()\n```\n\nReturns the last top-level DOM node in the rendered content of the component.\n\n*Wrapper around [Blaze's `lastNode`](http://docs.meteor.com/#/full/template_lastNode).*\n\n#### Access to data context and components ####\n\n\u003ca name=\"reference_instance_data\"\u003e\u003c/a\u003e\n```javascript\ndata([path], [equalsFunc])\n```\n\nReturns current component-level data context. A reactive data source.\n\nIf `path` is provided, it returns only the value under the path. It uses\n[data-lookup](https://github.com/peerlibrary/meteor-data-lookup) package to resolve the path. Moreover, this limits\nreactivity only to changes of that value and not the whole data context.\n\nUse this to always get the top-level data context used to render the component.\n\n\u003ca name=\"reference_instance_currentData\"\u003e\u003c/a\u003e\n```javascript\ncurrentData([path], [equalsFunc])\n```\n\nReturns current caller-level data context. A reactive data source.\n\nIn [event handlers](#event-handlers) use `currentData` to get the data context at the place where the event originated (target context).\nIn template helpers `currentData` returns the data context where a template helper was called. In life-cycle\nhooks [`onCreated`](#user-content-reference_instance_onCreated), [`onRendered`](#user-content-reference_instance_onRendered),\nand [`onDestroyed`](#user-content-reference_instance_onDestroyed), it is the same as [`data`](#user-content-reference_instance_data).\nInside a template accessing the method as a template helper `currentData` is the same as `this`.\n\nIf `path` is provided, it returns only the value under the path. It uses\n[data-lookup](https://github.com/peerlibrary/meteor-data-lookup) package to resolve the path. Moreover, this limits\nreactivity only to changes of that value and not the whole data context.\n\nWhen `path` is provided, current lexical scope is consulted first, before path is looked up\nin the data context. This allows one to access lexical scope values from the component.\n`currentData('foo.bar')` thus becomes the same as `{{foo.bar}}`, even when `foo` is defined\nthrough the lexical scope. For example, to access current iteration index, you can do:\n\n```handlebars\n\u003ctemplate name=\"ListComponent\"\u003e\n  \u003cul\u003e\n    {{#each list}}\n      \u003cli class=\"{{oddOrEven}}\"\u003e{{item}}\u003c/li\u003e\n    {{/each}}\n  \u003c/ul\u003e\n\u003c/template\u003e\n```\n\n```javascript\nclass ListComponent extends BlazeComponent {\n  oddOrEven() {\n    // @index is zero-based, so \"odd\" and \"even\" are swapped.\n    return this.currentData('@index') % 2 === 0 ? 'odd' : 'even';\n  }\n}\n\nListComponent.register('ListComponent');\n```\n\n\u003ca name=\"reference_instance_component\"\u003e\u003c/a\u003e\n```javascript\ncomponent()\n```\n\nReturns the component. Useful in templates and mixins to get a reference to the component.\n\n\u003ca name=\"reference_instance_currentComponent\"\u003e\u003c/a\u003e\n```javascript\ncurrentComponent()\n```\n\nSimilar to [`currentData`](#user-content-reference_instance_currentData), `currentComponent` returns current\ncaller-level component.\n\nIn most cases the same as `this` in the code, but in event handlers it returns the component at the place\nwhere event originated (target component), and inside template content wrapped with a block helper component,\nit is the closest block helper component.\n\n\u003ca name=\"reference_instance_componentName\"\u003e\u003c/a\u003e\n```javascript\ncomponentName()\n```\n\nThis is a complementary instance method which calls [`componentName`](#user-content-reference_class_componentName)\nclass method.\n\n\u003ca name=\"reference_instance_parentComponent\"\u003e\u003c/a\u003e\n```javascript\nparentComponent()\n```\n\nReturns the component's parent component, if it exists, or `null`. A reactive data source.\n\nThe parent component is available only after the component has been [created](#user-content-reference_instance_onCreated),\nand until is [destroyed](#user-content-reference_instance_onDestroyed).\n\n\u003ca name=\"reference_instance_childComponents\"\u003e\u003c/a\u003e\n```javascript\nchildComponents([nameOrComponent])\n```\n\nReturns an array of component's children components. A reactive data source. The order of children components in the\narray is arbitrary.\n\nYou can specify a component name, class, or instance to limit the resulting children to.\n\nThe children components are in the array only after they have been [created](#user-content-reference_instance_onCreated),\nand until they are [destroyed](#user-content-reference_instance_onDestroyed).\n\n\u003ca name=\"reference_instance_childComponentsWith\"\u003e\u003c/a\u003e\n```javascript\nchildComponentsWith(propertyOrMatcherOrFunction)\n```\n\nReturns an array of component's children components which match a `propertyOrMatcherOrFunction` predicate. A reactive\ndata source. The order of children components in the array is arbitrary.\n\nA `propertyOrMatcherOrFunction` predicate can be:\n* a property name string, in this case all children components which have a property with the given name (or their\n  mixins do) are matched\n* a matcher object specifying mapping between property names and their values, in this case all children components\nwhich (or their mixins) have all properties from the matcher object equal to given values are matched (if a property\nis a function, it\nis called and its return value is compared instead)\n* a function which receives `(child, parent)` with `this` bound to `parent`, in this case all children components\nfor which the function returns a true value are matched\n\nExamples:\n\n```javascript\ncomponent.childComponentsWith('propertyName');\ncomponent.childComponentsWith({propertyName: 42});\ncomponent.childComponentsWith((child, parent) =\u003e child.propertyName === 42);\n```\n\nThe children components are in the array only after they have been [created](#user-content-reference_instance_onCreated),\nand until they are [destroyed](#user-content-reference_instance_onDestroyed).\n\n#### Life-cycle hooks ####\n\n\u003ca name=\"reference_instance_constructor\"\u003e\u003c/a\u003e\n```javascript\nconstructor([args...])\n```\n\nWhen a component is created, its constructor is first called. There are no restrictions on component's constructor\nand Blaze Components are designed to [coexist with classes](#use-with-existing-classes) which require their own\narguments when instantiated. To facilitate this, Blaze Components operate equally well with classes (which are\nautomatically instantiated as needed) or already made instances. The real life-cycle of a Blaze Component starts\nafter its instantiation.\n\nWhen including a component in a template, you can pass arguments to a constructor by using the `args` keyword.\n\nExample:\n\n```handlebars\n{{\u003e ButtonComponent args 12 color='red'}}\n```\n\nBlaze Components will call `ButtonComponent`'s constructor with arguments `12` and `Spacebars.kw({color: 'red'})`\nwhen instantiating the component's class. Keyword arguments are wrapped into\n[`Spacebars.kw`](https://github.com/meteor/meteor/blob/devel/packages/spacebars/README.md#helper-arguments).\n\nIt is a good practice to always call parent class constructor using `super`.\n\nAfter the component is instantiated, all its [mixins](#user-content-reference_instance_mixins) are instantiated as well.\n\n\u003ca name=\"reference_instance_onCreated\"\u003e\u003c/a\u003e\n```javascript\nonCreated()\n```\n\nExtend this method to do any initialization of the component before it is rendered for the first time. This is a better\nplace to do so than a class constructor because it does not depend on the component nature,\n[mixins](#user-content-reference_instance_mixins) are already initialized, and most Blaze Components methods\nwork as expected (component was not yet rendered, so [DOM related methods](#access-to-rendered-content) do not yet work).\n\nBy default the method calls preexisting [`onCreated`](http://docs.meteor.com/#/full/template_onCreated) callbacks defined\non the template returned from the [`template`](#user-content-reference_instance_template) method call.\n\nA recommended use is to initialize any reactive variables and subscriptions internal to the component.\n\nExample:\n\n```javascript\nclass ButtonComponent extends BlazeComponent {\n  onCreated() {\n    super.onCreated();\n\n    this.color = new ReactiveField(\"Red\");\n\n    $(window).on('message.buttonComponent', (event) =\u003e {\n      let color = event.originalEvent.data \u0026\u0026 event.originalEvent.data.color;\n      if (color) this.color(color);\n    });\n  }\n\n  onDestroyed() {\n    super.onDestroyed();\n\n    $(window).off('.buttonComponent');\n  }\n}\n\nButtonComponent.register('ButtonComponent');\n```\n\n```handlebars\n\u003ctemplate name=\"ButtonComponent\"\u003e\n  \u003cbutton\u003e{{color}}\u003c/button\u003e\n\u003c/template\u003e\n```\n\nYou can now use [`postMessage`](https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage) to send messages\nlike `{color: \"Blue\"}` which would reactively change the label of the button.\n\nIt is a good practice to always call parent class method using `super`.\n\nWhen [mixins](#mixins-1) provide `onCreated` method, they are called after the component in mixins order automatically.\n\n\u003ca name=\"reference_instance_onRendered\"\u003e\u003c/a\u003e\n```javascript\nonRendered()\n```\n\nThis method is called once when a component is rendered into DOM nodes and put into the document for the first time.\n\nBy default the method calls preexisting [`onRendered`](http://docs.meteor.com/#/full/template_onRendered) callbacks\ndefined on the template returned from the [`template`](#user-content-reference_instance_template) method call.\n\nBecause your component has been rendered, you can use [DOM related methods](#access-to-rendered-content) to access\ncomponent's DOM nodes.\n\nThis is the place where you can initialize 3rd party libraries to work with the DOM content as well. Keep in\nmind that interactions of a 3rd party library with Blaze controlled content might bring unintentional consequences\nso consider reimplementing the 3rd party library as a Blaze Component instead.\n\nIt is a good practice to always call parent class method using `super`.\n\nWhen [mixins](#mixins-1) provide `onRendered` method, they are called after the component in mixins order automatically.\n\n\u003ca name=\"reference_instance_onDestroyed\"\u003e\u003c/a\u003e\n```javascript\nonDestroyed()\n```\n\nThis method is called when an occurrence of a component is taken off the page for any reason and not replaced\nwith a re-rendering.\n\nBy default the method calls preexisting [`onDestroyed`](http://docs.meteor.com/#/full/template_onDestroyed) callbacks\ndefined on the template returned from the [`template`](#user-content-reference_instance_template) method call.\n\nHere you can clean up or undo any external effects of [`onCreated`](#user-content-reference_instance_onCreated)\nor [`onRendered`](#user-content-reference_instance_onRendered) methods. See the example above.\n\nIt is a good practice to always call parent class method using `super`.\n\nWhen [mixins](#mixins-1) provide `onDestroyed` method, they are called after the component in mixins order automatically.\n\n\u003ca name=\"reference_instance_isCreated\"\u003e\u003c/a\u003e\n```javascript\nisCreated()\n```\n\nReturns `true` if the component is created, possibly rendered, but not (yet) destroyed. Otherwise `false`. A reactive\ndata source.\n\n\u003ca name=\"reference_instance_isRendered\"\u003e\u003c/a\u003e\n```javascript\nisRendered()\n```\n\nReturns `true` if the component is rendered, but not (yet) destroyed. Otherwise `false`. A reactive data source.\n\n\u003ca name=\"reference_instance_isDestroyed\"\u003e\u003c/a\u003e\n```javascript\nisDestroyed()\n```\n\nReturns `true` if the component is destroyed. Otherwise `false`. If component was never created, it was also never\ndestroyed so initially the value is `false`. A reactive data source.\n\n#### Programmatic rendering ####\n\nBlaze Components are most often automatically rendered by Blaze when included in templates. In that case Blaze\ntakes care of the whole life-cycle of a component. Sometimes you might want to render a component programmatically\nby yourself. In that case you have to keep in mind that Blaze Components are first rendered to Blaze template, which\nare then rendered by Blaze to DOM.\n\n\u003ca name=\"reference_instance_renderComponent\"\u003e\u003c/a\u003e\n```javascript\nrenderComponent([parentComponent])\n```\n\nRenders a Blaze Component into a Blaze template.\n\nIn the case you want to render the Blaze template further to DOM, you can use that Blaze template as an input to\n[`Blaze.render`](http://docs.meteor.com/#/full/blaze_render) or\n[`Blaze.renderWithData`](http://docs.meteor.com/#/full/blaze_renderwithdata).\n\nAlternatively, you can return that Blaze template from a Blaze Component method to have a dynamic include in the\ntemplate:\n\n```javascript\nclass DynamicComponent extends BlazeComponent {\n  renderButton(parentComponent) {\n    parentComponent ||= this.currentComponent();\n    return ButtonComponent.renderComponent(parentComponent);\n  }\n}\n\nDynamicComponent.register('DynamicComponent');\n```\n\n```handlebars\n\u003ctemplate name=\"DynamicComponent\"\u003e\n  {{\u003e renderButton}}\n\u003c/template\u003e\n```\n\nNotice the use of [`currentComponent`](#user-content-reference_instance_currentComponent) as the default\n`parentComponent` argument.\nThis makes `parentComponent` be set to the correct value when `renderButton` method is used in a template include,\nbut also allows calling `renderButton` from elsewhere in the code with a provided `parentComponent`.\n\n*Despite being documented, `renderComponent` method is not yet considered public and is subject to change.*\n\n\u003ca name=\"reference_instance_removeComponent\"\u003e\u003c/a\u003e\n```javascript\nremoveComponent()\n```\n\nRemoves rendered-to-DOM Blaze Component from DOM, destroys the underlying Blaze template, and destroys the Blaze Component.\n\nYou should call this method only if you have previously programmatically rendered the Blaze Component to DOM\n(using [`Blaze.render`](http://docs.meteor.com/#/full/blaze_render) or\n[`Blaze.renderWithData`](http://docs.meteor.com/#/full/blaze_renderwithdata)). In all other cases Blaze Components\nwill be removed from DOM and destroyed automatically by Blaze: you should not interfere with Blaze by removing\nrendered DOM by yourself.\n\n\u003ca name=\"reference_instance_renderComponentToHTML\"\u003e\u003c/a\u003e\n```javascript\nrenderComponentToHTML([parentComponent], [parentView], [data])\n```\n\nRenders a Blaze Component into a HTML string. If you pass `data`, it is used as a data context for rendering.\n\nIt works both on the client and [server side](#server-side-rendering). But you have to add your HTML template\nfile and Blaze Component code file to the target (or targets) you want to call this method on.\n\nWhen using this method to render a Blaze Component, [life-cycle](#life-cycle-hooks-1) of a component is different:\nthe component is created and destroyed, but not rendered (its [`onRendered`](#user-content-reference_instance_onRendered)\nlife-cycle hook is also not called). This allows you to put into the [`onCreated`](#user-content-reference_instance_onCreated)\nlife-cycle hook initialization of the component which does not depend on the fact that the component is being\nrendered to the DOM, and you put into the `onRendered` logic which needs access to the rendered DOM.\nOf course, the best is if you do not access DOM directly and do not use `onRendered`. Then such a component\ncan work both on the client and server side the same.\n\n#### Utilities ####\n\n\u003ca name=\"reference_instance_autorun\"\u003e\u003c/a\u003e\n```javascript\nautorun(runFunc)\n```\n\nA version of [`Tracker.autorun`](http://docs.meteor.com/#/full/tracker_autorun) that is stopped when the component is\ndestroyed. You can use `autorun` from an [`onCreated`](#user-content-reference_instance_onCreated) or\n[`onRendered`](#user-content-reference_instance_onRendered) life-cycle hooks to reactively update the DOM or the component.\n\n\u003ca name=\"reference_instance_subscribe\"\u003e\u003c/a\u003e\n```javascript\nsubscribe(name, [args...], [callbacks])\n```\n\nA version of [`Meteor.subscribe`](http://docs.meteor.com/#meteor_subscribe) that is stopped when the component is\ndestroyed. You can use `subscribe` from an [`onCreated`](#user-content-reference_instance_onCreated) life-cycle hook to\nspecify which data publications this component depends on.\n\n\u003ca name=\"reference_instance_subscriptionsReady\"\u003e\u003c/a\u003e\n```javascript\nsubscriptionsReady()\n```\n\nThis method returns `true` when all of the subscriptions called with [`subscribe`](#user-content-reference_instance_subscribe)\nare ready. Same as with all other methods, you can use it as a template helper in the component's template.\n\n#### Low-level DOM manipulation hooks ####\n\n\u003ca name=\"reference_instance_insertDOMElement\"\u003e\u003c/a\u003e\n```javascript\ninsertDOMElement(parent, node, before)\n```\n\nEvery time Blaze wants to insert a new DOM element into the component's DOM content it calls this method. The default\nimplementation is that if `node` has not yet been inserted, it simply inserts the `node` DOM element under the\n`parent` DOM element, as a sibling before the `before` DOM element, or as the last element if `before` is `null`.\n\nYou can extend this method if you want to insert the new DOM element in a different way, for example, by animating\nit. Make sure you do insert it correctly because Blaze will expect it to be there afterwards.\n\nIf you want to use [mixins](#mixins-1) with the `insertDOMElement` method, you will have to extend the component's\nmethod to call them in the way you want.\n\n\u003ca name=\"reference_instance_moveDOMElement\"\u003e\u003c/a\u003e\n```javascript\nmoveDOMElement(parent, node, before)\n```\n\nEvery time Blaze wants to move a DOM element to a new position between siblings it calls this method. The default\nimplementation is that if `node` has not yet been moved, it simply moves the `node` DOM element before the `before`\nDOM element, or as the last element if `before` is `null`.\n\nYou can extend this method if you want to move the DOM element in a different way, for example, by animating\nit. Make sure you do move it correctly because Blaze will expect it to be there afterwards.\n\nIf you want to use [mixins](#mixins-1) with the `moveDOMElement` method, you will have to extend the component's\nmethod to call them in the way you want.\n\n\u003ca name=\"reference_instance_removeDOMElement\"\u003e\u003c/a\u003e\n```javascript\nremoveDOMElement(parent, node)\n```\n\nEvery time Blaze wants to remove a DOM element it calls this method. The default implementation is that\nif `node` has not yet been removed, it simply removes the `node` DOM element.\n\nYou can extend this method if you want to remove the DOM element in a different way, for example, by animating\nit. Make sure you do remove it correctly because Blaze will expect it to be removed afterwards.\n\nIf you want to use [mixins](#mixins-1) with the `removeDOMElement` method, you will have to extend the component's\nmethod to call them in the way you want.\n\n#### Mixins ####\n\n\u003ca name=\"reference_instance_mixins\"\u003e\u003c/a\u003e\n```javascript\nmixins()\n```\n\nExtend this method and return mixins for the component. Mixins can be components themselves, or just classes or\nobjects resembling them. No method is required for them, but methods will be called on them by Blaze\nComponents if they do exist.\n\nThe `mixins` method should return an array of registered component names, mixin classes, or mixin instances.\nWhen component instance is created, all mixins' instances are created as well, if they were not already an\ninstance. Life-cycle of mixin instances matches that of the component.\n\n\u003ca name=\"reference_instance_getMixin\"\u003e\u003c/a\u003e\n```javascript\ngetMixin(nameOrMixin)\n```\n\nReturns the component's mixin instance for a given name, class, or instance. Returns `null` if mixin is not found.\n\nYou can use it to check if a given mixin is used by the component.\n\n\u003ca name=\"reference_instance_getFirstWith\"\u003e\u003c/a\u003e\n```javascript\ngetFirstWith(afterComponentOrMixin, propertyOrMatcherOrFunction)\n```\n\nIt searchers the component and its mixins in order to find the first which matches a `propertyOrMatcherOrFunction`\npredicate. If `afterComponentOrMixin` is `null`, it starts with the component itself. If `afterComponentOrMixin` is the component,\nit starts with the first mixin. Otherwise it starts with the mixin after `afterComponentOrMixin`.\n\nReturns `null` if such component or mixin is not found.\n\nA `propertyOrMatcherOrFunction` predicate can be:\n* a property name string, in this case the first component or mixin which has a property with the given name is matched\n* a matcher object specifying mapping between property names and their values, in this case the first component or mixin\nwhich has all properties from the matcher object equal to given values is matched (if a property is a function, it\nis called and its return value is compared instead)\n* a function which receives `(mixin, component)` with `this` bound to `component`, in this case the first component or\nmixin for which the function returns a true value is matched\n\n\u003ca name=\"reference_instance_callFirstWith\"\u003e\u003c/a\u003e\n```javascript\ncallFirstWith(afterComponentOrMixin, propertyName, [args...])\n```\n\nIt searchers the component and its mixins in order to find the first with a property `propertyName`,\nand if it is a function, calls it with `args` as arguments, otherwise returns the value of the property.\nIf `afterComponentOrMixin` is `null`, it starts with the component itself. If `afterComponentOrMixin` is the component,\nit starts with the first mixin. Otherwise it starts with the mixin after `afterComponentOrMixin`.\n\nReturns `undefined` if such component or mixin is not found.\n\n\u003ca name=\"reference_instance_mixinParent\"\u003e\u003c/a\u003e\n```javascript\nmixinParent([mixinParent])\n```\n\nWhen called without a `mixinParent` argument it returns the mixin's parent. For a component instance's mixins it\nreturns the component instance.\n\nWhen called with a `mixinParent` argument it sets the mixin's parent.\n\nTo access the mixin's component, it is better to use [`component`](#user-content-reference_instance_component)\ninstead, which traverses multiple levels of mixins automatically.\n\n*Setting the mixin's parent is done automatically by calling this method when creating component's mixins. Extend\n(or provide) this method if you want to do any action when parent is set, for example, add dependency mixins to\nthe parent using [`requireMixin`](#user-content-reference_instance_requireMixin). Make sure you call `super` as well.*\n\n\u003ca name=\"reference_instance_requireMixin\"\u003e\u003c/a\u003e\n```javascript\nrequireMixin(nameOrMixin)\n```\n\nAdds a mixin after already added mixins. `nameOrMixin` can be a registered component name, mixin class, or\nmixin instance.\n\nIf mixin is already added to the component the method does nothing.\n\nUse `requireMixin` to manually add additional mixins after a component was created. For example, to add\ndependencies required by automatically added mixins as a result of [`mixins`](#user-content-reference_instance_mixins).\n\nDebugging\n---------\n\nTo help with debugging, `BlazeComponentDebug` class is available. It contains class methods which can help\nyou introspect the current state of rendered components.\n\n\u003ca name=\"debugging_class_dumpComponentSubtree\"\u003e\u003c/a\u003e\n```javascript\nstatic dumpComponentSubtree(componentOrElement)\n```\n\nFor a provided component instance or DOM element rendered by a component instance this class method prints\nto the browser web console the tree structure of component instances for which the provided component instance\nis an ancestor.\n\n\u003ca name=\"debugging_class_dumpComponentTree\"\u003e\u003c/a\u003e\n```javascript\nstatic dumpComponentTree(componentOrElement)\n```\n\nFor a provided component instance or DOM element rendered by a component instance this class method prints\nto the browser web console the whole tree structure of component instances in which the provided component\ninstance exists, from the root component instance down.\n\nThe provided component instance's name is underlined.\n\n\u003ca name=\"debugging_class_dumpAllComponents\"\u003e\u003c/a\u003e\n```javascript\nstatic dumpAllComponents()\n```\n\nPrints to the browser web console tree structures of all component instances currently rendered.\n\nRelated projects\n----------------\n\n* [meteor-template-extension](https://github.com/aldeed/meteor-template-extension) – provides various ways of copying\ntemplate helpers, event handlers and hooks between templates, allowing code reuse; a downside is that all copying\nhas to be taken care by a developer, often again and again, which becomes problematic as codebase grows; moreover,\nwithout a clearly defined API community cannot build and share components\n* [meteor-autoform](https://github.com/aldeed/meteor-autoform) – offers forms components through a sophisticated\nuse of templates and template helpers but it is still hard to compose behaviors you want beyond defining additional\ninput fields\n* [Flow Components](https://github.com/meteorhacks/flow-components) – Flow Components are closer to\n[React](https://facebook.github.io/react/) in the API design while Blaze Components are keeping familiar concepts\nlike data contexts and template helpers; Flow Components on the other hand still use template-based event handlers\nwhile Blaze Components make them class methods so it easier to extend or override them through inheritance; in\ngeneral Blaze Components seems to be more OOP oriented; Flow Components are not yet officially released\n* [ViewModel](https://github.com/ManuelDeLeon/viewmodel) – instead of using event handlers to imperatively respond to user\ninteractions, ViewModel provides a two-way data binding between the model and DOM elements, like form input elements,\nif data changes, form input element updates, if user modifies form input element, data is updated; alongside, ViewModel\ncan be used as components; Blaze Components are in this way lower level and they do not prescribe the way you\nshould be using data binding or event handlers, Blaze Components provide traditional DOM event handlers but you can\nbuild on top of it data binding in the way you want, when you want/need it; you can even create a mixin for that and\nreuse it across components; moreover, Blaze Components' main focus is on providing a good and extensible components\nsystem and its power shows exactly because you can build such features through opt-in mixins\n* [Blaze Plus](https://github.com/kadirahq/blaze-plus/) – Blaze Plus adds props and state management functionality to\nBlaze, allowing one to pass data from the top to the bottom. These ideas are inspired by React.\nA proposed way to limit rerenders in Blaze Components if one wants to pass data from the top to the bottom is to use\n[computed field](https://github.com/peerlibrary/meteor-computed-field) package.\n* [TemplateController](https://github.com/meteor-space/template-controller) – Wrapping some of the same best practices Blaze Components do, but into only a thin layer without much extra features one can find in Blaze Components and without support for code reusability and sharing.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fpeerlibrary%2Fmeteor-blaze-components","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fpeerlibrary%2Fmeteor-blaze-components","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fpeerlibrary%2Fmeteor-blaze-components/lists"}