Support Map for iteration and nested paths

[karlvr]

Re #1418 and #1557 this PR adds support for accessing properties in Maps, and iterating over the values in Maps using #each.

e.g.

var foo = new Map();
foo.set('expression', 'beautiful');
...

+

Goodbye {{foo/expression}} world!
{{#each foo}}
The {{@key}} is {{.}}.
{{/each}}

=

Goodbye beautiful world!
The expression is beautiful.

• Please don't start pull requests for security issues. Instead, file a report at https://www.npmjs.com/advisories/report?package=handlebars
• Maintain the existing code style
• Are focused on a single change (i.e. avoid large refactoring or style adjustments in untouched code if not the primary goal of the pull request)
• Have good commit messages
• Have tests
• Have the typings (lib/handlebars.d.ts) updated on every API change. If you need help, updating those, please mention that in the PR description.
• Don't significantly decrease the current code coverage (see coverage/lcov-report/index.html)
• Currently, the 4.x-branch contains the latest version. Please target that branch in the PR.

[karlvr]

I was trying to fix the change in code formatting around the blockParams, but it looks like there's some automatic reformatting on commit? Something's doing something :-D

[karlvr]

I'm sorry I didn't notice the failing tests outside of the node environment before. I am trying to work out what's going wrong now... I think perhaps it's a product of webpack babel.

[karlvr]

That's the ticket. I'm keen to discuss; Handlebars is central to my project and I'm trying to make the decision between Map and POJOs.

[nknapp]

Thanks for submitting this PR. I haven't been able to answer earlier, but I think your PR makes sense. There are just one point that I would like to discuss and one change request. I haven't had a very close look at the code yet though.

Is this a breaking change?

I am not sure if this change should go into the 4.x-branch. In #1557, you said that Maps could be iterated at the moment, they would be iterate like an array of key-value pairs, rather than like an object (values with @key containing the key).

I would like to hear some opinions (@wycats, @ErisDS, @aorinevo) if this should be considered a breaking change. If we interprete semver strictly, it is not breaking, because iterating Maps is not documented anywhere.

But one could also argue that some people might already use {{#each}} to iterate maps and expect key-value pairs in the iteration. Support for iterable objects was added only a couple of months ago in 4.4.0, so there is only a limited changes that this is the case

Tests

There is a new way of writing tests (see #1683 for details). You IDE probably didn't show the shouldCompileTo-function as deprecated, but the new way is to use expectTemplate(...).toCompileTo(...) instead. It makes the test-code much more readable.

I am also not sure if we will get any merge conflicts with #1683, so I think it would be best to wait until that one is merged, and then rebase.

[karlvr]

@nknapp thanks for your message. No, I didn't see that! I've converted those tests. I'm also happy to rebase and make any adjustments when #1683 lands.

[nickshreck]

Did this ever get merged? It seems the perfect solution to handling Maps in Handlebars. I haven't found a cleaner way yet.

[jaylinski]

Memo: in order to play it safe, this will be only merged in master (v5).

@karlvr I know it's been 3 years, but if this PR is still relevant for you, please target in on master. (Otherwise I'll do it myself, because I think this is a really nice feature.)

[karlvr]

@jaylinski no problem! I've left things much longer than that. I actually didn't end up using this. I had a quick look and it looks like it might benefit from a little insight to rebase it (particularly each.js). If you're happy to that would be fantastic.

[wind4gis]

did handlebars support map now?

[jaylinski]

@karlvr I opened an updated PR in #1996. Thanks for your PR, it helped a lot!