meteor / blaze Goto Github PK
View Code? Open in Web Editor NEW:fire: Meteor Blaze is a powerful library for creating live-updating user interfaces
Home Page: http://blazejs.org/
License: Other
:fire: Meteor Blaze is a powerful library for creating live-updating user interfaces
Home Page: http://blazejs.org/
License: Other
A contribution guide make it easier to start helping on the project.
There are some points that could need a workflow guide :
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
component2.html
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.
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?
For #11 to really work, we have to move all dependencies into separate repositories/NPM.
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 need a global onRendered hookable function, the same goes for onCreated, onDestroyed, etc. Agreed?
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.
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.
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.
(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])}}
.
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#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
We have now documentation in the repository, but there are many things to improve. Some:
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).
(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>
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?
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
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
this
was a real string, but I don't think that's possible in JS.findOne
, to convert these spacebars object strings into real strings instead of throwing errors.Moved from meteor/meteor#5031
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}}
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?
So that master
is the stable branch.
It may be nice that instead of writing
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.
We should start providing stand-alone documentation for Blaze. Some ideas:
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.
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.
We have domain: http://blazejs.com/
Probably something simple hosted on GitHub pages.
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.
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.
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:
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}
In readme and here we should point to this repository to help users with transition. Some background.
๐ฅ ๐ฅ
Just so the repo doesn't look so bare.
I would setup so that we can pay it collectively (#60) and that more people have access to manage it.
After #16, we should try to get Meteor to serve server-side rendered Blaze templates.
I suggest you use CircleCI test runner. It knows how to go one by one for packages and run tinytests tests there.
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}} />
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 #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.
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.
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
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?
@martijnwalraven, can you do this? Or should contributors not have to sign it to contribute to this repository?
After we potentially split packages into multiple repositories/make NPM packages.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.