Suggestion to improve the view parser

The way you parse the views currently is quite buggy, it can fail if comments or parens are present in strings.

A better strategy would be to use a single regex that matches strings, comments and the /l\s*(/, and ignore the strings/comment matches.

Something like this would do:

L_MATCHER = /((?:^|[^\w\d$])l\s*\()|"(?:\\.|[^"\n])*"|'(?:\\.|[^'\n])*'|\/\*[\s\S]*?\*\/|\/\/.*?\n/g

function findL(str, i) {
  var match;
  L_MATCHER.lastIndex = i;
  while (match = L_MATCHER.exec(str)) if(match[1] != null) {
    return match.index + match[1].length;
  }
}

You could also use a similar strategy to match parentheses.

PAREN_MATCHER = /[()]|"(?:\\.|[^"\n])*"|'(?:\\.|[^'\n])*'|\/\*[\s\S]*?\*\/|\/\/.*?\n/g then ignore cases where match[0] is not a parenthesis.

[lhorie]

I’m not sure this approach is worth pursuing further at all. The function call regex/replace will break non-local variable references. Here’s a simple test case:

const { r, l: x, mount, component } = radi;
 
const counter = component({
  view: function() {
    return (
      r('button', {onclick: this.up}, 'Click me ', x(this.counter))
    )
  },
  state: {
    counter: 0
  },
  actions: {
    up() {
      this.counter += 1;
    },
  }
});
 
mount(new counter(), document.body);

So if l is renamed (which may happen, for example, if a bundler or a minifier renames it), things break.

Using any library in a view function will also break:

const { r, l, mount, component } = radi;

function format(date) {return date.toString();}
 
const counter = component({
  view: function() {
    return (
      r('div', format(new Date))
    )
  },
  state: {
    counter: 0
  },
  actions: {
    up() {
      this.counter += 1;
    },
  }
});
 
mount(new counter(), document.body);

My recommendation would be to do the replacements with a custom babel transformation instead of doing it at runtime. Doing it at the JSX level might allow you to drop the l() call altogether if an assumption is made that an interpolation is reactive, but it could just be a macro on l() as well.

[Marcisbee]

With merging refactor into master, this is no longer relevant