Parsers in browser

[GianlucaGuarini]

Is it possible with the new compiler to parse the riot tags in runtime directly in the browser?
In this file I see many require calls that are only available in a node environment

[a-moses]

👍

[aMarCruz]

@GianlucaGuarini , yes, it is already fixed my local copy, but now having problems with compiler logic.
Please tell if I'm wrong...
The file test/tag/named-child.tag (one of various errors) is:

<named-child-parent>
  <named-child name="tags-child"></named-child>
</named-child-parent>
<named-child>I have a name</named-child>

now, the compiler is generating:

riot.tag2('named-child-parent', '<named-child name="tags-child"></named-child>', '', '', function(opts) {
});
riot.tag2('named-child', '', '', '', function(opts) {
  I have a name    // <================ Parse error here when executing riot.tag2
});

I think this is the intention:

<named-child-parent>
  <named-child name="tags-child"></named-child>
</named-child-parent>
<named-child><p>I have a name</p></named-child>

The compiler is generating, I think correctly:

riot.tag2('named-child-parent', '<named-child name="tags-child"></named-child>', '', '', function(opts) {
});
riot.tag2('named-child', '<p>I have a name</p>', '', '', function(opts) {
});

In the first form, named-child is a custom tag with no html content inside, only bad javascript. I'm wrong? If so, how to detect the difference. I'm reading the old code right now to understand this.

EDIT: This is from specs/node.js test

[GianlucaGuarini]

@aMarCruz you can indent that tag, I have already updated the analyzer to detect this kind of issue https://github.com/riot/cli/blob/master/test/tags/analyzer/one-line.tag

[aMarCruz]

You mean indenting <named-child>? i.e. the rule of 0 indentation for custom tags? the compiler is recognizing indented tags now, but is ok back to 0, it is simpler.

btw: call to riot.tag2 by the compiler was done mainly for precompiled expressions, this is transparent to users and sets brackets automatically, but may complicate the tests. I must mantain this, or back to riot.tag? Isee riot.tag2 in your tests, maybe is late to quest.
Now I think the way for precompiled expressions is a postprocessor, separated from riot, to not complicate the current code.

[GianlucaGuarini]

You mean indenting <named-child>?

yes

btw: call to riot.tag2 by the compiler was done mainly for precompiled expressions, this is transparent to users and sets brackets automatically, but may complicate the tests. I must mantain this, or back to riot.tag? Isee riot.tag2 in your tests, maybe is late to quest.

No it's never too late ;) just try to freeze the compiler api in order to make a new riot release
I think the compiler should mainly output riot compliant code, and riot-cli just prints the output in a file. Honestly I didn't really get why you needed riot.tag2 but if it's needed for the new compiler that's ok for me

[aMarCruz]

riot.tag2 was for differentiate compiler code from users code, in precompiled expressions. It is not necessary now, except for auto-setting brackets, but it can do on riot.tag, or remove the feature, your decision.
Working in adjust the indent 0 regretion.

[GianlucaGuarini]

You can either keep riot.tag2 but we need to update the doc, or remove it handling it in runtime. I am fine with both solutions

[aMarCruz]

Well, keep riot2 please, the distinction can be useful in the future.
The working on the fixes for browser is at ~80%, I'm out of home this weekend, upon returning I will finish the code, and begin the docs.

[GianlucaGuarini]

@aMarCruz thank you I will try to fix the ie issue in our unit test