Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Riot should support less intrusive virtual tags #1735

Closed
5 tasks
kokujin opened this issue Apr 12, 2016 · 7 comments
Closed
5 tasks

Riot should support less intrusive virtual tags #1735

kokujin opened this issue Apr 12, 2016 · 7 comments

Comments

@kokujin
Copy link

kokujin commented Apr 12, 2016

Riots tags virtual tags sometimes are unnecessary and may "pollute" DOM. It would be nice if it was something like Knockouts(http://knockoutjs.com/documentation/custom-bindings-for-virtual-elements.html)

<!-- ko foreach: items -->
        <li data-bind="text: $data"></li>
    <!-- /ko -->
  • Question
  • Bug
  • Discussion
  • [x ] Feature request
  • Tip
  • [x ] Enhancement
  • Performance
@rsbondi
Copy link
Contributor

rsbondi commented Apr 12, 2016

your ko example renders to the dom

<!-- ko foreach: items -->
        <li data-bind="text: $data">item 1</li>
        <li data-bind="text: $data">item 2</li>
<!-- /ko -->

it renders the comments as well as the expression on each list item

the riot equivelant would be

<li each={item in items}>{item}</li>

renders

<li>item 1</li>
<li>item 2</li>

with virtual

<virtual each={item in items}>
  <h1>{item.h}</h1>
  <p>{item.p}</p>
</virtual>

renders

<h1>header 1</h1>
<p>value 1</p>
<h1>header 2</h1>
<p>value 2</p>

no virtual element(comments rendered in ko) and no expressions on each element so polluting the dom is not an issue, however the knockout style advantage does allow virtual anywhere since comments can go anywhere, so I can see an improvement where you might want use in a table or select/options but I can't think of an good example.

@GianlucaGuarini
Copy link
Member

Honestly I don't see any improvement here, it's just a matter of style. Riot uses DOM nodes easier to remember and type, self contained, familiar for any HTML developer and IDE friendly. Knockout on the other hand uses DOM comments that in my opinion are less semantic and more confusing: we reuse html (enhancing it a bit) as presentation layer, html comments were made for another purpose and make sense only if you want to comment what you are actually coding and not what you are trying to achieve with your layout.

@kokujin
Copy link
Author

kokujin commented Apr 12, 2016

Maybe I'm mistaken. But I noticed that nested custom tags leave an encompassing virtual tag. So using the example above

<virtual each={item in items}>
  <h1>{item.h}</h1>
  <my-test>
      <p>{item.p}</p>
    </my-test>
</virtual>

Would render, this

<virtual each={item in items}>
    <h1>header 1</h1>

    </my-test>
        <p>value 1</p>
    </my-test>
    <h1>header 2</h1>

    <my-test>
    <p>value 2</p>
    </my-test>
</virtual>

I understand the advantages of riots virtual tags, the thing is, I would like them not to show up in the markup

@GianlucaGuarini
Copy link
Member

All virtual tags must be removed. The current riot implementation removes them only in the loops. In future we will remove also in the conditional statements

@rsbondi
Copy link
Contributor

rsbondi commented Apr 12, 2016

no virtual in dom,

I would like them not to show up in the markup

Not sure I follow?

@wintercounter
Copy link

Tried your plunker with this. As stated, it is only removed when using with each. Agree that it should be removed always under any circumstances.

<virtual if={ true }>
    My content
</virtual>

@GianlucaGuarini
Copy link
Member

The current virtual implementation allows if statement and loops and that's enough for riot@3 the future riot release will allow users to render their tag with pure js template strings so I am closing this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants