| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
Allow for iteration on undefined values, but special case undefined and null to prevent rendering errors when not running in strict mode.
Fixes #1093
|
| |
|
| |
|
|
|
|
| |
These allow for a given block to be wrapped in helper methods or metadata and allow for more control over the current container and method before the code is run.
|
|
|
| |
There is no real need for us to do `.call(container` other than for backwards compatibility with legacy versions. Using the 4.x release as a chance to optimize this behavior.
|
| |
|
|
|
|
|
| |
This allows for `{{helper foo}}` to still operate under strict mode when `foo` is not defined on the context. This allows helpers to perform whatever existence checks they please so patterns like `{{#if foo}}{{foo}}{{/if}}` can be used to protect against missing values.
Fixes #1063
|
|
|
|
| |
The ‘ character would cause invalid javascript to be generated as it was not properly escaped. Switching to JSON.stringify safely handles all potential unescaped cases.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Converts the tool chain to use babel, eslint, and webpack vs. the previous proprietary solutions.
Additionally begins enforcing additional linting concerns as well as updates the code to reflect these rules.
Fixes #855
Fixes #993
|
|
|
|
|
|
|
|
|
| |
Uses the subexpression syntax to allow for dynamic partial lookups. Ex:
```
{{> (helper) }}
```
Fixes #933
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* await
* null
* true
* false
IE 8 was failing to compile Handlebars-generated source code
because it had helpers.null.
I came up with this list by diffing
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Lexical_grammar#Keywords
against the ones Handlebars already had.
I added two corresponding tests for nameLookup.
|
|
|
|
|
|
|
|
| |
Causes templates to throw when lookup fields are not defined within the context. Strict mode will throw when any field is omitted. assumeObjects mode maintains the existing behavior of outputting an empty response when fields are not defined but allows for performance/size optimizations by not doing safety checks for intermediate objects in the lookup chain.
Strict mode effectively disables the helperMissing and inverse handling for blockHelperMissing as templates will throw rather than call those features for missing data fields.
Fixes #651
Fixes #805
|
| |
|
| |
|
|
|
| |
Fixes #907
|
| |
|
|
|
|
|
| |
Fixes a very specific error case where deduped children won’t receive the depths object due to it being omitted by the caller when optimizing.
Fixes #926
|
| |
|
|
|
|
| |
This is no longer necessary with the depths array tracking and adds compiler overhead.
|
| |
|
| |
|
|
|
| |
This helps unify the code handling and will also be needed to support string/id tracking on partials.
|
| |
|
|
|
| |
This is a breaking change for string mode users as there is no longer a distinct type for data parameters. Instead data consumers should look for the @ prefix value.
|
|
|
| |
Part of #889
|
| |
|
|
|
| |
Fixes #901
|
|
|
| |
Fixes #903
|
| |
|
|
|
|
|
|
| |
Allow the precompiler to generate source maps when the srcFile parameter is passed.
This refactors large chunks of the code generation pipeline, allowing metadata to be associated with code chunks as well as breaking out much of the code generation logic into a separate helper.
|
| |
|
| |
|
| |
|
|
|
|
| |
We don’t want to remove these as the generic code may need it in the future, but these code paths are not triggered through the existing language constructs.
|
| |
|
| |
|
|
|
|
| |
Allows for append operations to avoid breaking inline chain.
|
|
|
| |
Fixes #827
|
| |
|
|
|
|
| |
Fixes #318 (regression)
Partial fix for #783
|
| |
|
|
|
|
|
| |
We already have to track these behaviors for the standalone parsing and rather than having two whitespace pruning implementations this moves all of the behavior into one place.
Fixes #852
|
|
|
| |
Only use case was with inline input so most of this code was unnecessary.
|
| |
|
|
|
|
|
|
| |
They are no longer duplicated with the new helper calling pattern and this also introduced stack corruption issues due to improper value lookups.
Fixes #767
Fixes #768
|
|
|
|
| |
Fixes #837
|
| |
|
| |
|
|
|
| |
Prevents duplicate calls from being made.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Provides the mustache behavior of recursive lookup without the use of depthed paths.
Note that this does incur a fairly dramatic performance penalty for depthed queries.
|
|
|
| |
Approximately doubles the throughput performance of depthed templates and clears the way for doing recursive path lookups in pathed mode.
|
| |
|
| |
|
| |
|
|
|
|
| |
Fixes #764
|
|
|
|
| |
Fixes #820
|
|
|
| |
Final change for #731
|
|
|
|
|
|
|
| |
- Move the lookup null protection out of `nameLookup` and into that contexts that are aware of the needs for falsy vs. not displayed values.
- Optimize lookup for nested path operations
Fixes #731
|
|
|
| |
This has a very positive impact on precompiled output size, particularly for known-helpers cases, and little or no impact on the throughput numbers.
|
|
|
| |
Fixes #772
|
|
|
| |
Fixes #743
|
|\
| |
| | |
properly handle multiple subexpressions in the same hash, fixes #748
|
| |
| |
| |
| |
| | |
push all hash params before popping any so as to avoid the last stackN var
stomping previous ones
|
|/
|
|
|
|
|
| |
looks like this broke in 2812fe27
also s/this.i/var i/, since the functions that needed it were removed in
a1edab6ef
|
| |
|
| |
|
|\
| |
| | |
Convert template spec to object literal
|
| |
| |
| | |
This allows for metadata to be associated with the template and a simplification of the template init logic.
|
|/ |
|
|
|
|
| |
Allows helpers that care about where a particular field came from derive this data while maintaining backward compatibility with existing helpers.
|
|
|
| |
Fixes #658
|
| |
|
|
|
|
| |
setup options to use a hash helper.
|
|\
| |
| | |
It would be great to have the helper name passed to `blockHelperMissing`
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
All helper calls will have access to `options.name` which is the first id value of the mustache operation.
As part of this the helperMissing call has been simplified to remove the indexed name in order to optimize the call. This is a breaking change.
Fixes #634
|
|/ |
|
| |
|
| |
|
|
|
|
| |
Remove if conditional in favor of boolean failover.
|
|\
| |
| |
| |
| |
| |
| | |
blakeembrey-compiler-options
Conflicts:
lib/handlebars/compiler/javascript-compiler.js
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Handlebars now supports subexpressions.
{{foo (bar 3)}}
Subexpressions are always evaluated as helpers; if
`3` were omitted from the above example, `bar`
would be invoked as a param-less helper, even
though a top-levell `{{bar}}` would be considered
ambiguous.
The return value of a subexpression helper is
passed in as a parameter of a parent subexpression
helper, even in string params mode. Their type,
as listed in `options.types` or `options.hashTypes`
in string params mode, is "sexpr".
The main conceptual change in the Handlebars code
is that there is a new AST.SexprNode that manages
the params/hash passed into a mustache, as well
as the logic that governs whether that mustache
is a helper invocation, property lookup, etc.
MustacheNode, which used to manage this stuff,
still exists, but only manages things like
white-space stripping and whether the mustache
is escaped or not. So, a MustacheNode _has_
a SexprNode.
The introduction of subexpressions is fully
backwards compatible, but a few things needed
to change about the compiled output of a template
in order to support subexpressions. The main one
is that the options hash is no longer stashed in
a local `options` var before being passed to
either the helper being invoked or the
`helperMissing` fallback. Rather, the options
object is inlined in these cases. This does
mean compiled template sizes will be a little
bit larger, even those that don't make use of
subexpressions, but shouldn't have any noticeable
impact on performance when actually rendering
templates as only one of these inlined objects
will actually get evaluated.
|
|\
| |
| | |
Allow any number of trailing characters for valid JavaScript variable
|
| | |
|
| |
| |
| | |
Fixes #656
|
| |
| |
| |
| | |
Fixes #166
Fixes #587
|