meteor / blaze

:fire: Meteor Blaze is a powerful library for creating live-updating user interfaces

What is Blaze?

Blaze is a powerful library for creating user interfaces by writing reactive HTML templates. Compared to using a combination of traditional templates and jQuery, Blaze eliminates the need for all the "update logic" in your app that listens for data changes and manipulates the DOM. Instead, familiar template directives like {{#if}} and {{#each}} integrate with Tracker's "transparent reactivity" and Minimongo's database cursors so that the DOM updates automatically.

Blaze has two major parts:

• A template compiler that compiles template files into JavaScript code that runs against the Blaze runtime library. Moreover, Blaze provides a compiler toolchain (think LLVM) that can be used to support arbitrary template syntaxes. The flagship template syntax is Spacebars, a variant of Handlebars, but a community alternative based on Jade is already in use by many apps.

• A reactive DOM engine that builds and manages the DOM at runtime, invoked via templates or directly from the app, which features reactively updating regions, lists, and attributes; event delegation; and many callbacks and hooks to aid the app developer.

Check our Overview to learn more.

Quick Start

Blaze is a Meteor-only package for now. Soon we will have Blaze on npm so you can use it in your stack.

Each new Meteor project you create has Blaze included (the blaze-html-templates package).

Get involved

We'd love for you to help us build Blaze. If you'd like to be a contributor, check out our contributing guide.

Also, to stay up-to-date on all Blaze related news and the community you should definitely join us on Slack.

See open issues and consider helping with any of the tasks. Those labeled "contributions welcome" are probably a good start. We have issues organized into GitHub projects for a better overview as well. And the current roadmap shows the issues we need help with for the next release.

Backers

Support us with a monthly donation and help us continue our activities. Become a backer.

Sponsors

Become a sponsor and get your logo on our README on Github with a link to your site. Become a sponsor.

License

Blaze is available under the MIT license.

blaze's Issues

Weird behaviour when passing functions from helpers

Hi Everybody!
I'm experiencing a weird thing with Blaze when passing callbacks from helpers that receive a parameter. An example:

<template name="example" args="parameter">
    {{> childTemplate callback=(callbackGenerator parameter)}} 
</template>

Template.example.helpers({
    callbackGenerator(parameter) {
        return () => {
            console.log(parameter);
        };
    }
});

I expected the callbackGenerator to return a function, and this function to be called when childTemplate calls it.
But what actually happens is that the function returned is getting immediatly called. It doesn't happen with callbacks without parameters though.
To fix that, we have to write this:

Template.example.helpers({
    callbackGenerator(parameter) {
        return () => {
            return () => {
                console.log(parameter);
            };
        };
    }
});

Is really ugly 😞

Anything i'm doing wrong?

post to the forum

Fix tests

They are failing now: https://circleci.com/gh/meteor/blaze/38

Error: Depending on unknown package spacebars-compiler

Maybe now that those packages were removed from Meteor?

Provide integrations with common build toolchains to compile Blaze templates

Don't pass an empty {hash:{}} as the last arg to a template helper

Moved from meteor/meteor#5031

Repeated class names not rendered correctly

meteor/meteor#5632

Original Post

Using Semantic-UI sometimes you need to add the same class name twice, i.e.

but this is translated into

<div class="ui two column computer one mobile grid container">

breaking the interface.
This is because of DiffingAttributeHandler call this.parseValuewhich reduces the repeated element into one since the element is the key in the array where values are stored

`parseValue: function (attrString) {
var tokens = {};

_.each(attrString.split(' '), function(token) {
  if (token)
    tokens[token] = token;
});
return tokens;

}`

Here is the repo to reproduce the error with step by step guide: https://github.com/bitIO/repeated-class-issue

---

The outcome was of a pull request that appears to fix the issue but lacked tests, comments and was not readable.
meteor/meteor#5753

Easy way to force no data context in templates

(From meteor/meteor#5459 .)

Proposal:

{{> fooTemplate ()}}

Includes the template with {} as a data context.

We should check if {{> fooTemplate null}} works.

I would then suggest that we document this in the guide as a recommended way to include templates, if you do not want to pass a data context.

Or, we could do:

<template name="foo" nullDefaultDataContext="true">
  ...
</template>

So we could provide some arguments to template to tweak the behavior.

Imagine even:

<template name="foo" templateInstanceAsThis="true">
  ...
</template>

Support dots in names of templates.

Originally posted on meteor/meteor#5584 by @matteodem

Create an empty meteor app (version 1.2.1) and paste in following html:

<body>
  {{> myNamespace.testTemplate}}
</body>

<template name="myNamespace.testTemplate">
  Hello
</template>

Which does not work, whereas the same template without the . in its name works.

A callback event after DOM is updated

Migrated from meteor/meteor#4731

_7 Upvotes_ please feel free to close this issue if this request is invalid or I neglected an already-existing feature

We need something better than onRendered that is called everytime a DOM is updated.

Given the following code:

<template name="FrameItems">
  {{#each frames}}
    <div id="frame-{{_id}}" class="frame-preview-item cyan lighten-5">
      <div class='frame-name'>{{name}}</div>
      <div class="ep"></div>
    </div>
  {{/each}}
</template>

and the helper function

  Template.FrameItems.helpers({
    frames: function() {
      var trialId = Session.get('trialId');
      return Frames.find({trialId: trialId});
    }
  });

DOM is updated every time frames helper function is re-run, but onRendered() only gets called once when the template was initially constructed. What if you want to update the DOM every time frames helper function returns new set of .frame-preview-item? On StackOverflow and Google Groups, people have been suggesting to use Meteor.defer(). However, since it's basically same as setTimeout it's not called exactly when the new frames are inserted (i.e. it's slower than onRendered callback). To solve this problem, I used Blaze.remove and Blaze.render to destroy FrameItems and insert them manually (not using {{> frameItems}}) every time frames is updated, so that I can use the onRendered callback.

This seems to be a common use case and I wonder if Meteor yet supports a clean way to deal with this.
These are links to posts asking how to do this:

http://stackoverflow.com/questions/10109788/callback-after-the-dom-was-updated-in-meteor-js
https://groups.google.com/forum/#!topic/meteor-talk/TMf4RLfQK_w
http://stackoverflow.com/questions/17584522/how-to-make-a-meteor-template-helper-re-run-render-after-another-template-has-re
http://stackoverflow.com/questions/31353120/run-a-function-after-dom-is-updated-from-a-helper-function/31353151?noredirect=1#comment50720195_31353151

{{elsif}} or {{elseif}} or {{#elseif}}

I am suggesting we add an {{elsif}} or {{elseif}} or whatever variation to avoid this ugly piece of code:

{{#if condition1}}
{{else}}
  {{#if condition2}}
  {{else}}
     {{#if condition3}}
     {{/if}}
  {{/if}}
{{/if}}

Imagine this instead

{{#if condition1}}
{{elseif condition2}}
{{elseif condition3}}
{{/if}}

I also think this will go a long way in making people more likely to adopt Blaze as it cleans up the code quite a bit for complex apps.

Add Template.registerHelpers(object)

Migrated from meteor/meteor#4367

This is now a feature of https://github.com/aldeed/meteor-template-extension
We could consider including the whole package

---

There are two patterns I use a few places in my app that would be improved by this:

1. registering multiple helpers at once
2. registering helpers that are also called from app JS
   Before:

helpers = 
  foo: ->
    0
  bar: ->
    1
for name, fn of helpers
  Template.registerHelper name, fn

After:

Template.registerHelpers
  foo: ->
    0
  bar: ->
    1

Before:

foo = ->
  0
bar = ->
  1

Template.registerHelper 'foo', foo
Template.registerHelper 'bar', bar

After:

foo = ->
  0
bar = ->
  1

Template.registerHelpers {foo, bar}

Use Incremental DOM

In the hopes of improving performance. Library from google: https://github.com/google/incremental-dom

From @mitar: "So I think you want to override materializer. If incremental DOM has good API, this might be relatively straightforward to do."

Migrated from peerlibrary/meteor-blaze-components#120

Make CI testing works for all packages

After we potentially split packages into multiple repositories/make NPM packages.

Data context in a for each loop not properly set

I am using Meteor 1.3.4 and I am struggling with the data context in a for each loop. In the previous version of Meteor 1.2.x I could have a {{# each }} loop in my template and add and event on the iterated elements. When I would need the data object that was looped I could just use the this keyword in the Template.x.events method and I would get the data context.

I seems in meteor that you now explicitly have to create a new include {{> templatename }} to get the data context. Can someone confirm this? And is there another option with adding a new template for each element in a loop. Some stuff is to simple to loop over and putting it in a new template, just for the context.

Cheers Roy

Move Tracker and all other dependencies into separate repositories and NPM

For #11 to really work, we have to move all dependencies into separate repositories/NPM.

Need integration tests

I suggest you use CircleCI test runner. It knows how to go one by one for packages and run tinytests tests there.

Improve speed of removing templates

Migrated from meteor/meteor#4352

Sometimes it takes a long enough time that it creates a bad user experience, eg a 340ms delay on one of my templates is a noticeable wait.

Spacebars: Objects/arrays as arguments

(From meteor/meteor#5095 .)

I really think Blaze should allow the following syntax:

{{foo (a=1 b=2)}}
{{foo (1 2)}}

So in the first case it just creates in-place object. In the second case it finds that 1 is not a function, so it returns an array [1, 2]. {{foo (1 2 a=1)}} would return [1, 2, Spacebars.kw({a: 1})].

Alternatively, we could introduce {{foo [1 2])}}.

Provide official jQuery Blaze Template plugin

Example.

Meteor serving server-side rendered Blaze templates

After #16, we should try to get Meteor to serve server-side rendered Blaze templates.

Needs a README

🔥 🔥

Just so the repo doesn't look so bare.

Add to blaze package readme that repository is here

In readme and here we should point to this repository to help users with transition. Some background.

Add Meteor CLA bot to this repository

@martijnwalraven, can you do this? Or should contributors not have to sign it to contribute to this repository?

Provide standalone documentation

We should start providing stand-alone documentation for Blaze. Some ideas:

• API documentation (probably what is currently at http://docs.meteor.com/)
• guide for good patterns (probably what is currently at Meteor guide)
• guide how to contribute
• documentation should be versioned

I like simplicity of Vue documentation.

Probably we could just use CircleCI testing platform to compile also templates and push it to gh-pages branch on every successful test run on master branch. I did something similar Travis CI.

Migrate all still relevant issues from Meteor main repository to this repository

Unnecessary re-rendering in Blaze because with's ReactiveVar uses default equals function

(Migrated from #4073.)

Blaze uses in its Blaze.With view ReactiveVar with default equality function:

A function of two arguments, called on the old value and the new value whenever the ReactiveVar is set. If it returns true, no set is performed. If omitted, the default equalsFunc returns true if its arguments are === and are of type number, boolean, string, undefined, or null.

This means that for most data contexts which are objects re-rendering is triggered because equality function returns false. Even if new and old objects are referentially or content-wise completely equal.

The issue is that this triggers again and again Template.currentData() which might be in autoruns which do complex code.

So the questions are: why not provide some configurability here? Somehow one-size fits all approach is not good enough here. Some objects are equal when they are referentially equal. Some objects are equal when EJSON.equals returns true and it is cheaper for equality then recomputing the autorun reactive var is used in. For some you want fast failure like it is now.

Maybe a set of utilities around reactive dependencies would be beneficial which would help? https://github.com/peerlibrary/meteor-computed-field does not help with Template.currentData() because it does not use Blaze autorun.

In any case, the main issue is that internally all with data contexts are rerendered. And if this triggers then dynamic template inclusion to rerun, then you have things rebuilding and re-rendering all over the place.

Split packages each into its own repository

This repository still contains multiple packages. Would it be better to really split each one into a separate repository?

Especially with NPM, to my knowledge, this would allow one to easily depend with a package on the forked git repository.

Introspection of Current Scope

There should be functionality for viewing the current scope programatically just as we can for the data context with Template.currentData()... For instance:

{{#each things}}
   <!-- Template.currentData() equals each of the items in things -->
{{/each}}

But with "scope", there isn't a similar Template.currentScope()...

{{#each x in things}}
   <!-- x is added to the scope; accessible to helpers by passing but... -->
{{/each}}

Create landing page

We have domain: http://blazejs.com/

Probably something simple hosted on GitHub pages.

[Bug] Blaze: hidden html attribute does not work properly

Blaze dynamic attributes doesn't work properly with attribute hidden.

If you use:

helperName(){
    return {
        checked: false
}

It works great, removing the checked attribute.
But when you use:

helperName(){
    return {
        hidden: false
}

Blaze creates a html with:

hidden="false"

that occurs in an hidden element.

We need global template hooks

We need a global onRendered hookable function, the same goes for onCreated, onDestroyed, etc. Agreed?

Create devel branch

So that master is the stable branch.

Slack join page not working

Create standalone npm package(s)

It would be fantastic if Blaze had a life of it's own and could be used independently like React. I'm sure there are a lot of details to work out, some of them potentially difficult (e.g dealing with assumptions on globals).

I wonder if it's feasible to create a Webpack loader that loads .blaze.html files.

[IDEA] Components represented as HTML elements rather than spacebars syntax.

It may be nice that instead of writing

{{#some-component}}
{{/some-component}}
{{> other-component}}

we can write

<some-component>
</some-component>
<other-component />

This is more inline with other view layers (React, Angular, and others), and expands on the HTML standard rather than having a separate syntax just for Blaze components.

Collectivelly manage domain name

I would setup so that we can pay it collectively (#60) and that more people have access to manage it.

Enable locally-scoped, importable Blaze templates

Today, Blaze templates are global. I propose we add an alternate, locally-scoped/ES 2015 import compatible syntax. I've already implemented a version of this by modifying the blaze-html-templates package (and related subpackages) to enable a <component> tag that is default export from the generated JS file.
The code changes are pretty small and don't affect the existing global templates.

I have an example app on Github that includes mixing normal templates with the local templates, but following is a quick sample of the new syntax. The local templates use the <component> tag because I needed a different one than <template> and it's the first one I came up with.

component1.html

<component name="component1">
Testing {{> component2}}
</component>

component2.html

<component name="component2">
1 2 3.
</component>

component1.js

import component1 from './component1.html';
import component2 from './component2.html';

component1.helpers{{ component2 });

Redefine `this`

Make it the template instance?

Migrated from meteor/meteor#3579

For Blaze 2 milestone

Develop here or in meteor/meteor/packages/blaze?

There's two source codes: in this repo, and at https://github.com/meteor/meteor/tree/devel/packages/blaze.

Which one do we make PRs against? Why is there two?

Blaze renders self-closing tags with attributes with / at the wrong place

If there is in Blaze template such string:

<input foo={{foo}}/>

This is rendered as:

<input foo="/">

Instead of:

<input foo="">

Or:

<input>

I see in the code some special handling for non-self-closing tags of this situation. But for self-closing tags there is no special handling.

Inserting space solves the problem:

<input foo={{foo}} />

fix

markdown-cheatsheet-online.pdf

Uploading markdown-cheatsheet-online.pdf…

Visual identity of the framework

Guys, first of all, I would like to know if the blazejs has a visual identity, figures, logo or a graphic in which we can work to develop the landing page and later a documentation.

I started playing and I've got to an advanced version, what do you think?

Get Meteor to use code from this repository for Blaze distributed with Meteor releases

Improve spacebars string data context

Migrated from meteor/meteor#4259

When you do {{> foo uid}}, where uid is "FuFa6muAquumzfLMC", and you're inside a foo event, this is not a string, but rather an object representation of a string.

> console.log this, typeof this, Meteor.users.findOne this
String {0: "F", 1: "u", 2: "F", 3: "a", 4: "6", 5: "m", 6: "u", 7: "A", 8: "q", 9: "u", 10: "u", 11: "m", 12: "z", 13: "f", 14: "L", 15: "M", 16: "C", length: 17, [[PrimitiveValue]]: "FuFa6muAquumzfLMC"}
object
Uncaught TypeError: key.substr is not a function

1. It would be nice if this was a real string, but I don't think that's possible in JS.
2. If not 1, then it would be nice for Meteor functions that take strings, like findOne, to convert these spacebars object strings into real strings instead of throwing errors.

[idea] Blaze.remove(templateInstance)

Currently we can do

Blaze.remove(this.view)
// or
Blaze.remove(template.view)
// or
Blaze.remove(Template.instance().view)

which also destroys the view's template. But that might not be as convenient as simply

Blaze.remove(this)
// or
Blaze.remove(template)
// or
Blaze.remove(Template.instance())

Suggestion: allow Blaze.remove() to accept a Template instance.

Establish Open Collective for Blaze

Open Collective is an interesting new and transparent way to do financing for open source projects. We could establish one for Blaze and then use it collectively to cover expenses (like Heroku containers we might need, domain name, maybe even have bounties).

Companies who relay on Blaze could becomes sponsors. It would be great if MDG could become such a sponsor, too.

What others think? I think we should do it because I worry a bit about our infrastructure (domain, Slack invite #51).

[Idea] Add a contribution guide (contributing.md) for blaze

A contribution guide make it easier to start helping on the project.

There are some points that could need a workflow guide :

• How to submit bugs (templates)
• How to reproduce a bug & submit reproduction in the repo issues
• In the Next steps, how do you notify contributors that you've started working on a milestone & how do you submit the result for validation

Blaze reactivity bug with arrays and parentData

Assume template "outer" includes "inner" and passes it a data context with an array generated by a collection fetch(). If a helper in "inner" uses parentData() to access this context (from inside #each, for example), then the helper will be run twice when the data context changes. It should only be run once.

See https://github.com/graemian/blaze-extra-redraw . If you run

col.insert({_id: "3"})

from the browser console, you will see logging statements showing that the helper is run twice. If you remove the line

Template.parentData(1);

the helper will only be run once.

Tested on latest Meteor devel (25 April 2016)

Think about a governance

Here're my little cents on community organization: ourmeteor/discussions#1

In that way we could form a community organization to work with MDG in a completely transparent way.

Improve our documentation

We have now documentation in the repository, but there are many things to improve. Some:

• links to source code from documentation do not work
• API docs are missing
• links in API docs are pointing to Meteor repository
• landing page is duplicating the README file of this repository, I think we should decide where should be main content and then the other should point to it (I think we should put content of README into docs and then README should be very thin and just point to docs)
• Improve the layout, use the same theme and style of the "Meteor Docs" (submodule)

Don't rerun helpers when an #each cursor limit changes

Migrated from meteor/meteor#4960

When the argument to {{#each}} changes between different cursors, we treat the transition as if it is a change between two arrays. Since {{#each}} works with arbitrary arrays, we don't diff the items in the array. Instead, we inform all of the rendered items that their contents have changed (even though they likely haven't). This means many helpers will fire but their contents will stay the same.

The elegant solution in the framework would be to make minimongo smarter, giving it the intelligence to reuse materialized query results. You could imagine a minimongo that internally keeps ReactiveArrays of some sort that are updated incrementally and sliced and projected as needed for the purposes of queries.