Mustache lambdas emiting any object including components (extended #951)

[psrok1]

Your checklist for this pull request

• [x] I've read the contributing guideline.
• [x] I've tested my changes by building and running the project, and testing changed functionality (if applicable)
• [ ] I've added automated tests for my change (if applicable, optional)
• [ ] I've updated documentation to reflect my change (if applicable)

Extended and fixed version of #951

Plugin code used for tests

export default () => ({
    mustacheExtensions: [
        {
            "makeButton": (text, renderer) => <button>{renderer(text)}</button>,
            "capitalize": (text, renderer) => { let renderedValue = renderer(text); return renderedValue.charAt(0).toUpperCase() + renderedValue.slice(1); },
        }
    ]
})

[yankovs]

Hey! looks good, i'll try to play with it soon. One of my "inspirations" for this kind of code was from kibana (elastic). They extended mustache with helper functions such as: {{#join}} for joining strings with a , delimeter and other useful stuff. It's talked about in this issue

How does the current state of this handle an input of an array? For example doing {{#join}}{{names}}{{/join}} where names is an array of strings and join is something like (text, renderer) => renderer(text).join(', ')

[psrok1]

The main problem is that Mustache.js generates strings so {{names}} will be stringified by renderer(text) and then passed to the {{#join}} function, so stringified names must be then parsed back to the array and then joined.

I see much better idea in Mustache.js pull-requests: Pipeline operator and that's something we can easily implement ourselves by extending lookup function in MustacheContext. It would be also nice to keep a common interface, so string processing functions can use both section and pipeline syntax.

[yankovs]

Got to play with it. I really like the direction of this, I've been able to in around 30 minutes create extensions that create nice stuff like tables with pagination from attribute data. This makes the "attributes" section of the page really powerful.

I've noticed that extensions that return jsx aren't composable: In this case, when tableFromList runs the renderer on the text then it receives the markdown references. I think this is a fair behavior and something people can live with.

I see that in cases where the user defined field is the same as an existing lambda, the lambda lookup gets higher precedence: I think that in such a case, it is better to make the user defined value get a higher precedence and be returned. What do you think?

Overall, this looks like a good direction, and thank you for taking the time to look into it :)

[psrok1]

Superseded by #1021