(v2) feat. Make raw json data available for Handlebars templates

[Britaliope]

Mailtrain v2

Context

Handle is a quite powerful language and allows things like iterate on lists or contitionnal structures.

However, it is not currently possible to do this in Mailtrain emails, because merge tags only contains parsed, string data that does not behave correctly in handlebars structures that expect json data, e.g. {{#if <VARIABLE>}}, {{#unless <VARIABLE>}}, {{#each <VARIABLE>}}.

This PR add, for relevents field types, a merge tag MERGE_EXAMPLE_NAME_RAW which contains the raw JSON Data.

Example

Assuming MERGE_IS_MODERATOR is an Option field, that does not belong to checkbox/dropdown/radio group (so it is rendered as a checkbox in the subscription page, and have a checked value and an unchecked value).

The following template will work as expected

Content of email, received by everyone


{{#if MERGE_IS_MODERATOR_RAW}}
Some specific information that only people marked as Moderators have to recived
{{/if}}

In the same way, it would expand the capabilities of radio buttons / checkboxes / JSON values field a lot, as would be possible to have complex templates that uses data present in these fields to generate a dynamic email.

---

What do you think of this feature ?

[bures]

I'm afraid, I don't understand. Why are the XXX_RAW tags needed for the {{#if MERGE_IS_MODERATOR}}?

[bures]

BTW, I'm wondering if we need the XXX_RAW. I guess, we can just change how some field types work in handlebars mode. Even though this would be a breaking change, I don't think it would have any significant impact. I would rather go with a clean solution than having XXX_RAW and then maybe another and yet another suffix.

[Britaliope]

Why are the XXX_RAW tags needed for the {{#if MERGE_IS_MODERATOR}}?

EDIT: I made a typo in the PR description, corrected to {{#if MERGE_IS_MODERATOR_RAW}}

The value rendered by the currently defined tag are casted to string. For the option field, it is either the field.settings.checkedLabel or field.settings.uncheckedLabel, which are both evaluate to true by handlebars, even if one is set to 'true' and the other to 'false'.

I guess, we can just change how some field types work in handlebars mode. Even though this would be a breaking change, I don't think it would have any significant impact.

I don't understand what you mean by changing how some fields type work. Could you detail this a bit ?

[Britaliope]

@bures Had you had time to review this solution ? I'll be happy to implement a better way to do this but this is the best i could implement.

I think the best would be to make fields behaves differently when used in a handlebars template, but i don't know how this would be possible. Do you have idea on how to implement this ?

[bures]

I see. Yes, now I understand. Well, I'm not very happy to include more tags because eventually there will be collisions - because XXX_RAW is a valid tag identifier. It would make more sense to me to treat the tags as structures (as opposed to strings) if handlebars style of tags is selected. As such MERGE_IS_MODERATOR would be in fact the MERGE_IS_MODERATOR_RAW.

We are in beta, so I'm not so much worried about introducing breaking changes if they give good, consistent and evolvable functionality.

[Britaliope]

@bures i'm working on changing the PR the way that you suggested.

I have a question concerning the forHbs method defined at server/models/fields.js:725. The name of the method and the doc comment " Returns an array that can be used for rendering by Handlebars " looks like this was made for a feature similar of what we needs here, however:

• This method uses the forHbs property of fieldTypes objects defined in server/models/fields.js:39-266 which returns in most of the cases the same string-parsed data used by merge tags.
• I don't understand which features are using this part of the code

could you clarify what's the purpose of these methods ?

[bures]

Sorry for my inactivity. Do you still want to continue in this PR? If you do, I'll try to be more responsive now. Thanks.