Skip to content
This repository has been archived by the owner on Jun 10, 2018. It is now read-only.

Iterate over arrays #31

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Iterate over arrays #31

wants to merge 1 commit into from

Conversation

maccman
Copy link

@maccman maccman commented Sep 13, 2011

Not sure if you want this in core, but it lets you pass an array to eco(), instead of an object, rendering the template over each item in the array. This is the standard in other templating libs, like jQuery.tmpl.

@@ -8,6 +8,12 @@ exports.precompile = precompile = (source) ->
"""
function(__obj) {
if (!__obj) __obj = {};
if (Object.prototype.toString.call(__obj) == '[object Array]') {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we just check for __obj.length and __obj.join here instead?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Absolutely, that might be better. A bit crazy that typeof array is broken.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1

@josh
Copy link
Contributor

josh commented Sep 13, 2011

It seems nice, but I kind of like restricting the template context to an object. Not a strong opinion though.

@maccman
Copy link
Author

maccman commented Sep 21, 2011

@sstephenson worth me refactoring the array check? Is this something you'd like to see in core?

@josh - the template context will still be an object, the array index.

@ckihneman
Copy link

+1. I ended up writing myself a helper function to template an array at first (this is what i was used to from other libraries). Since then i've been been doing <% for item, i in @: %> because it gives me access to the iterator in the template (which is desired IMO). Would for sure want access to the iterator if the library decided to take this one on. I suppose this is more of a connivence and an necessity. Is the recommended behavior to do as i have been with <% for item, i in @: %>?

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

Successfully merging this pull request may close these issues.

5 participants