Which helpers do we want here?

[erikjung]

Currently, we have: https://github.com/cloudfour/core-hbs-helpers/tree/master/lib

├── average.js
├── displayName.js
├── fraction.js *
├── ifAnd.js
├── ifEqual.js
├── ifOr.js
├── random.js
├── randomIf.js
├── slug.js *
├── timestamp.js *
└── toFixed.js *

* renamed from original version

I'm not sure that all of these are useful enough to maintain here, so I welcome others to discuss and decide. Also, there is some room for improvement regarding consistency. For example, some helpers assume more than others about the arguments passed to them, some throw errors, etc. We should make them all appear to have been written by the same person.

[tylersticka]

Which projects were these pulled from? Because none of them are commented and I'm unsure of their original context, it's tough to say. I can't tell off-hand for example what the purpose of displayName versus slug is.

In my personal projects, I've become a bigger fan of using Assemble's compare helper to avoid needing a zillion separate if* helpers.

Is the goal to have a starting-point of only the helpers we use most often, or an exhaustive repository of every helper we might need?

[erikjung]

@tylersticka

Which projects were these pulled from? Because none of them are commented and I'm unsure of their original context, it's tough to say. I can't tell off-hand for example what the purpose of displayName versus slug is.

Projects scavenged from, with a lot of overlap:

• RFD: https://github.com/cloudfour/rfd-2015/blob/master/src/content/helpers.js
• Cloud Four redesign: https://github.com/cloudfour/cloudfour-redesign/tree/master/build/helpers
• WEC: https://github.com/cloudfour/wec-sandbox/blob/master/gulpfile.js#L42-L70
• VSE: https://github.com/cloudfour/vse-responsive-pilot/blob/master/source/patterns/templateHelpers.js

I also found displayName a bit odd. It seems to basically turn filenames like 01-some-page into Some Page. Most helpers were uncommented.

In my personal projects, I've become a bigger fan of using Assemble's compare helper to avoid needing a zillion separate if* helpers.

I agree that the ultra-granular if helpers are a bit silly. I haven't looked at Assemble yet. I would also propose the usage of Ramda for many of these kinds of helpers:

• http://ramdajs.com/0.18.0/docs/#cond
• http://ramdajs.com/0.18.0/docs/#and
• http://ramdajs.com/0.18.0/docs/#ifElse
• http://ramdajs.com/0.18.0/docs/#not
• http://ramdajs.com/0.18.0/docs/#or
• http://ramdajs.com/0.18.0/docs/#unless

Is the goal to have a starting-point of only the helpers we use most often, or an exhaustive repository of every helper we might need?

I think the latter. The goal is to not have to rewrite any of them (or copy and paste them) on a per-project basis. That said, there are some that I omitted. What I would like a consensus on in order to proceed:

• Did I miss any useful ones that should also be included here?
• Did I mistakingly include any that are too specific or useless?
• Do any of the names or APIs need to change because they're confusing or awkward?

If nobody has a strong opinion on this yet, that's fine too. I just wanted a gut-check since I took the liberty of hand-picking the helpers in order to get this repo up and running.

[tylersticka]

Did I miss any useful ones that should also be included here?

Will we have access to iterate (sometimes called times in our projects) via Fabricator? If not, I think we should include it here, because I use this very often.

It looks like @nicolemors added replace for RFD, that seems potentially useful?

As silly as it sounds, I find count useful (unless there's a better way of outputting the length of a collection).

Did I mistakingly include any that are too specific or useless?

I already mentioned my misgivings about the conditional helpers, but I'm open to differences of opinion there. I wonder if something like ifAnd or ifOr could compare two or more arguments? These are thoughts.

Do any of the names or APIs need to change because they're confusing or awkward?

displayName needs a better name. Based on the context you provided I could see how it might be useful in the context of our Fabricator instance, but... yeah, I'm not sure. It's almost the inverse of slug, right?

Similarly, I wonder if the fraction helper should be toFraction or something similar to mimic toFixed?

Also cc'ing @saralohr in case she has opinions.

[erikjung]

@tylersticka

Will we have access to iterate (sometimes called times in our projects) via Fabricator? If not, I think we should include it here, because I use this very often.

I do think it exists with Fabricator, but we probably shouldn't rely on that. I'll add it back.

As silly as it sounds, I find count useful (unless there's a better way of outputting the length of a collection).

Unless I'm misunderstanding:

{{collection.length}}

I already mentioned my misgivings about the conditional helpers, but I'm open to differences of opinion there. I wonder if something like ifAnd or ifOr could compare two or more arguments? These are thoughts.

I'll look into consolidating these into a single helper.

displayName needs a better name. Based on the context you provided I could see how it might be useful in the context of our Fabricator instance, but... yeah, I'm not sure. It's almost the inverse of slug, right? Similarly, I wonder if the fraction helper should be toFraction or something similar to mimic toFixed?

I see an opportunity for naming conventions here. Maybe anything that translates a value should be named this way? toSlug, toTitle, toFraction, toFixed, etc.

[tylersticka]

I didn't know collection.length worked! That's awesome.

I'll look into consolidating these into a single helper.

Unless others find that more confusing. I just like not having to look up the syntax for four or five separate helpers, y'know?

I see an opportunity for naming conventions here. Maybe anything that translates a value should be named this way? toSlug, toTitle, toFraction, toFixed, etc.

Good idea!

I was about to suggest adding another helper from one of my personal projects, but I think it'd be better for me to just contribute it as a PR. :smiley:

[tylersticka]

@erikjung I'm also happy to help commenting these or improving the way they are documented if you want to adopt a format I can mimic. (That very well could be a separate issue, just throwing it out there! Can you tell I kinda like Handlebars helpers?)

[erikjung]

@tylersticka How about this JavaDoc-ish format: https://github.com/ramda/ramda/blob/v0.18.0/src/add.js

Specifically, the following annotations:

/**
 * This is a helper that helps something.
 *
 * @since v0.1.0
 * @param {String} str
 * @return {String}
 * @see (if applicable)
 * @example
 *
 *   {{toSlug "Some String"}} //=> "some-string"
 */

[tylersticka]

@erikjung Works for me! Let me know when/if you want any help.

[erikjung]

@tylersticka I will make an issue for it.

[erikjung]

I think this thread served its purpose for now. Anyone, feel free to reopen for further discussion.