The below fiddle recreates the issue. Checking an item should remove it. However, checking any but the last item with riot 2.2.2, while the item is removed, the item below becomes checked. It works fine with 2.1.0 and 2.0.15.

http://jsfiddle.net/cdanielw/bkw5ommu/4/

I was very interested in seeing how fast Riot was compared to React based on the intro docs.

So I put together these simple demos to help me learn and compare.

10k item list with reverse button. After you click the button, you'll see the time it took to reverse and finish rendering. (Actually, in a separate issue, I don't understand why you have to click the button twice on the Riot version before the timing text appears.)

React: http://jsfiddle.net/brianmfranklin/w674Lv7p/ Riot2: http://jsfiddle.net/brianmfranklin/j05ukz2r/

On my MacBook Pro, I consistently get about 2500 ms for Riot, and only 250-350ms for React.

I thought maybe this was a quirk of how I was having to measure the timing. But it DOES seem to actually take longer to do the re-render.

Is this expected? Or are there more optimizations to do?

Roadmap proposal for the future riot major release:

(this list just a draft and it's going to grow)

• [ ] Complete rewrite of the compiler simplifying the sourcecode allowing also sourcemaps
• [ ] Fix all the yield issues introducing the use of <slot> deprecating the <yield>
• [ ] Make the use of riot-observable optional
• [ ] Remove this.tags from the tags instances in favor of ref https://github.com/riot/riot/issues/2360
• [ ] Automounted components deprecating the riot.mount method
• [ ] Add support for shadow DOM or at least support the :root selector instead of :scope
• [ ] Make the tags options explicit avoiding to pick per default all the custom tags attributes
• [ ] Avoid the use of riot.csp in favor of a simpler solution
• [ ] Cleanup the readme file removing dead links to tutorials or old riot stuff
• [ ] Simplify the mixin logic avoid the use of es6 classes and functions instances
• [ ] Remove the shouldUpdate method in favor of a smarter DOM updates strategy
• [ ] Drop IE9/10/11 support
• [ ] Use new ES6 features like Proxies and template strings
• [ ] Drop the use of each={ items } in favor of each={ item in items }
• [ ] Reduce the source code simplifying a lot the api
• [ ] Update the api simplifying the core methods arguments handling
• [ ] Prefer a functional approach over the current objects extension strategy

We will track the progress here

✌️

Riot 2.2.3

The next riot release the 2.2.3 (maybe we could split it also in 2 releases 2.2.4) will fix the mainly the issues raised up by our users

• Bugs
  • [x] #1055
  • [x] #1048
  • [x] #1040 #974 #995
  • [x] #1016 #984
  • [x] #976
  • [x] #907
  • [x] #1071

Riot 2.2.4

bugs list

Riot 2.3.0

I would like also to discuss here the updates I've planned for riot 2.3.*

• [x] rethink/refactore the riot loops to keep them fast but also updating the DOM node correctly
• [x] remove the compiler, router, observable (maybe also the cli).. from the riot repo. We could publish all these scripts as separate npm modules riot-* and use them to build riot in this repo (or even extend the basic riot functionalities like the router 4 ex.). This solution allows us to split and test all the riot core modules in their own repos avoiding to pollute this repo with too many unrelated tests. Indeed we could also track better the issues related to small parts of our code base. I have already prepared riot-observable containing the folder structure I would like to use also for the other riot modules. Notice that the doc folder could be used to update the whole riot documentation/website here avoiding to rely on @tipiirai on any new riot release. The submodules versioning should be in sync with riot at least for the major releases
  • [x] riot-observable assigned to @gianlucaguarini
  • [x] riot-compiler assigned to @aMarCruz
  • [x] riot-router assigned to @cognitom
  • [x] riot-cli assigned to @gianlucaguarini
  • [x] riot-tmpl assigned to @aMarCruz
• [x] remove the ie8 support as one of the main riot pros from the doc, I would like explain the hacks about how to use eventually riot on IE8 only in our FAQ section
• [ ] remove the dist folder from the .gitignore to easily debug the release in the dev branch
• [x] decide whether we want to optimize our build using webpack or keep using smash
  • with smash we could only include the index.js files of all our riot submodules
    • Pros: It will keep the riot codebase small
    • Pros/Cons: Our source files will not be processed by any other tool, they will be only concatenated in riot.js
    • Cons: Use of a deprecated technology
    • Cons: We will lose control over the global variables, functions risking global namespace conflicts
  • with webpack
    • Pros: We can get only the methods exported from our riot submodules keeping, the riot context clean
    • Pros/Cons: We could parse our modules, using babeljs using also es2015 features
    • Cons: Our output will not match the codestyle used in the sourcecode
    • Cons: Our output will be bigger containing extra code generated by webpack to handle the commonjs calls
• [x] merge the new tmpl.js https://github.com/riot/riot/pull/954 version (maybe it could also be a riot submodule riot-tmpl?! )
• [x] update the riot website automatically on any new riot release enhancing the code [here].(https://github.com/riot/riot.github.io) Do we need to redesign it? Or do you want to keep the current template?
• [x] enhance the riot-router using the HTML5 history API

Your feedback is really appreciated @tipiirai @cognitom @rsbondi @aMarCruz

:v:

It would be great to specify where to include the content of a parent tag. Ie:

<!-- form-group.tag -->
<form-group>
  <div class="form-group">
    <label>{ opts.label }</label>
    { innerHTML } <!-- somehow transclude given content here (there is probably a better name than "innerHTML" ;) -->
  </div>
</form-group>

<!-- index.html -->
<form>
  <form-group label="Field 1">
    <input type="text" name="field-1"/>
  </form-group>
</form>

.... producing ....

<div class="form-group">
  <label>Field 1</label>
  <input type="text" name="field 1"/>
</div>

3.0.0 will be quite a big release for riot. @rsbondi and the new member of the team @rogueg are already working on the next branch fixing many of the important issues that we can solve only by introducing breaking changes. Here you can check the list of the issues we want to close for the next major release:

• [x] improve the loop performances using the @pakastin's hint http://jsfiddle.net/paldepind/rju8rzmn/4/
• [ ] ~~switch from makefile to a more crossplatform solution #2024~~
• [ ] add sourcemaps generation in the compiler compiler/56
• [x] use the ref attribute instead of names and ids riot/1185
• [x] allow the es6 import also inside the tags compiler/69
• [x] build riot using rollup+babel instead of smash using the new es6 modules syntax
• [x] remove riot-route from the core making it optional https://github.com/riot/riot/issues/1485
• [x] fix all the issues related to the if conditions https://github.com/riot/riot/issues/1477 https://github.com/riot/riot/pull/1658
• [x] avoid that the update and the updated events get triggered before any tag has been mounted https://github.com/riot/riot/issues/1661
• [x] decision regarding how the input/select tags should react on the updates https://github.com/riot/riot/issues/1642
• [x] remove the automatic preventDefault from the riot DOM events https://github.com/riot/riot/issues/1770 https://github.com/riot/riot/issues/1718 https://github.com/riot/riot/issues/526
• [x] avoid to inherit properties from the parent in loops of custom children tags https://github.com/riot/riot/issues/1697
• [x] avoid to update the parent tag on the events generated from a child tags https://github.com/riot/riot/issues/1319
• [x] remove the __ prefix for the "boolean" html attributes https://github.com/riot/riot/issues/276
• [x] clean up the tests splitting them into several files
• [x] Add the shouldUpdate method to the tags to emulate componentShouldUpdate in react

I also hope to have enough time to add a blog section on our site describing the riot status on any release.

I would like also to mention that we started a pledgie donation campaign and if you would like to sustain us and you like riot it might be nice to consider a donation at least to let us paying the costs of the riot maintenance (domain, saucelabs, browserstack.. )

:v:

Bugs:

• [x] https://github.com/muut/riotjs/issues/766
• [x] https://github.com/muut/riotjs/issues/764
• [ ] ~~https://github.com/riot/riot/issues/810~~ in the next release
• [ ] ~~https://github.com/riot/riot/issues/334~~ in the next release
• [x] https://github.com/riot/riot/issues/809
• [x] https://github.com/muut/riotjs/issues/700
• [x] https://github.com/muut/riotjs/issues/484 ( probably the most important )
• [x] https://github.com/muut/riotjs/issues/763

Features/Enhancements

• [x] faster each rendering ( related to #484 )
• [x] fix the saucelabs tests on the iPhone/iPad (I have removed them)
• [x] increase the code coverage
• [x] enable use strict

p.s. This list could change at anytime, new ideas and suggestions are welcome Your contribute to riot is precious :v:

I think looping through element is at the wrong tag level. Specially when you have this case you need to write twice the each to get it work as expected.

<dl class="dl-horizontal" >
    <dt each={name in opts.data.metrics}>{name}</dt>
    <dd each={name, value in opts.data.metrics}>{value}</dd>
</dl>

It iterates the same list twice right?

Shouldn't that be like this? And more efficient.

<dl class="dl-horizontal" each={name, value in opts.data.metrics}>
    <dt>{name}</dt>
    <dd>{value}</dd>
</dl>

It feels more natural too. If you base on templating engines such as Jinja http://jinja.pocoo.org/docs/dev/templates/#for

Recap

It's almost one year that we didn't release updates about Riot v4 so I think opening a new roadmap issue (closing the old one https://github.com/riot/riot/issues/2283) is the cleanest way to keep our community updated regarding the upcoming news.

Riot v3

Riot v3 is feature complete and bug free so we will update the source code just in case of security vulnerabilities. All the enhancements and the yield problems submitted by some users will introduce breaking changes so I would like to keep the current API/behavior stable as it is and move forward.

Core Contributors

Please see here

Riot v4

Riot and Simulacra.js will join forces

Riot 4 will use Simulacra.js as default rendering engine. Simulacra.js is currently one of the fastest and smartest rendering engine available and its creator @daliwali is now a riot core member. Dali will actively be part of the riot 4 rewrite and we started already working on a new parser/compiler.

Components Structure

The riot components structure will be a bit refreshed but it will not be a radical change. We will avoid the current ambiguities in favor of a cleaner and nicer structure.

Old

<my-component>
  <h1 if={ title }>{ title }</h1>
  <ul>
    <li onclick={ onClick } each={ items }>{ value }</li>
  </ul>

  var goodbye = 'goodbye'

  this.on('mount', function() {
    console.log('mounted!')
  })

  onClick() {
    this.title = goodbye
  }

  <style>
    :scope {
      color: red;
    }
  </style>
</my-component>

New

<my-component>
  <h1 if={ title }>{ title }</h1>
  
  <ul>
    <li onclick={ onClick } each={ item in items }>{ item.value }</li>
  </ul>

  <script>
    var goodbye = 'goodbye'

    export default {
      onMount() {
        console.log('mounted!')
      },
      onClick() {
        this.title = goodbye
      }
    }
  </script>

  <style>
    :root {
      color: red;
    }
  </style>
</my-component>

New Ideas

We got many new ideas for the rewrite but we need to test them first so you will be informed when the compiler will be in a functional prototype state.

Release date

At moment we don't have any fixed release date, we only know that a full rewrite of the framework in 2 of us (working only during our spare time) will take quite some time. We will inform you about a plausible release date when a first prototype will be released. Please donate to our open collective campaign if you want to actively support the development of the new Riot.js major release

API changes 🚧

• [ ] Complete rewrite of the compiler simplifying the sourcecode and the parsing
• [ ] Switch to Simulcra.js as default rendering engine
• [ ] Remove riot-observable in favor of callbacks lifecycle methods
• [ ] Remove this.tags from the tags instances in favor of ref https://github.com/riot/riot/issues/2360
• [ ] Add support for shadow DOM or at least support the :root selector instead of :scope
• [ ] Remove riot.csp.js in favor of a single version compatible for any environement
• [ ] Cleanup the readme file removing dead links to tutorials or old riot stuff
• [ ] Simplify the mixin logic allowing only object
• [ ] Make the use of <script> and <style> obligatory
• [ ] Remove the shouldUpdate method
• [ ] Drop the use of each={ items } in favor of each={ item in items }
• [ ] Update the API simplifying the arguments overload issue for many riot methods

✌️

I would like to make a unit test with mocha to check that the code pushed on any pull request does not break. Another advantage could be to check the crossbrowser compatibility on any release automatically. We need to create an account on saucelabs ( email + psw ) and @tipiirai you should create also the travis hook

This PR introduces a huge improvement in our routes making it easy to define different callbacks for each path. Below I am adding some examples, check the tests for more details.

// Defining several routes at once
riot.route({
   // static route
   "/home":  function(params) { ... },

   // RegEx route 
   ".*/something": function(params) { ... }, 

   // Passing params
   "/items/{item}": function(params) { ... },

   // With RegEx and several params 
   ".*/{type}/{id}?.*q={q}.*": function(params) { ... }
});

// Defining a single route
riot.route("/somepage", function(params) { ... });

// Trigger a route, this will execute the the callback of this route
riot.route("/somepage");

The issue:

1. The draggable attribute isn't handled right by riot when you assign it a boolean expression.
2. The HTML standard (and the browser) expects values of "true" or "false" (unlike, "checked", for example, which expects "checked" value or non).
3. Riot translate a truthy value into the string "draggable" - which doesn't make it draggable.

Reproduction https://codesandbox.io/embed/riot-js-7-bug-template-forked-1mco0f?fontsize=14&hidenavigation=1&theme=dark

Test context browsers: Chrome and Firefox, linux OS, riot version 7

Issue type Bug

Help us to manage our issues by answering the following:

1. Describe your issue:

In my company we are working on a huge and terrible legacy code written in Angular 11 and we'd like to gradually migrate out of it into Riot, with which we have a good experience in other project. We thought about building an angular component which will function as a bridge between the containing application to the riot component. So far, we managed to do so only when we precompile the riot file into a js file. However, this method would be pretty cumbersome. We didn't manage to properly configure the webpack to do that compilation for us. If you have any ideas how to solve this "bridging problem" we'd be grateful.

3. Can you reproduce the issue? n/a
4. On which browser/OS does the issue appear? all
5. Which version of Riot does it affect? latest (7)
6. How would you tag this issue?

• [ ] Question

Help us to manage our issues by answering the following:

1. Describe your issue:

There is an issue in Storybook repository, Storybook does not seem to support the latest Riot.js.

https://github.com/storybookjs/riot/issues/1

2. Can you reproduce the issue?

3. On which browser/OS does the issue appear?

5. Which version of Riot does it affect?

v4 and later

7. How would you tag this issue?

• [ ] Question
• [ ] Bug
• [ ] Discussion
• [x] Feature request
• [ ] Tip
• [ ] Enhancement
• [ ] Performance