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.

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}}

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.

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

Moved from meteor/meteor#5031

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?

Make it the template instance?

Migrated from meteor/meteor#3579

For Blaze 2 milestone

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

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

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

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

Probably something simple hosted on GitHub pages.

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}} />

🔥 🔥

Just so the repo doesn't look so bare.

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

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 });

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.

Example.

(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])}}.

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.

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.

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)

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}

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.

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.

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.

(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>

So that master is the stable branch.

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

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

meteor/meteor#5632

Original Post

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

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

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

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.

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

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?

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

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?

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.

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)

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

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

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

markdown-cheatsheet-online.pdf

Uploading markdown-cheatsheet-online.pdf…

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.

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.

(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.

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).