Context different for partial #182

merged 3 commits into from Jan 18, 2014


None yet
dethe commented Feb 17, 2012

Hi folks,

When I have a template, say:

  {{#each updates}}
    <div class="update">
        {{#if ../user}}
          <div class="name">{{}}</div>

And it works fine, but I move the update into a partial:

file: update.handlebars

<div class="update">
  {{#if ../user}}
    <div class="name">{{}}</div>

And include the partial where the update code used to be:

  {{#each updates}}
    {{> update}}

I get "TypeError: Cannot read property 'user' of undefined" now. Why would the context be different for a partial containing the exact same code?

wagenet commented Feb 17, 2012

I'm not an expert in this, but I suspect the ../user is where you're having problems. The ../ attempts to move into the parent context, but I suspect that the parent context is not passed to the partial. Does it not work to just do {{#if user}}?

dethe commented Feb 17, 2012

{{#if user}} doesn't work because I'm in the context of the {{#each}} iteration. Why wouldn't partials get the parent context? I thought they inherited the full context of the caller.


Yes, I agree, the parent context would need to be passed.

(I've actually accidentally open a separate bug for the same issue (#192) )

dethe commented Feb 27, 2012

Is there some way to fix/force/coerce the parent context to be used? This is impacting our use of handlebars in a number of ways (at least I know why it is happening now). It makes partials a lot less useful.


I tried looking at the source code for handlebars, some of which goes way above my head but I think what's happening is that a partial essentially acts like a separate template.

When invoked, it's like calling a brand new template, with the current context of the caller passed as new context for the partial.

What that means is the partial gets a brand new stack (which is what handlebars uses to maintain nested context), so .. is undefined in the partial/sub-template (the same way .. is undefined at the top of a template, before any nesting).

So I don't think you can force the parent context to be used, I think the handlebars partial loading would need to be rewritten for that.. (maybe when loading a partial depth0 in the partial could inherit the current stack of the caller, but like I said, that part of the code goes a bit above my head :)


I did manage this hack to go around the problem. Makes the template kinda messy but it does allow you to pass the parent context. All it does is wrap this and .. into an object and sets that object as the context:

Handlebars.registerHelper('subcontext', function( parent, options) {

    if (arguments.length != 2)
        throw new Error("Handlerbars Helper 'subcontext' needs .. as a parameter");

    var subcontext = { obj:this, parent:parent };

    return options.fn(subcontext);

Then you can do this:

{{#subcontext ..}}
    {{> my-partial}}


{{whatis this label="this"}}                <!-- Shows {obj, parent} -->
{{#with obj}}                       <!-- Sets obj as this -->
    {{whatis ../parent label="parent"}}     <!-- parent context from calling template -->

But yeah, it's kinda messy.

Would be great if .. was properly integrated.

source for whatis

aymuras commented Mar 7, 2012

@doginthehat I think that this workaround doesn't work when invoking inside loop. And yeah it's messy.
This bug should be fixed for sure.

Other idea: What do you think about introducing something like 'absolute paths' so we can always access all variables nevertheless where we are in the context. Now everything in handlebars seems to be 'relative paths'.

dethe commented Mar 7, 2012

Absolute paths would work for me. Simply adding variables during iteration instead of replacing them would work too. Or simply using "this" to scope the iteration variables and leaving the rest of the context alone. Anything that let's me reference the context regardless of whether I'm iterating or in an included partial (or both).


@marcinmuras Definitely is messy :)

Haven't had the need for an absolute path as such yet. One thing I have had the need for in the past is the top level context - it often has some global settings for rendering the view that need to be used inside loops or subview.

Recently tried to render a tree structure with handlebar, that was a bit painful.

aymuras commented Mar 7, 2012

Seems that we are talking about same things. I called your 'top level context' as absolute path. Generally we need something to access all variables in loops, partials etc..


Thanks for the idea, @doginthehat. There should definitely be a native implementation of this feature for Mustache/Handlebars in the future. I came up with a version that's a bit cleaner (@marcinmuras):

Handlebars.registerHelper('$', function ( child, options ) {
    if ( typeof child !== 'object' ) {
        return '';
    child['$_'] = this;
    return options.fn( child );

When calling your partial, wrap it in this helper and pass it an argument of a variable in the current content that will become child context, as follows:

{{#$ childContextObject }}{{> yourPartial}}{{/$}}

To access variables from the calling/parent context in your partial, use:

{{ $_.variableInParentContext }}

Variables from the child context object passed above can be accessed as usual within the partial, i.e.:

{{ variableInChildContext }}

You can rename the helper $ or the parent accessor variable $_ to anything you like.


+1 A native way to access the parent variables from within a nested partial in a loop would be very helpful.


nice workaround @adjohnson916 , thanks!

definitely would love to see this fixed natively


is there any suggestion from the powers that be (i.e. @wycats) that this could be natively supported by handlebars in the near future?


I just found another problem may relatived to this one.

I want to use the customize helpers and paritials like what in wiki:

template(context, {helpers: helpers, partials: partials, data: data})

but I found that in paritials the customize helpers are gone, I guess it because the customize helpers didn't passed correctly as the context changed.

for example, in the main:

 Hi, {{> partial}}!


{{Uppercase name}}

and run it as:

template({name: 'A' }, { helpers: {
                                       'Uppercase': function(name) { return name.toUpperCase(); }

But it reported: Uncaught Error: Could not find property 'Uppercase'


This might be interesting:
For me, this issue is becoming more and more a major headache


@mschipperheyn Thanks, that is interesting. Though I don't think it applies to partials, there is no upper context to navigate to in partials, that's the main issue :)


I wrote a workaround which gives you a little more control as to how access the parent scope inside of the partial

see code example here

With a context like this

var context = {name: "Dennis", town: "berlin",  hobbies: [{hobbyname: "swimming"}, {hobbyname: "dancing"}, {hobbyname: "movies"}]}

and the following helper

Handlebars.registerHelper('include', function(templatename, options){  
    var partial = Handlebars.partials[templatename];
    var context = $.extend({}, this, options.hash);
    return partial(context);

This lets you include a partial like this (from jsfiddle expample):

{{include "template-partial" parentcontext=.. town=../town}}

now town would be accesible inside the partial directly by {{town}} or {{}}

With the options (key=value) following the templatename ("template-partial") you can kind of map the parent context to any key inside the partial. This makes it easier to change things back, when native support is there.

denisu commented Sep 4, 2012


thanks, looks brilliant!


thanks @chickenwing

I like it!

(still +1 for native support though)

ustun commented Sep 18, 2012

@chickenwing Using your helper helped, thanks. I had to change the last line to:

        return new Handlebars.SafeString(partial(context));

otherwise, the html output from the include was being interpreted as text.

(Also, not sure why, but it seems Handlebars is storing my partials as strings, not functions under Handlebars.partials, so I added

if (typeof partial === "string") {
        partial = Handlebars.compile(partial);

@ustun and @chickenwing - Haha. Struggled with this for a few minutes as well - was about to paste the same solution as @ustun. Here's my full helper code (in CoffeeScript):

Handlebars.registerHelper 'include', (templateName, options) -> 
  partial = Handlebars.partials[templateName]
  if (typeof partial is "string")
    partial = Handlebars.compile(partial)
    Handlebars.partials[templateName] = partial
  context = $.extend({}, this, options.hash)
  new Handlebars.SafeString partial(context)
@lwille lwille added a commit to lwille/handlebars.js that referenced this pull request Nov 20, 2012
@lwille lwille added 'include' helper from #182 25d1fe4
lwille commented Nov 20, 2012



rektide commented Dec 4, 2012

That include helper causes a lot of data copying to happen. It seems insane not to just have the partial operator participate in scope somehow, directly, and to instead keep generating new crazy contexts via hackery like include.


@chickenwing solution is solid, but has a line that bothers me:

Handlebars.partials["template-partial"] = Handlebars.compile( sourcePartial );

A Handlebars compilation has to occur outside of the helper in order for it to work properly.

I think the following solution works well and uses the familiar Helper syntax with a clean partial declaration inside -

{{#eachIncludeParent context parent=this}}
    {{> template-partial}}
Handlebars.registerHelper('eachIncludeParent', function ( context, options ) {
    var fn = options.fn,
        inverse = options.inverse,
        ret = "",
        _context = [];
        $.each(context, function (index, object) {
            var _object = $.extend({}, object);
    if ( _context && _context.length > 0 ) {
        for ( var i = 0, j = _context.length; i < j; i++ ) {
            _context[i]["parentContext"] = options.hash.parent;
            ret = ret + fn(_context[i]);
    } else {
        ret = inverse(this);
    return ret;

Just submitted a pull request. The Helper now has no dependencies outside of Handlebars.

cscott commented Dec 14, 2012

I like the @chickenwing solution in so far as it also solves a related problem: passing arguments to partials. Much of what is done in code with helpers could be done with partials instead if only I could pass arguments into the partial's context...

c089 commented Mar 20, 2013

+1 on what @cscott said: This would allow to use partials instead of helpers which is absolutely essential when sharing templates between different implementations such as on the server-side and handlebars.js on the client. Writing a helper always requires two implementations in that case where the "include" from #368 would often be sufficient.


I wonder if @wycats is still actively supporting this project. Maybe he should give commit access to someone who would have time to go through the issues.


Yeah when users submit issues about this on our projects we have to keep explaining that "it's a handlebars problem". IMO this is so obvious it should be considered a bug, not a feature. It would be great to not have to address this anymore.

fguillen commented Sep 4, 2013

+1 for native support

jsFiddle that reproduces the issue


I'm wondering though, should it be up to each helper that change the context to make sure that the parent context is added to the child?


I looked into doing this without touching the helpers themselves and the problem I am struggling with is the multi threading and the stack part. I was able to append an object to the this object for each helper but the object being added is a JavaScript object for the node thread instead of the handlebars context


+1 for native support

Is anyone working on a pull request at the moment? If everyone +1-ing tried to take a look at implementing a solution, we'd have something by now. I'm happy to give it a go if no one else is...


I don't like the ../ support for a variety of reasons. They can add a significant amount of performance overhead as all of the local variables that are used to represent each context need to be packaged and passed to the partial since the caller doesn't know what the partial may need to access. Additionally this feels like a very good way to run into unexpected behavior or issues reusing partials in settings that have different context hierarchies.

I do like the suggestions of augmenting the context that have been made here and in the various linked PRs. This lets the caller opt in to any performance overhead and allows partials to define "api contracts" that the caller can adhere to rather than making assumptions about the context stack that the partial is being called in.

Rather than doing this as a helper as the PRs suggest I'm going to implement this within the partial execution logic itself so we can have one defacto method of accessing partials.

{{> foo bar=.. }}.

@kpdecker kpdecker merged commit 363cb4b into master Jan 18, 2014

1 check passed

default The Travis CI build passed
@kpdecker kpdecker deleted the partial-hash branch Jan 18, 2014
wycats commented Jan 18, 2014

@kpdecker I have always preferred "partial interfaces" to the risks of ..'ing into an arbitrary parent.



Released in v2.0.0-alpha.1

@dmarcotte dmarcotte added a commit to dmarcotte/intellij-plugins that referenced this pull request Nov 10, 2014
@dmarcotte dmarcotte Support parameters for partials
Partials can now take params, hashes.

See wycats/handlebars.js#182 for detail.
@SergeyZh SergeyZh pushed a commit to JetBrains/intellij-plugins that referenced this pull request Nov 11, 2014
@dmarcotte dmarcotte Support parameters for partials
Partials can now take params, hashes.

See wycats/handlebars.js#182 for detail.
@SergeyZh SergeyZh pushed a commit to JetBrains/intellij-plugins that referenced this pull request Nov 14, 2014
@dmarcotte @anstarovoyt dmarcotte + anstarovoyt Support parameters for partials
Partials can now take params, hashes.

See wycats/handlebars.js#182 for detail.
(cherry picked from commit 7625f54)
@shannonmoeller shannonmoeller referenced this pull request in shannonmoeller/handlebars-layouts Jan 24, 2015

Add params to #embed #14

@kkirsche kkirsche added a commit to kkirsche/ that referenced this pull request Feb 10, 2015
@kkirsche kkirsche Update handlebars from 1.0.0-rc.4 to 3.0.0
Update handlebars from 1.0.0-rc.4 to 3.0.0

## v3.0.0 - February 10th, 2015
- [#941](wycats/handlebars.js#941) - Add support for dynamic partial names ([@kpdecker](
- [#940](wycats/handlebars.js#940) - Add missing reserved words so compiler knows to use array syntax: ([@mattflaschen](
- [#938](wycats/handlebars.js#938) - Fix example using #with helper ([@diwo](
- [#930](wycats/handlebars.js#930) - Add parent tracking and mutation to AST visitors ([@kpdecker](
- [#926](wycats/handlebars.js#926) - Depthed lookups fail when program duplicator runs ([@kpdecker](
- [#918](wycats/handlebars.js#918) - Add instructions for 'spec/mustache' to, fix a few typos ([@oneeman](
- [#915](wycats/handlebars.js#915) - Ast update ([@kpdecker](
- [#910](wycats/handlebars.js#910) - Different behavior of {{@last}} when {{#each}} in {{#each}} ([@zordius](
- [#907](wycats/handlebars.js#907) - Implement named helper variable references ([@kpdecker](
- [#906](wycats/handlebars.js#906) - Add parser support for block params ([@mmun](
- [#903](wycats/handlebars.js#903) - Only provide aliases for multiple use calls ([@kpdecker](
- [#902](wycats/handlebars.js#902) - Generate Source Maps ([@kpdecker](
- [#901](wycats/handlebars.js#901) - Still escapes with noEscape enabled on isolated Handlebars environment ([@zedknight](
- [#896](wycats/handlebars.js#896) - Simplify BlockNode by removing intermediate MustacheNode ([@mmun](
- [#892](wycats/handlebars.js#892) - Implement parser for else chaining of helpers ([@kpdecker](
- [#889](wycats/handlebars.js#889) - Consider extensible parser API ([@kpdecker](
- [#887](wycats/handlebars.js#887) - Handlebars.noConflict() option? ([@bradvogel](
- [#886](wycats/handlebars.js#886) - Add SafeString to context (or use duck-typing) ([@dominicbarnes](
- [#870](wycats/handlebars.js#870) - Registering undefined partial throws exception. ([@max-b](
- [#866](wycats/handlebars.js#866) - comments don't respect whitespace control ([@75lb](
- [#863](wycats/handlebars.js#863) - + jsDelivr CDN info ([@tomByrer](
- [#858](wycats/handlebars.js#858) - Disable new default auto-indent at included partials ([@majodev](
- [#856](wycats/handlebars.js#856) - jspm compatibility ([@MajorBreakfast](
- [#805](wycats/handlebars.js#805) - Request: "strict" lookups ([@nzakas](

- Export the default object for handlebars/runtime - 5594416
- Lookup partials when undefined - 617dd57

Compatibility notes:
- Runtime breaking changes. Must match 3.x runtime and precompiler.
- The AST has been upgraded to a public API.
  - There are a number of changes to this, but the format is now documented in docs/
  - The Visitor API has been expanded to support mutation and provide a base implementation
- The `JavaScriptCompiler` APIs have been formalized and documented. As part of the sourcemap handling these should be updated to return arrays for concatenation.
- `JavaScriptCompiler.namespace` has been removed as it was unused.
- `SafeString` is now duck typed on `toHTML`

New Features:
- noConflict
- Source Maps
- Block Params
- Strict Mode
- @last and other each changes
- Chained else blocks
- @data methods can now have helper parameters passed to them
- Dynamic partials


## v2.0.0 - September 1st, 2014
- Update jsfiddle to 2.0.0-beta.1 - 0670f65
- Add contrib note regarding docs - 4d17e3c
- Play nice with gemspec version numbers - 64d5481


## v2.0.0-beta.1 - August 26th, 2014
- [#787](wycats/handlebars.js#787) - Remove whitespace surrounding standalone statements ([@kpdecker](
- [#827](wycats/handlebars.js#827) - Render false literal as “false” ([@scoot557](
- [#767](wycats/handlebars.js#767) - Subexpressions bug with hash and context ([@evensoul](
- Changes to 0/undefined handling
  - [#731](wycats/handlebars.js#731) - Strange behavior for {{#foo}} {{bar}} {{/foo}} when foo is 0 ([@kpdecker](
  - [#820](wycats/handlebars.js#820) - strange behavior for {{}} when foo is 0 or null or false ([@zordius](
  - [#837](wycats/handlebars.js#837) - Strange input for custom helper ( == false when foo is undefined ) ([@zordius](
- [#819](wycats/handlebars.js#819) - Implement recursive field lookup ([@kpdecker](
- [#764](wycats/handlebars.js#764) - This reference not working for helpers ([@kpdecker](
- [#773](wycats/handlebars.js#773) - Implicit parameters in {{#each}} introduces a peculiarity in helpers calling convention  ([@Bertrand](
- [#783](wycats/handlebars.js#783) - helperMissing and consistency for different expression types ([@ErisDS](
- [#795](wycats/handlebars.js#795) - Turn the precompile script into a wrapper around a module. ([@jwietelmann](
- [#823](wycats/handlebars.js#823) - Support inverse sections on the with helper ([@dan-manges](
- [#834](wycats/handlebars.js#834) - Refactor blocks, programs and inverses ([@mmun](
- [#852](wycats/handlebars.js#852) - {{foo~}} space control behavior is different from older version ([@zordius](
- [#835](wycats/handlebars.js#835) - Templates overwritten if file is loaded twice

- Expose escapeExpression on the root object - 980c38c
- Remove nested function eval in blockHelperMissing - 6f22ec1
- Fix compiler program de-duping - 9e3f824

Compatibility notes:
- The default build now outputs a generic UMD wrapper. This should be transparent change but may cause issues in some environments.
- Runtime compatibility breaks in both directions. Ensure that both compiler and client are upgraded to 2.0.0-beta.1 or higher at the same time.
  - `programWithDepth` has been removed an instead an array of context values is passed to fields needing depth lookups.
- `false` values are now printed to output rather than silently dropped
- Lines containing only block statements and whitespace are now removed. This matches the Mustache spec but may cause issues with code that expects whitespace to exist but would not otherwise.
- Partials that are standalone will now indent their rendered content
- `AST.ProgramNode`'s signature has changed.
- Numerious methods/features removed from psuedo-API classes
  - `JavaScriptCompiler.register`
  - `JavaScriptCompiler.replaceStack` no longer supports non-inline replace
  - `Compiler.disassemble`
  - `DECLARE` opcode
  - `strip` opcode
  - `lookup` opcode
  - Content nodes may have their `string` values mutated over time. `original` field provides the unmodified value.
- Removed unused `Handlebars.registerHelper` `inverse` parameter
- `each` helper requires iterator parameter


## v2.0.0-alpha.4 - May 19th, 2014
- Expose setup wrappers for compiled templates - 3638874


## v2.0.0-alpha.3 - May 19th, 2014
- [#797](wycats/handlebars.js#797) - Pass full helper ID to helperMissing when options are provided ([@tomdale](
- [#793](wycats/handlebars.js#793) - Ensure isHelper is coerced to a boolean ([@mmun](
- Refactor template init logic - 085e5e1


## v2.0.0-alpha.2 - March 6th, 2014
- [#756](wycats/handlebars.js#756) - fix bug in IE<=8 (no Array::map), closes #751 ([@jenseng](
- [#749](wycats/handlebars.js#749) - properly handle multiple subexpressions in the same hash, fixes #748 ([@jenseng](
- [#743](wycats/handlebars.js#743) - subexpression confusion/problem? ([@waynedpj](
- [#746](wycats/handlebars.js#746) - [CLI] support `handlebars --version` ([@apfelbox](
- [#747](wycats/handlebars.js#747) - updated grunt-saucelabs, failing tests revealed ([@Jonahss](
- Make JSON a requirement for the compiler. - 058c0fb
- Temporarily kill the AWS publish CI step - 8347ee2

Compatibility notes:
- A JSON polyfill is required to run the compiler under IE8 and below. It's recommended that the precompiler be used in lieu of running the compiler on these legacy environments.


## v2.0.0-alpha.1 - February 10th, 2014
- [#182](wycats/handlebars.js#182) - Allow passing hash parameters to partials ([@kpdecker](
- [#392](wycats/handlebars.js#392) - Access to root context in partials and helpers ([@kpdecker](
- [#472](wycats/handlebars.js#472) - Helpers cannot have decimal parameters ([@kayleg](
- [#569](wycats/handlebars.js#569) - Unable to lookup array values using @index ([@kpdecker](
- [#491](wycats/handlebars.js#491) - For nested helpers: get the @ variables of the outer helper from the inner one ([@kpdecker](
- [#669](wycats/handlebars.js#669) - Ability to unregister a helper ([@dbachrach](
- [#730](wycats/handlebars.js#730) - Raw block helpers ([@kpdecker](
- [#634](wycats/handlebars.js#634) - It would be great to have the helper name passed to `blockHelperMissing` ([@kpdecker](
- [#729](wycats/handlebars.js#729) - Convert template spec to object literal ([@kpdecker](

- [#658](wycats/handlebars.js#658) - Depthed helpers do not work after an upgrade from 1.0.0 ([@xibxor](
- [#671](wycats/handlebars.js#671) - Crashes on no-parameter {{#each}} ([@stepancheg](
- [#689](wycats/handlebars.js#689) - broken template precompilation ([@AAS](
- [#698](wycats/handlebars.js#698) - Fix parser generation under windows ([@osiris43](
- [#699](wycats/handlebars.js#699) - @DATA not compiles to invalid JS in stringParams mode ([@kpdecker](
- [#705](wycats/handlebars.js#705) - 1.3.0 can not be wrapped in an IIFE ([@craigteegarden](
- [#706](wycats/handlebars.js#706) - README: Use with helper instead of relying on blockHelperMissing ([@scottgonzalez](

- [#700](wycats/handlebars.js#700) - Remove redundant conditions ([@blakeembrey](
- [#704](wycats/handlebars.js#704) - JavaScript Compiler Cleanup ([@blakeembrey](

Compatibility notes:
- `helperMissing` helper no longer has the indexed name argument. Helper name is now available via ``.
- Precompiler output has changed, which breaks compatibility with prior versions of the runtime and precompiled output.
- `JavaScriptCompiler.compilerInfo` now returns generic objects rather than javascript source.
- AST changes
  - Additional PartialNode hash parameter
  - New RawBlockNode type
- Data frames now have a `_parent` field. This is internal but is enumerable for performance/compatability reasons.


## v1.3.0 - January 1st, 2014
- [#690](wycats/handlebars.js#690) - Added support for subexpressions ([@machty](
- [#696](wycats/handlebars.js#696) - Fix for reserved keyword "default" ([@nateirwin](
- [#692](wycats/handlebars.js#692) - add line numbers to nodes when parsing ([@fivetanley](
- [#695](wycats/handlebars.js#695) - Pull options out from param setup to allow easier extension ([@blakeembrey](
- [#694](wycats/handlebars.js#694) - Make the environment reusable ([@blakeembrey](
- [#636](wycats/handlebars.js#636) - Print line and column of errors ([@sgronblo](
- Use literal for data lookup - c1a93d3
- Add stack handling sanity checks - cd885bf
- Fix stack id "leak" on replaceStack - ddfe457
- Fix incorrect stack pop when replacing literals - f4d337d


## v1.2.1 - December 26th, 2013
- [#684](wycats/handlebars.js#684) - Allow any number of trailing characters for valid JavaScript variable ([@blakeembrey](
- [#686](wycats/handlebars.js#686) - Falsy AMD module names in version 1.2.0 ([@kpdecker](


## v1.2.0 - December 23rd, 2013
- [#675](wycats/handlebars.js#675) - Cannot compile empty template for partial ([@erwinw](
- [#677](wycats/handlebars.js#677) - Triple brace statements fail under IE ([@hamzaCM](
- [#655](wycats/handlebars.js#655) - Loading Handlebars using bower ([@niki4810](
- [#657](wycats/handlebars.js#657) - Fixes issue where cli compiles non handlebars templates ([@chrishoage](
- [#681](wycats/handlebars.js#681) - Adds in-browser testing and Saucelabs CI ([@kpdecker](
- [#661](wycats/handlebars.js#661) - Add @first and @index to #each object iteration ([@cgp](
- [#650](wycats/handlebars.js#650) - Handlebars is MIT-licensed ([@thomasboyt](
- [#641](wycats/handlebars.js#641) - Document ember testing process ([@kpdecker](
- [#662](wycats/handlebars.js#662) - handlebars-source 1.1.2 is missing from RubyGems.
- [#656](wycats/handlebars.js#656) - Expose COMPILER_REVISION checks as a hook ([@machty](
- [#668](wycats/handlebars.js#668) - Consider publishing handlebars-runtime as a separate module on npm ([@dlmanning](
- [#679](wycats/handlebars.js#679) - Unable to override invokePartial ([@mattbrailsford](
- [#646](wycats/handlebars.js#646) - Fix "\\{{" immediately following "\{{" ([@dmarcotte](
- Allow extend to work with non-prototyped objects - eb53f2e
- Add JavascriptCompiler public API tests - 1a751b2
- Add AST test coverage for more complex paths - ddea5be
- Fix handling of boolean escape in MustacheNode - b4968bb

Compatibility notes:
- `@index` and `@first` are now supported for `each` iteration on objects
- `Handlebars.VM.checkRevision` and `Handlebars.JavaScriptCompiler.prototype.compilerInfo` now available to modify the version checking behavior.
- Browserify users may link to the runtime library via `require('handlebars/runtime')`


## v1.1.2 - November 5th, 2013

- [#645](wycats/handlebars.js#645) - 1.1.1 fails under IE8 ([@kpdecker](
- [#644](wycats/handlebars.js#644) - Using precompiled templates (AMD mode) with handlebars.runtime 1.1.1 ([@fddima](

- Add simple binary utility tests - 96a45a4
- Fix empty string compilation - eea708a


## v1.1.1 - November 4th, 2013

- [#642](wycats/handlebars.js#642) - handlebars 1.1.0 are broken with nodejs

- Fix release notes link - 17ba258


## v1.1.0 - November 3rd, 2013

- [#628](wycats/handlebars.js#628) - Convert code to ES6 modules ([@kpdecker](
- [#336](wycats/handlebars.js#336) - Add whitespace control syntax ([@kpdecker](
- [#535](wycats/handlebars.js#535) - Fix for probable JIT error under Safari ([@sorentwo](
- [#483](wycats/handlebars.js#483) - Add first and last @ vars to each helper ([@denniskuczynski](
- [#557](wycats/handlebars.js#557) - `\\{{foo}}` escaping only works in some situations ([@dmarcotte](
- [#552](wycats/handlebars.js#552) - Added BOM removal flag. ([@blessenm](
- [#543](wycats/handlebars.js#543) - publish passing master builds to s3 ([@fivetanley](

- [#608](wycats/handlebars.js#608) - Add `includeZero` flag to `if` conditional
- [#498](wycats/handlebars.js#498) - `Handlebars.compile` fails on empty string although a single blank works fine
- [#599](wycats/handlebars.js#599) - lambda helpers only receive options if used with arguments
- [#592](wycats/handlebars.js#592) - Optimize array and subprogram performance
- [#571](wycats/handlebars.js#571) - uglify upgrade breaks compatibility with older versions of node
- [#587](wycats/handlebars.js#587) - Partial inside partial breaks?

Compatibility notes:
- The project now includes separate artifacts for AMD, CommonJS, and global objects.
  - AMD: Users may load the bundled `handlebars.amd.js` or `handlebars.runtime.amd.js` files or load individual modules directly. AMD users should also note that the handlebars object is exposed via the `default` field on the imported object. This [gist]( provides some discussion of possible compatibility shims.
  - CommonJS/Node: Node loading occurs as normal via `require`
  - Globals: The `handlebars.js` and `handlebars.runtime.js` files should behave in the same manner as the v1.0.12 / 1.0.0 release.
- Build artifacts have been removed from the repository. [npm][npm], [components/handlebars.js][components], [cdnjs][cdnjs], or the [builds page][builds-page] should now be used as the source of built artifacts.
- Context-stored helpers are now always passed the `options` hash. Previously no-argument helpers did not have this argument.


## v1.0.12 / 1.0.0 - May 31 2013

- [#515](wycats/handlebars.js#515) - Add node require extensions support ([@jjclark1982](
- [#517](wycats/handlebars.js#517) - Fix amd precompiler output with directories ([@blessenm](
- [#433](wycats/handlebars.js#433) - Add support for unicode ids
- [#469](wycats/handlebars.js#469) - Add support for `?` in ids
- [#534](wycats/handlebars.js#534) - Protect from object prototype modifications
- [#519](wycats/handlebars.js#519) - Fix partials with . name ([@jamesgorrie](
- [#519](wycats/handlebars.js#519) - Allow ID or strings in partial names
- [#437](wycats/handlebars.js#437) - Require matching brace counts in escaped expressions
- Merge passed partials and helpers with global namespace values
- Add support for complex ids in @data references
- Docs updates

Compatibility notes:
- The parser is now stricter on `{{{`, requiring that the end token be `}}}`. Templates that do not
  follow this convention should add the additional brace value.
- Code that relies on global the namespace being muted when custom helpers or partials are passed will need to explicitly pass an `undefined` value for any helpers that should not be available.
- The compiler version has changed. Precompiled templates with 1.0.12 or higher must use the 1.0.0 or higher runtime.


## v1.0.11 / 1.0.0-rc4 - May 13 2013

- [#458](wycats/handlebars.js#458) - Fix `./foo` syntax ([@jpfiset](
- [#460](wycats/handlebars.js#460) - Allow `:` in unescaped identifers ([@jpfiset](
- [#471](wycats/handlebars.js#471) - Create release notes (These!)
- [#456](wycats/handlebars.js#456) - Allow escaping of `\\`
- [#211](wycats/handlebars.js#211) - Fix exception in `escapeExpression`
- [#375](wycats/handlebars.js#375) - Escape unicode newlines
- [#461](wycats/handlebars.js#461) - Do not fail when compiling `""`
- [#302](wycats/handlebars.js#302) - Fix sanity check in knownHelpersOnly mode
- [#369](wycats/handlebars.js#369) - Allow registration of multiple helpers and partial by passing definition object
- Add bower package declaration ([@DevinClark](
- Add NuSpec package declaration ([@MikeMayer](
- Handle empty context in `with` ([@thejohnfreeman](
- Support custom template extensions in CLI ([@matteoagosti](
- Fix Rhino support ([@broady](
- Include contexts in string mode ([@leshill](
- Return precompiled scripts when compiling to AMD ([@JamesMaroney](
- Docs updates ([@iangreenleaf](, [@gilesbowkett](, [@utkarsh2012](
- Fix `toString` handling under IE and browserify ([@tommydudebreaux](
- Add program metadata
@kkirsche kkirsche referenced this pull request in rubyloco/ Feb 10, 2015

Update handlebars from 1.0.0-rc.4 to 3.0.0 #16


Where is this documented? If it's not, then I would gladly send the pull request for updating the docs if it meant one less developer had to go implement his own 'include' helper ;)

@mattkime mattkime referenced this pull request in jknack/ Apr 7, 2015

support passing hash to partials #357


@jfbrennan I just pushed docs for this to the site but glad to take any improvements you might be able to offer!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment