Product Wish List

To share product feedback, please fill out the form below with as much detail as possible! We aim to include as many suggestions in our roadmap, but we prioritize features aligned with our goals and most customers' needs.
Support nested merge tag rules
When using repeat rules, I can provide nested merge tags which are only valid inside a block where that rule is selected. The docs use the following example: unlayer.init({ mergeTags: { products: { name: "Products", rules: { repeat: { name: "Repeat for Each Product", before: "{{#products}}", after: "{{/products}}", } }, mergeTags: { name: { name: "Product Name", value: "{{name}}" }, image: { name: "Product Image", value: "{{image}}" } } } } }); Now suppose I have multiple images per product instead of a single one. It would be natural to model this as a nested repeat rule inside the one for products, like so: unlayer.init({ mergeTags: { products: { name: "Products", rules: { repeat: { name: "Repeat for Each Product", before: "{{#products}}", after: "{{/products}}", } }, mergeTags: { name: { name: "Product Name", value: "{{name}}" }, images: { repeat: { name: "Repeat for Each Product Image", before: "{{#images}}", after: "{{/images}}", }, mergeTags: { url: { name: "Image URL", value: "{{url}}" } } } } } } }); I would then expect that I can use the "products" repeat rule for a row, and the "images" repeat rule for some content (e.g. an image) inside that row. Moreover, the "images" rule should be available ONLY inside the products block, not as a top-level rule on a row, just like the merge tag for the product name is also only available inside the products block. Right now, a nested rule is NEVER shown, neither for a top-level row (as it shouldn't be) nor inside the corresponding parent rule (where it actually should be shown). One workaround for that is to move the product images rule out from the products and make it a top-level rule, even though in the data "images" would still be an array inside a product: unlayer.init({ mergeTags: { products: { name: "Products", rules: { repeat: { name: "Repeat for Each Product", before: "{{#products}}", after: "{{/products}}", } }, mergeTags: { name: { name: "Product Name", value: "{{name}}" } } }, images: { repeat: { name: "Repeat for Each Product Image", before: "{{#images}}", after: "{{/images}}", }, mergeTags: { url: { name: "Image URL", value: "{{url}}" } } } } }); This way, Unlayer always allows the "images" rule to be selected, not only inside a product, but also for other blocks where product images are actually not available, which isn't ideal of course. If everything is configured correctly, this will work. If the template uses "images" outside of "products", it won't work because there are no "images" defined in the data on that level. Ideally, the user should know where a nested rule can be used in a template, just as it is already implemented for merge tags that can be only used inside a rule. Note that the workaround shows that once you have a template with nested repeat rules, template engines already support them correctly. The problem is just that it is currently hard to design such templates with Unlayer. This is one reason why I really think Unlayer should support this. To fully support this idea of nested rules, the API for providing a custom UI for merge tag rules via registerCallback('mergeTagRule', ...) must be adapted as well. Currently, the callback only receives the current merge tag group of the current block. But in order to correctly decide whether a nested rule (product images in the example above) is available for a block or not, the callback must also know the merge group tag of the outer block. Sticking to the example, if the outer block has the "products" repeat rule, the custom UI would allow to select the "images" repeat rule, otherwise images would not be available. I'll leave it up to you to design the API for this. There could be something like a "parentMergeTagGroup" that is passed along with the current group. A more general alternative would be to provide a path of groups from the root to this block as an array of groups. In practice, only one level of nesting is possible at the moment.
Load More