No error on non-existent partial

[pmendelski]

Why there is no information if I try to use a non-existent partial?
Example: https://jsfiddle.net/mendlik/7boebcan/1/

[jbboehr]

The mustache spec requires an unset partial to be rendered as an empty string: https://github.com/mustache/spec/blob/master/specs/partials.yml#L24

[pmendelski]

Ok, thanks.
I just think it is not very helpful during development.
Simple warning log would be a blessing.

[jbboehr]

Maybe it would make sense to throw an error for an unregistered partial when strict: true is passed, if it doesn't already?

[jbboehr]

@mendlik It looks like a regular partial is supposed to trigger an error if undefined: https://github.com/wycats/handlebars.js/blob/v4.0.5/spec/partials.js#L95-L100

[jbboehr]

@mendlik It looks like that's the expected behaviour of a partial block: http://handlebarsjs.com/partials.html

The normal behavior when attempting to render a partial that is not found is for the implementation to throw an error. If failover is desired instead, partials may be called using the block syntax.

{{#> myPartial }}
  Failover content
{{/myPartial}}

[pmendelski]

Thanks for your insight.
However I think it is a little bit misleading because the same paragraph says:

This block syntax may also be used to pass templates to the partial, which can be executed by the specially named partial, @partial-block.

Don't you think that having an optional partial is not as popular feature as using layouts?
Nevertheless thank you for your time.

[WestonThayer]

Agree with @mendlik, the docs shouldn't encourage you to use a partial block in the @partial-block sense if it's not going to throw an error, or at least a warning.

[olsonpm]

I'm pretty sure I just got hit by this.

The issue is that the syntax is the same for failover partials and layouts. That's just bad design because it leaves intent ambiguous from the compiler's perspective.

[nknapp]

Closing due to inactivity. If this is still important to you, please comment.