Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement named helper variable references #907

Closed
kpdecker opened this issue Nov 13, 2014 · 20 comments
Closed

Implement named helper variable references #907

kpdecker opened this issue Nov 13, 2014 · 20 comments
Labels
Milestone

Comments

@kpdecker
Copy link
Collaborator

Implement the remainder of the feature started in #906.

We want to allow for helpers to provide named values that may be accessed by any child program run. The goal is to allow explicit naming of helper data fields so they can easily be accessed in nested scope, vs. arbitrary @../index references.

For example:

{{#each foos as |foo indexFoo|}}
  {{#each bars as |bar indexBar|}}
    {{indexFoo}}.{{indexBar}}. {{foo}} {{bar}}
  {{/each}}
{{/each}}
@kpdecker kpdecker added this to the 3.0 milestone Nov 13, 2014
@kpdecker
Copy link
Collaborator Author

@wycats @mmun any thoughts on how these should interact with partials? Compat mode?

@wycats
Copy link
Collaborator

wycats commented Nov 13, 2014

What is the exact current status of partial state inheritance?

@mmun
Copy link
Contributor

mmun commented Nov 13, 2014

A couple notes...

  1. I didn't implement block params on inverses, but it seems like something worth exploring. For example
{{my-each items as |item|}}
  {{item.name}}
{{else as |error|}}
  {{error.message}}
{{/my-each}}

This might be annoying to implement because {{each}} is just a token and because of some ambiguities with inverse blocks {{else foo}}{{/foo}}. Maybe you already worked this stuff out with your inverse chaining work.

  1. For backwards compatibility / to ease transitioning, you may want to tag child templates with options.fn.hasBlockParams = true;, options.inverse.hasBlockParams = true;, etc. This will give the helper an opportunity to use an old API. For example in ember we will support the new syntax {{#each items in |item|}} but we might also want to accept the old pseudosyntax that Ember invented {{#each item in items}} if no block params were passed. Though it could probably just be inferred from arguments.length.

  2. I think partial should reset the environment/stack frame/data/whatever :). I guess it mostly depends on how you are doing it now and what your users expect. This actually raises another issue: there's no syntax for defining block params on the root program. It may not be necessary in practice, but I'm not sure. I think @wycats has some insights on this topic.

@kpdecker
Copy link
Collaborator Author

@wycats When in compat mode, Partials will resolve through the parent scope in the same manner as other lookups. If in the default mode, only parameters explicitly passed via the partial hash construct.

For the non-compat mode I think its a no brainer that these should not apply. When compat mode is set I think there are some ways that we can have the similar behavior with minimal additional overhead but I'm not sure if it matter that much.

@mmun 1) I had not thought of that case but it certainly adds a lot of complexity. What happens with chained helpers? Who is the provider of the final set of parameters?

@mmun
Copy link
Contributor

mmun commented Nov 13, 2014

I'm not too sure how chained helpers work. Are there other use cases besides if? How does the fall through to the next else work one?

@kpdecker
Copy link
Collaborator Author

Chained helpers are basically syntactic sugar for this fall through construct:

{{#if foo}}
{{else}}
  {{#anyHelper}}
  {{else}}
  {{/anyHelper}}
{{/if}}

but are written as

{{#if foo}}
{{else anyHelper}}
{{else}}
{{/if}}

I think we are better off leaving this feature off of simple else cases as they are ambiguous and I'm not sure what the use case would be. The chained else should still support it in the positive case (we should check the parser for that).

@mmun
Copy link
Contributor

mmun commented Nov 13, 2014

Ah that makes sense. Leaving it off else is fine with me.

@kpdecker
Copy link
Collaborator Author

@mmun what API is being exposed to helpers for this in HTMLbars? Right now something like:

fn(context[key], { data: data, blockParams: [context[key], key] })

Is the winner for me personally. I don't want to play games with argv and having options at the end of the list like helpers implement now and the only other thing that comes to mind is some sort of setter API.

fn.blockParams([context[key], key]);
fn(context[key], { data: data })

Which I'm not certain that I'm keen on.

Also, getting into it, the question of if this should be conditional or not occurs. I.e. if someone does {{#each foo as |bar|}} should the context change or should bar be the only way to access the iteration object? More generically, should helpers be made aware that block params were passed or not?

@mmun
Copy link
Contributor

mmun commented Nov 29, 2014

First, HTMLBars has diverged in the template structure (and will probably diverge even more). The signature currently is

fn(context, options/environment, contextualDOMElement, arrayOfBlockParams)

We are planning on making templates first class objects soon so that we can store cached computations and reduce closures. Your second suggestion is interesting.

Secondly, In HTMLBars we are passing the number of block params to the helper (as options.blockParams) so that the helper can choose to yield only the values that the template has defined names for. It can also be used for backwards compatibility (by checking if options.blockParams is 0 or undefined or something).

We are not passing the names of the block params because that will inevitably lead to people yielding different values based on the name. Unfortunately, knowing the number of block params still is a bit sketchy because a helper-writer may choose to permute the arguments based on the number of block params, e.g. {{#each items as |item|}} and {{#each items as |index item|}}. But ultimately performance won over "correctness".

@kpdecker
Copy link
Collaborator Author

Signature: Ok, sounds like things are distinct enough (there are numerous helper differences anyway, that was one of the sticking points of the merge)
Number: Agreed that it should be available
Names: Also agreed that it should not be available. That fully breaks the whole premise of being able to provide distinct names for nested args.

String params mode will be an interesting one to handle. Does Ember plan on supporting classical Handlebars in the first release that has block params or is everyone expected to be running HTMLbars on upgrade?

@kpdecker
Copy link
Collaborator Author

Released in 3.0.0

kkirsche pushed a commit to kkirsche/rubyloco.com that referenced this issue Feb 10, 2015
Update handlebars from 1.0.0-rc.4 to 3.0.0

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

[Commits](handlebars-lang/handlebars.js@v2.0.0...v3.0.0)

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

[Commits](handlebars-lang/handlebars.js@v2.0.0-beta.1...v2.0.0)

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

[Commits](handlebars-lang/handlebars.js@v2.0.0-alpha.4...v2.0.0-beta.1)

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

[Commits](handlebars-lang/handlebars.js@v2.0.0-alpha.3...v2.0.0-alpha.4)

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

[Commits](handlebars-lang/handlebars.js@v2.0.0-alpha.2...v2.0.0-alpha.3)

## v2.0.0-alpha.2 - March 6th, 2014
- [#756](handlebars-lang/handlebars.js#756) - fix bug in IE<=8 (no Array::map), closes #751 ([@jenseng](https://api.github.com/users/jenseng))
- [#749](handlebars-lang/handlebars.js#749) - properly handle multiple subexpressions in the same hash, fixes #748 ([@jenseng](https://api.github.com/users/jenseng))
- [#743](handlebars-lang/handlebars.js#743) - subexpression confusion/problem? ([@waynedpj](https://api.github.com/users/waynedpj))
- [#746](handlebars-lang/handlebars.js#746) - [CLI] support `handlebars --version` ([@apfelbox](https://api.github.com/users/apfelbox))
- [#747](handlebars-lang/handlebars.js#747) - updated grunt-saucelabs, failing tests revealed ([@Jonahss](https://api.github.com/users/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.

[Commits](handlebars-lang/handlebars.js@v2.0.0-alpha.1...v2.0.0-alpha.2)

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

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

- [#700](handlebars-lang/handlebars.js#700) - Remove redundant conditions ([@blakeembrey](https://api.github.com/users/blakeembrey))
- [#704](handlebars-lang/handlebars.js#704) - JavaScript Compiler Cleanup ([@blakeembrey](https://api.github.com/users/blakeembrey))

Compatibility notes:
- `helperMissing` helper no longer has the indexed name argument. Helper name is now available via `options.name`.
- 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
  - INTEGER -> NUMBER
  - Additional PartialNode hash parameter
  - New RawBlockNode type
- Data frames now have a `_parent` field. This is internal but is enumerable for performance/compatability reasons.

[Commits](handlebars-lang/handlebars.js@v1.3.0...v2.0.0-alpha.1)

## v1.3.0 - January 1st, 2014
- [#690](handlebars-lang/handlebars.js#690) - Added support for subexpressions ([@machty](https://api.github.com/users/machty))
- [#696](handlebars-lang/handlebars.js#696) - Fix for reserved keyword "default" ([@nateirwin](https://api.github.com/users/nateirwin))
- [#692](handlebars-lang/handlebars.js#692) - add line numbers to nodes when parsing ([@fivetanley](https://api.github.com/users/fivetanley))
- [#695](handlebars-lang/handlebars.js#695) - Pull options out from param setup to allow easier extension ([@blakeembrey](https://api.github.com/users/blakeembrey))
- [#694](handlebars-lang/handlebars.js#694) - Make the environment reusable ([@blakeembrey](https://api.github.com/users/blakeembrey))
- [#636](handlebars-lang/handlebars.js#636) - Print line and column of errors ([@sgronblo](https://api.github.com/users/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

[Commits](handlebars-lang/handlebars.js@v1.2.1...v1.3.0)

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

[Commits](handlebars-lang/handlebars.js@v1.2.0...v1.2.1)

## v1.2.0 - December 23rd, 2013
- [#675](handlebars-lang/handlebars.js#675) - Cannot compile empty template for partial ([@erwinw](https://api.github.com/users/erwinw))
- [#677](handlebars-lang/handlebars.js#677) - Triple brace statements fail under IE ([@hamzacm](https://api.github.com/users/hamzaCM))
- [#655](handlebars-lang/handlebars.js#655) - Loading Handlebars using bower ([@niki4810](https://api.github.com/users/niki4810))
- [#657](handlebars-lang/handlebars.js#657) - Fixes issue where cli compiles non handlebars templates ([@chrishoage](https://api.github.com/users/chrishoage))
- [#681](handlebars-lang/handlebars.js#681) - Adds in-browser testing and Saucelabs CI ([@kpdecker](https://api.github.com/users/kpdecker))
- [#661](handlebars-lang/handlebars.js#661) - Add @FIRST and @Index to #each object iteration ([@cgp](https://api.github.com/users/cgp))
- [#650](handlebars-lang/handlebars.js#650) - Handlebars is MIT-licensed ([@thomasboyt](https://api.github.com/users/thomasboyt))
- [#641](handlebars-lang/handlebars.js#641) - Document ember testing process ([@kpdecker](https://api.github.com/users/kpdecker))
- [#662](handlebars-lang/handlebars.js#662) - handlebars-source 1.1.2 is missing from RubyGems.
- [#656](handlebars-lang/handlebars.js#656) - Expose COMPILER_REVISION checks as a hook ([@machty](https://api.github.com/users/machty))
- [#668](handlebars-lang/handlebars.js#668) - Consider publishing handlebars-runtime as a separate module on npm ([@dlmanning](https://api.github.com/users/dlmanning))
- [#679](handlebars-lang/handlebars.js#679) - Unable to override invokePartial ([@mattbrailsford](https://api.github.com/users/mattbrailsford))
- [#646](handlebars-lang/handlebars.js#646) - Fix "\\{{" immediately following "\{{" ([@dmarcotte](https://api.github.com/users/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')`

[Commits](handlebars-lang/handlebars.js@v1.1.2...v1.2.0)

## v1.1.2 - November 5th, 2013

- [#645](handlebars-lang/handlebars.js#645) - 1.1.1 fails under IE8 ([@kpdecker](https://api.github.com/users/kpdecker))
- [#644](handlebars-lang/handlebars.js#644) - Using precompiled templates (AMD mode) with handlebars.runtime 1.1.1 ([@fddima](https://api.github.com/users/fddima))

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

[Commits](handlebars-lang/handlebars.js@v1.1.1...v1.1.2)

## v1.1.1 - November 4th, 2013

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

- Fix release notes link - 17ba258

[Commits](handlebars-lang/handlebars.js@v1.1.0...v1.1.1)

## v1.1.0 - November 3rd, 2013

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

- [#608](handlebars-lang/handlebars.js#608) - Add `includeZero` flag to `if` conditional
- [#498](handlebars-lang/handlebars.js#498) - `Handlebars.compile` fails on empty string although a single blank works fine
- [#599](handlebars-lang/handlebars.js#599) - lambda helpers only receive options if used with arguments
- [#592](handlebars-lang/handlebars.js#592) - Optimize array and subprogram performance
- [#571](handlebars-lang/handlebars.js#571) - uglify upgrade breaks compatibility with older versions of node
- [#587](handlebars-lang/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](https://gist.github.com/wycats/7417be0dc361a69d5916) 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.

[Commits](handlebars-lang/handlebars.js@v1.0.12...v1.1.0)

## v1.0.12 / 1.0.0 - May 31 2013

- [#515](handlebars-lang/handlebars.js#515) - Add node require extensions support ([@jjclark1982](https://github.com/jjclark1982))
- [#517](handlebars-lang/handlebars.js#517) - Fix amd precompiler output with directories ([@blessenm](https://github.com/blessenm))
- [#433](handlebars-lang/handlebars.js#433) - Add support for unicode ids
- [#469](handlebars-lang/handlebars.js#469) - Add support for `?` in ids
- [#534](handlebars-lang/handlebars.js#534) - Protect from object prototype modifications
- [#519](handlebars-lang/handlebars.js#519) - Fix partials with . name ([@jamesgorrie](https://github.com/jamesgorrie))
- [#519](handlebars-lang/handlebars.js#519) - Allow ID or strings in partial names
- [#437](handlebars-lang/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.

[Commits](handlebars-lang/handlebars.js@v1.0.11...v1.0.12)

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

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

ErisDS commented Jul 9, 2015

Could I please trouble someone for a little help understanding how this works? I've been trawling through the code changes, tests, and trying it out, and although I've got it working, I'm not sure on a few things. I'll explain what I understand so far, and hopefully this'll end up being a sort of documentation 😁

Taking the first block param test as an example:

it('should take presedence over context values', function() {
    var hash = {value: 'foo'};
    var helpers = {
      goodbyes: function(options) {
        equals(options.fn.blockParams, 1);
        return options.fn({value: 'bar'}, {blockParams: [1, 2]});
      }
    };
    shouldCompileTo('{{#goodbyes as |value|}}{{value}}{{/goodbyes}}{{value}}', [hash, helpers], '1foo');
});

Inside a block helper, if a block param was specified when the helper was called, we now get access to options.fn.blockParams which tells us how many block params the user asked for. In this case it was just 1, which was declared as value.

When we call fn, we pass the context as the first argument, and can now pass a blockParams option as a property on the second (options?) argument. blockParams should be an array.

The first item of the array is the data we want to resolve for our blockParam. In the the test, the value block param is going to resolve to 1. The test shows that 1 gets output instead of bar which is the value of value in the context, asserting that the block param takes precedence.

What I don't understand, is what the second item of the array 2 is for? Is this purely for testing purposes to show that passing extra block params doesn't do anything, or does it mean something else?

The #each implementation passes an array with 2 properties, essentially the value and the index as you'd expect. It does this regardless of whether 1 or 2 block params are declared when calling the helper. I guess it's simpler to always pass both rather than checking to see what was declared.

The #each helper also adds a path property to the blockParams array, which so far for me always evaluates to [ NaN, null ]. I'm not at all sure what this path property is for, or when it comes into play - it seems to be related to contextPath but I'm not clear on what that is either!

Basically, I'm trying to figure out exactly what's needed and why in order to determine what might be necessary in a custom helper. Thanks in advance!

@kpdecker
Copy link
Collaborator Author

@ErisDS we need to do a better job of documenting this for implementors of helpers.

Your analysis is pretty much spot on, and it might be a good thing for us to pull this into the formal docs.

Yes, 2 is strictly for testing. Wanted to make sure that it didn't blow up if additional values are passed and didn't want the extra time cost of another test for that case explicitly.

Context path is a little used feature similar to the strings mode used by Ember. This is a little used feature that allows code to attempt to lookup a data field from the root context value based on handlebar's iteration. I believe the only consumer of this is Thorax's SSJS implementation and you can likely ignore if you aren't touching that.

@ErisDS
Copy link
Collaborator

ErisDS commented Jul 27, 2015

Context path is a little used feature similar to the strings mode used by Ember. This is a little used feature that allows code to attempt to lookup a data field from the root context value based on handlebar's iteration. I believe the only consumer of this is Thorax's SSJS implementation and you can likely ignore if you aren't touching that.

Do you have a reference link to any sort of example of this in action that I can take a peek at? If I manage to understand it I'll have a go at writing up an in depth explanation.

Just an FYI - I wrote some documentation on Handlebars for Ghost theme developers: http://themes.ghost.org/docs/handlebars not sure if it's helpful but please steal from it if it is.

@kpdecker
Copy link
Collaborator Author

kpdecker commented Aug 1, 2015

@ErisDS the built in helpers implement context path tracking and there is test coverage. https://github.com/wycats/handlebars.js/blob/master/spec/track-ids.js#L140. The only existing documentation is https://github.com/wycats/handlebars-site/blob/master/src/pages/reference.haml#L338.

@kpdecker
Copy link
Collaborator Author

kpdecker commented Aug 1, 2015

@ErisDS wycats/handlebars-site@33feeb9 has an attempt at this. I always feel like my documentation skills are lacking so any input is appreciated. I actively chose to ignore the context path behaviors in the docs as I think it's a very niche use case that will only confuse further in the basic docs. If we do provide better docs, then it's probably better to document it in a section specific to that.

@Bertrand
Copy link

@kpdecker I'm currently integrating this in handlebars-objc, and from what I understand from JS implementation, context provided by the helper can be different from the first block parameter.
I find this very confusing and I cannot find any useful use case.

Did you have anything specific in mind?

@Bertrand
Copy link

@kpdecker Oh,maybe you wanted block helpers to be able to set named block params without changing current context. Is that it?

@kpdecker
Copy link
Collaborator Author

Context and block helpers are completely separate. That they match in each is just a function of that specific helper.

@Bertrand
Copy link

@kpdecker yep, that is what I figured out. I was just trying to find an example of a helper where this was both useful and not totally confusing for users.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants