Unable to use non standard angular start/stop symbols about angular-formly-templates-bootstrap

[kentcdodds]

One thing that we could do is do a replace on the template strings if the symbols are none-standard. This should be relatively trivial and might be a good first timer issue to...

[davidlukerice]

Good idea. I'm assuming that would be a change in angular-formly and not in the template repos?

[kentcdodds]

Actually, no, this would happen in this repo. Anywhere we require a
template, we'd do a replace.

On Wed, Sep 30, 2015, 2:27 PM David Rice [email protected] wrote:

Good idea. I'm assuming that would be a change in angular-formly
https://github.com/formly-js/angular-formly and not in the template
repos?

—
Reply to this email directly or view it on GitHub
#60 (comment)
.

• Kent C. Dodds https://twitter.com/kentcdodds

[davidlukerice]

Seems a bit redundant to have to do it each time a template gets required. I'm currently just using

.run([ '$interpolate', 'formlyConfig', function($interpolate, formlyConfig) {
        formlyConfig.templateManipulators.postWrapper.push(function(template, options, scope) {
            return template.replace(/{{/g, $interpolate.startSymbol())
                           .replace(/}}/g, $interpolate.endSymbol());
        });
    }])

when I initialize my own app to get around the issue, so was assuming I could do something similar in angular-formly. Unless there's some performance hit that I'm not seeing.

[kentcdodds]

That's not what I mean. What I mean is, anywhere we do this:

template: require('./label.html'),

We change it to:

template: fixInterpolationSymbols(require('./label.html'), $interpolate),

where fixInterpolationSymbols is something like this:

function fixInterpolationSymbols(templateString, $interpolate) {
  var start = $interpolate.startSymbol();
  var end =  $interpolate.endSymbol();
  if (start !== '{{') {
    templateString = templateString.replace(/{{/g, start);
  }
  if (end !== '}}') {
    templateString = templateString.replace(/}}/g, end);
  }
  return templateString;
}

[kentcdodds]

We'd put that function in a regular ES6 module and import it where we need it (hence it needs to accept the $interpolate as an additional argument).

[davidlukerice]

The import method still requires a code change every place a template is required, right (so 5 places in angular-formly-templates-bootstrap)? The module would also need to be duplicated across each angular-formly-templates-* repo and its template requires changed. This leaves quite a bit of room for bugs to slip in if a dev forgets to apply the fix method on a template import or if the method is updated in one template repo and not another. I understand the desire to leave templating concerns in the template extensions, but that much duplication makes me think the fix is at the wrong abstraction layer.

This is opposed to just having the single postWrapper push in say angular-formly/src/run/updateInterpolateSymbols.js.

export default updateInterpolateSymbols;

// @ngInject
function updateInterpolateSymbols(formlyConfig, $interpolate) {
  formlyConfig.templateManipulators.postWrapper.push(updateSymbols);

  function updateSymbols(template, options, scope) {
    var start = $interpolate.startSymbol();
    var end =  $interpolate.endSymbol();
    if (start !== '{{') {
      templateString = templateString.replace(/{{/g, start);
    }
    if (end !== '}}') {
      templateString = templateString.replace(/}}/g, end);
    }
    return templateString;
  }
}

The postWrapper seems designed for this sort of thing and looks like replacements would be more efficient, being called only once per form instead of once per template require.

[kentcdodds]

That makes sense. One issue I can see is that this will run for every field for every compile. While it's nice that you ensure you cover all the bases, it's sub-optimal from a perf standpoint. But that may be negligible.

That said, I don't want to put that in angular-formly core. A very small percentage of formly users will need it. But a plugin for that would be fantastic. Would you be interested in creating a plugin for that? See here for more info.

[davidlukerice]

Oh, yah, that linking call is on the field and not the whole form. Makes sense to not want it in core. I can definitely throw it in a plugin.

[davidlukerice]

Would you prefer the angular-formly-dynamic-interpolate-symbols plugin to reside in the formly-js org?

[kentcdodds]

I'll let you decide. I'll happily create the repo and add you as a collaborator if you like :-)

[davidlukerice]

Sure, that works for me. I'm assuming I can just mimic the structure of an existing plugin?

[kentcdodds]

Here's the repo: https://github.com/formly-js/angular-formly-dynamic-interpolate-symbols, you've been invited to collaborate on it.

You can feel free to do whatever you like with regards to the plugin. I don't recommend you go with the kcd-common-tools approach like some of the other plugins. It's a bit complex and not fully baked.

Feel free to do it however you like. Personally, I recommend you checkout my How to Write an Open Source JavaScript Library series on egghead, and then combine that knowledge with Webpack (egghead.io playlist).

Sorry that the original series isn't quite to webpack yet. Though you should be able to get away with doing this in a single file... If you want to DM me on twitter, I can give you access to a private video which could help you out as well..

[kentcdodds]

Oh, my twitter is: https://twitter.com/kentcdodds

[davidlukerice]

Alright, this feature is now in https://github.com/formly-js/angular-formly-dynamic-interpolate-symbols.

[kentcdodds]

This is terrific! I'll add it to the plugins page. Could you make an example for the website?

[kentcdodds]

Added

[davidlukerice]

Alright. Put in a PR to add an example to the advanced tab.
formly-js/angular-formly-website#81