Riot: Riot 3.0.0 roadmap

[GianlucaGuarini]

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:

[TheNavigateur]

Been trying to make a pull request for 3.0.0 in response to this based on this and this, but was having trouble setting up dev environment (now seemingly resolved, here and here) hence delay.

I just hope Riot 3.0.0 doesn't fly out the gate without at least me getting a chance to present it

[GianlucaGuarini]

What about removing the parent -> children properties inheritance?
It seems to create only confusion, pollute the child tags and slow down the riot performances

[avimar]

Performance:
Someone in gitter was just talking about a loop of items, which then looped inside a select box.

we have 250 adAccount, each adAccount need to display 50 consultant. 250 x 50 = 12500.

I'm guessing that each instances is also inheriting the entire parent, which is the problem? Not just the 12,500 instances but also duplicating the entire parent object 50 times.

Expect-ability:
Yes, having access to the parent prop without calling parent is useful, but I was using message and failure variables (which may not be 'best practice') but they were inheriting from their parent! I was _quite_ surprised and had to use childMessage instead to get around this.

So I'm all for removing it... sure, we can wait for 3.0.0 for this possibly breaking change.

[rogueg]

The one place you'll really want to keep the inheritance is for the "anonymous tags" created by each loops. Basically this should still work:

<span>{outer}</span>
<div each={item in list}>
  <span class={active: item == outer}>{item}</span>
</div>

[GianlucaGuarini]

So we need to check if the tag looped is a custom one or an anonymous one.. it looks correct to me

[avimar]

I'm afraid of the exceptions and would rather _cut out_ code.

But... it's namespaced here, into the item variable, so the inheritance doesn't cause clobbering issues.

In terms of performance, is it a clone of the items, or a reference..?

[rogueg]

I'm sure you guys have better instincts on what Riot needs, but FWIW, here are some things I had on my riot wishlist.

• For tests, define tags inline at the top of the test function. This makes them easier to read, write, and encourages shorter, more focused tests.
• A way to avoid updating expensive parts of the page, similar to react's componentShouldUpdate
• Allowing function arguments in callbacks onclick={foo('bar')}
• Shortcut for 2-way binding of inputs.
• When a critical opt changes, provide a way to completely reload that tag, similar to react's key.
• Improve the performance of adding new tags and each (maybe using prototypes?)

[avimar]

Allowing function arguments in callbacks onclick={foo('bar')}

... that would be cool -- but not generally the way JS works. It would allow me to skip data- values and event.target.getAttribute('data-) calls. e.g.:

<span each={name,i in daysOfWeekHuman }>
    <input type="button" data-day={i} value={name} onclick={seeDay}/>&nbsp;
    </span>

this.daysOfWeekHuman = ['Sunday','Monday','Tuesday','Wednesday','Thursday','Friday','Saturday'];
this.seeDay = function (event){
    var seeDay = event.target.getAttribute('data-day');
    ...
    }

... with this:

<span each={name,i in daysOfWeekHuman }>
    <input type="button" value={name} onclick={seeDay(i)}/>&nbsp;
    </span>

this.daysOfWeekHuman = ['Sunday','Monday','Tuesday','Wednesday','Thursday','Friday','Saturday'];
this.seeDay = function (data){
    var seeDay = data;
    ...
    }

[acousticseagull]

@avimar you should be able to do that with .bind.

onclick={ seeDay.bind(this, i) }

[GianlucaGuarini]

@rogueg great feedback thanks

For tests, define tags inline at the top of the test function. This makes them easier to read, write, and encourages shorter, more focused tests.

I agree I will clean this up as soon as the dev branch will be merged into the next branch

A way to avoid updating expensive parts of the page, similar to react's componentShouldUpdate

I thought about this and I guess we can use simply a flag isFrozen, if it will be true we will freeze all the tag updates

Allowing function arguments in callbacks onclick={foo('bar')}

Here I would like to avoid overcomplicating the riot api, .bind(this, ...params) seems to be the best option right now. Using data-val seems to be also a valid alternative

Shortcut for 2-way binding of inputs.

Checking the result of this post I guess this feature is not necessary. I still prefer the one-way data flow.

When a critical opt changes, provide a way to completely reload that tag, similar to react's key.

Can you provide more info? From the riot doc it's not really clear to me what's really used for

Improve the performance of adding new tags and each (maybe using prototypes?)

Of course I agree

I have added all the feedback I like to the initial post. I hope to work again on the next branch as soon as you guys will merge the dev branch

[pakastin]

My newer reorder snippet is faster and more flexible in most cases, you should definitely check that out:
https://github.com/pakastin/f/blob/master/src/setchildren.js

Here's some benchmarks against others:
http://pakastin.fi/perf

The reverse is the extreme case, because there's nothing to skip. When there's only few to reorder, or some of the views gets removed, it's even faster, because it can skip the actions cleverly, when needed.

[wellguimaraes]

I think another way to emulate componentShouldUpdate could be returning false on an tag update handler like this:

this.on('update', function() {   
  // do some checking
  return false; // if tag should not update
});

This would be possible if we had some changes on riot.observable behavior as I proposed here https://github.com/riot/observable/issues/16

If you guys think it is a good idea, I can work on this.

[GianlucaGuarini]

@wellguimaraes I think it's a lot easier if we just detect the isFrozen flag here and return

[wellguimaraes]

But probably I would set isFrozen inside an update handler, based on some checking, right?

Actually, the observable change idea was not meant to solve the tag frozen state, but eventually it could be an alternative solution to prevent update, as it could be used to prevent unmount and so on...

[avimar]

What about removing the parent -> children properties inheritance?
It seems to create only confusion, pollute the child tags and slow down the riot performances

+1, it created much confusion for me... accessing the parent opts is sometimes annoying, but more more predictable.

[rogueg]

I like the idea of checking return values from update, but that could get ambiguous if there are multiple handlers attached. What about an explicit method?

shouldUpdate() {
  if (opts.color == this.oldColor) return false
  this.oldColor = opts.color
  return true
}

If that method is present on the tag, then it gets run before an update. You could also gate _parts_ of a tag, which is pretty cool:

<div shouldUpdate={colorChange}>
  <span each={bigArray}>{color}</span>
</div>

colorChange() {
  if(opts.color == this.oldColor) return false
  this.oldColor = opts.color
  return true
}

I could even imagine a helper method for checking when the value at some path (ie opts.color) changes.

[wellguimaraes]

@rogueg I also like the idea of using a method to check whether the tag should update or not.

** I believe it would not get that ambiguous with multiple update handlers. We just need to know that if any handler return false, the update process would stop.

[GianlucaGuarini]

@rogueg ok let's use shouldUpdate I will update the next branch this weekend

[rvion]

Is the v3 alpha already usable ?
is there a release date planed already ?

---

thanks for that great lib

[GianlucaGuarini]

@rvion try npm install riot@next ;)

[rvion]

@GianlucaGuarini thanks :)
(for now, I clone the next branch and manually make min)

---

minor remark: those 2 features :

What about removing the parent -> children properties inheritance?
It seems to create only confusion, pollute the child tags and slow down the riot performances

and

Improve the performance of adding new tags and each (maybe using prototypes?)

from this thread do not appear in the top post summing up remaining items.

[mykone]

Hello @GianlucaGuarini, and thanks for this great framework. What is the current status of the "Experimental" Riot.Tag method used in manual tag construction. I really prefer this style of coding, because I don't like to mix logic with view in the same file.

[crisward]

A couple of suggestions for riot 3.0

Naming of custom event attributes

At the moment if you have a custom component and add an 'onclick' attibute this gets interpreted as the whole component having this and gets handled by riot.
ie

<cutomtag onclick="{somehandler}"></customtag>

There is no way to (that I know of) to handle this inside the component, ie just have a specific click area. This means we have to avoid native event handler attribute names. Custom attributes are much less 'guessable' than the native ones.

It would be really cool if we could..

<customtag>
  <script>
    this.onclick=function(e){
      // this runs instead of native
    }
  </script>
</customtag>

names and id's being attached to this

This has bitten me a few times, when named inputs have clashed with variables in the tag.
ie.

<customtag>
  <input name="user" />
  <script>
    this.user = "fred"
    this.on('update',function(){
      console.log(this.user)//is this fred or the input domnode?
    })
  </script>
</customtag>

Removing this now would break a lot of code. But a warning in the compiler would be really useful, or some kind of runtime error. Possibly by setting the writable property of the attached references. I've not used writeable properties on objects but Object.defineProperties seems to be supported in IE9+.

It looks like putting a console.warn in the objects setter could work, making a once use property
ie

obj = {}
Object.defineProperties(obj, {
  "user": {
    set:function(val){
      if(!this.value){
        this.value = val
      }else{
        console.warn("cannot set value of user")
      }
    }
  }
})

obj.user = "hello" // this works
obj.user = "hello2" // this warns

[GianlucaGuarini]

@crisward

At the moment if you have a custom component and add an 'onclick' attibute this gets interpreted as the whole component having this and gets handled by riot.

If I've understood what you mean I guess it should be already possible http://plnkr.co/edit/foTx2Vect5KmcDe7BUmP?p=preview

names and id's being attached to this

This is a dangerous change because it will trigger warnings also if your properties will be changed manually without riot. I might think about this and probably we can simply cache the riot DOM nodes in a property like this.ref. But this break change will be a pain for the whole riot ecosystem

[crisward]

@GianlucaGuarini

This is what I had in mind, http://plnkr.co/edit/lFKdf24ZbPX15BXtL8WM?p=preview

my-tag.html
So the internal this.onclick would override the tags onclick attribute. The default behaviour is to make the whole tag clickable which is sometimes useful to override.

tag2.html
It's also not possible to filter the event bubble as the outside one gets handled in parallel.

[GianlucaGuarini]

@crisward is this not enough http://plnkr.co/edit/GFEoRsDIHjmoD9NtbwF3?p=preview ?

[crisward]

@GianlucaGuarini it's still fires outside of the button, which means your component is unable to encapsulate it's own event logic if you use native event names. If the outside attribute was called on-click or buttonpressed it would work. But using native event names provides a much more predictable/familiar api. Not sure what other people think...

[MartinMuzatko]

Are there any decision-making discussion threads or issues regarding this _feature_?

remove the automatic preventDefault from the riot DOM events

[GianlucaGuarini]

@MartinMuzatko I have updated the task description adding the issues/confusion of some of our users regarding this topic

[rsbondi]

@crisward why not this.root.addEventListener('click', function(e) {...})?

[crisward]

@rsbondi thanks for the suggestions, it still fires the outside event. See example here

http://plnkr.co/edit/lFKdf24ZbPX15BXtL8WM?p=preview (my-tag.html)

[rsbondi]

You have both events attached to the same element, so there is no propagation to stop. This does not seem to be a riot issue, but maybe you can open a separate issue as we have strayed from the roadmap here

[crisward]

I realise that, that's why I'd like riot to check if a method on the tag already exists with the event name before adding one. So if this.onclick exists on the tag, don't add another onclick, instead use the one specified inside the component. I think it would be a useful addition for riot 3.0.

[nodefish]

What spec for shouldUpdate ended up in the alpha? Is it component-wide or can it be used to gate parts of the tag as rogueg suggested?

[GianlucaGuarini]

@nodefish the shouldUpdate method added to the riot alpha works on the whole component http://plnkr.co/edit/bZxn8Q0uEy0EB0RDV5WM?p=preview

[nodefish]

@GianlucaGuarini Understood, thanks.

[MartinMuzatko]

@GianlucaGuarini do you need help with the makefile? Do you already have plans to which build system to switch?

Webpack? Gulp? Something else?

[MartinMuzatko]

Also, regarding removing preventDefault and auto update for DOM events. I'm sure this puts the user a lot more in control of what happens and what shouldn't. I'm sure it is confusing that sometimes you have to call update and sometimes not. Also that sometimes you have to preventDefault and sometimes not. So that change is perfectly valid. But I think it is a bit against our philosophy of unnecessary boilerplate. What do you think? More control vs ease of use and conventions? Because we had return true earlier for enabling preventDefault (AFAIK)

Anyhow, I can't wait for the implementation details, once this version is released.

[mykone]

Rather than removing the feature, why not do what another framework does?
They implement preventDefault by default and provide an option for you to
enable it. The difference though is that they configure events using class
properties, so they can pack different options in there.

I do like how Riot uses direct vanilla events, which is less coding, but
how would you give the user the option to disable/enable preventDefault and
stopPropagation? Maybe you can use a custom attribute?

On Monday, July 11, 2016, Martin Muzatko [email protected] wrote:

Also, regarding removing preventDefault and auto update for DOM events.
I'm sure this puts the user a lot more in control of what happens and what
shouldn't. I'm sure it is confusing that sometimes you have to call update
and sometimes not. Also that sometimes you have to preventDefault and
sometimes not. So that change is perfectly valid. But I think it is a bit
against our philosophy of unnecessary boilerplate. What do you think? More
control vs ease of use and conventions? Because we had return true
earlier for enabling preventDefault (AFAIK)

Anyhow, I can't wait for the implementation details, once this version is
released.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/riot/riot/issues/1694#issuecomment-231678150, or mute
the thread
https://github.com/notifications/unsubscribe/AAZkuffljAZ9PVp8F_QLSF-TVZXVo6ywks5qUgVogaJpZM4H0iWK
.

[MartinMuzatko]

@mykone a great plus of riot is, that you don't have to configure anything to make it work. There is a configuration object though. riot.settings this is where this might belong. I'm sure it makes sense to have some conventions and standards, but maybe there is a reason not to add an option for that?

[avimar]

If this is a major gotcha for checkbox and radio options, then can you just add that preventDefault isn't called on those types?
The general defaults seem to have worked rather well...

[mykone]

Martin. Yeah, riot.settings sounds like a good place, but that would affect
all the events in that Riot view, but what if I want that behaviour for
only one element in that view, and keep the others as default?

On Mon, Jul 11, 2016 at 8:03 AM, avimar [email protected] wrote:

If this is a major gotcha for checkbox and radio options, then can you
just add that preventDefault isn't called on those types?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/riot/riot/issues/1694#issuecomment-231761652, or mute
the thread
https://github.com/notifications/unsubscribe/AAZkuWaL4HkN_CzWaWTrXH-e-IufFcEoks5qUlsqgaJpZM4H0iWK
.

[MartinMuzatko]

AFAIK the riot team wants to keep exceptions to a minimum. @avimar @mykone

Less cognitive load

[GianlucaGuarini]

@MartinMuzatko the new riot release will be focused on performances and stability rather than unpredictable behaviors (I don't like the magic stuff). The automatic prevent default and the auto DOM updates in the loops caused many problems for our users. The new riot simply will allow you to do event.preventDefault() whenever you need it rather than doing it always per default sticking to the default javascript behavior. We have also upgraded our events handling using DOM 2 events listeners. Another big update will be the use of refs instead of name or id to better scope the DOM elements queries under the same path this.refs.myDomNode @cognitom should be already working on this feature

[avimar]

The magic stuff -- like child inheritance caused problems. Not just the unexpectedness, but even figuring out how to work around it.

Where will event.preventDefault() be needed most? I think we'll need a robust upgrade guide. I think any onsubmit handle will probably need that triggered.
Hmm. I wonder if there can be an upgrade-assist like lodash-migrate? One that will log to console any time event.preventDefault() was called automatically for you, as well as other things?

Another big update will be the use of refs instead of name or id to better scope the DOM elements queries under the same path this.refs.myDomNode

So until now, myTextBox was referenced by this.myTextBox for the DOM and this.myTextBox.value for the value. That did cause some confusion as I was.. hoping? for 2-way binding of this.myTextBox. But now at least they won't clobber each other.
Is there any good way to link a dom node value directly to a variable for automatic 2-way updates?

[crisward]

I have no problem with having to call update() after modifying the state. However the preventDefault() I'm less convinced about. Many programmer won't know when to use preventDefault() so will get unexpected consequences when creating client side applications, possibly introducing more common questions.

An obvious one for this is when using onsubmit. Also anyone who has tried to write a drag feature knows how many events need preventDefault adding.

When don't you want to preventDefault? I've checked my riot components and I don't think I've ever had to use the return true option. The debate between 'purity' and 'convenience' should fall in favour of easier to understand code, and if the browsers implement something in a difficult to understand ways I think frameworks like Riot are well within their remit to smooth those edges.

[dogada]

IMO it will be good to add migration switch like
riot.settings.preventDefault, so old code will not be broken with new
Riot 3.0 behavior.

Regards,
Dmytro.

On Tue, Jul 12, 2016 at 10:35 AM, Cris Ward [email protected]
wrote:

I have no problem with having to call update() after modifying the state.
However the preventDefault() I'm less convinced about. Many programmer
won't know when to use preventDefault() so will get unexpected
consequences when creating client side applications, possibly introducing
more common questions.

An obvious one for this is when using onsubmit. Also anyone who has tried
to write a drag feature knows how many events need preventDefault adding.

When don't you want to preventDefault? I've checked my riot components and
I don't think I've ever had to use the return true option. The debate
between 'purity' and 'convenience' should fall in favour of easier to
understand code, and if the browsers implement something in a difficult to
understand ways I think frameworks like Riot are well within their remit to
smooth those edges.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/riot/riot/issues/1694#issuecomment-231961383, or mute
the thread
https://github.com/notifications/unsubscribe/ABtBWfLKHvp1x-0prGWaftGOB9Dp1UO-ks5qU0PdgaJpZM4H0iWK
.

[nodefish]

The magic stuff -- like child inheritance caused problems. Not just the unexpectedness, but even figuring out how to work around it.

Agreed. My main source of difficulty (not that Riot is difficult, overall) with Riot has been the magic. Another example is that Riot's shorthand functions automatically bind this to the tag instance. It's expected for this to be bound to the call context (e.g. scope from which the function is called), so in most cases there's no difference since you do call the functions from the Riot tag; however, in a few subtle and/or complex cases, it's quite a mess dealing with this, e.g. defining a function in a tag like so:

this.myFunc = function(){
//     `this` doesn't refer to the real tag instance here, even though it looks like it does in the debugger!
}

(I'm not saying the above example should be changed, I just cited it for illustrative purposes of the dangers of magic.)

For me, explicit metaphors make for a much stronger design than magic. So, in general, I'm glad some of the more hazardous magical things are being toned down.

@crisward I feel strongly that preventDefault should be a deliberate decision by the programmer. If programmers don't know about it, then the Riot documentation should give a hint about what it means, as well as direct people to external docs that discuss preventDefault. This seems preferable to Riot hiding the decision from inexperienced programmers.

On a different note, to play the devil's advocate, maybe we should force the developer to make a decision on preventDefault? Meaning that Riot event handlers must return true or false, or throw a warning? Or if not a warning, then at least a style convention, i.e. in the docs/examples, all Riot event handlers have a return statement. This would completely remove the implicitness and preventDefault would be part of the thought process when writing Riot functions.

Having functions return a value isn't boilerplate, so I don't find it bad at all to return true/false in all of them.

[avimar]

Regarding preventDefault, I only needed to actually run the "default" once, which I just wrote last week:
<input type="text" onkeydown={handleEscape}> to make a feature for ESC resets the box to the previous value.
And apparently that's only for the Escape button, since everything else is usually onkeyup/onchange which _already_ had an action and wouldn't have needed to return true
So 99.9% of the time, I _want_ preventDefault.

I'm actually concerned with the option of riot.settings.preventDefault since that makes a huge difference across the codebase. Hmm, wouldn't that also affect e.g. including riot-gear's tags? The point is NOT to be backwards compatible -- that's what the increase in major version is for. The point is: "What's the best choice?" and I think the "most used" is the best one.

Regarding calling update() I'm OK with that -- but it's still a big change -- since many of my changes happen async anyway I'm pretty sure I need to call it most of the time explicitly.

[GianlucaGuarini]

I am thinking about removing the spaced events in [email protected] to gain more speed it would be nice to have other opinions on this as well

[cognitom]

I'm still working on it, here's the entity map of v3.0, at this point. Just FYI, guys.

This is not a complete graph, but I hope it helps someone's understanding.

[rogueg]

What's the ETA for releasing riot 3? Looks like the only thing remaining on the list are internal, or non-breaking. They could easily be pushed off to a minor release.

[aMarCruz]

@rogueg riot-compiler v3 is not ready yet.

[GianlucaGuarini]

@rogueg the performance issue is a problem I want to solve before releasing [email protected]. Sourcemaps for the compiler are also an important feature so I would like to wait and make a good release with all we have planned for riot@3 instead of an incomplete upgrade. I must also say that there are still some problems in the @next branch that must be solved ( the unit test for example does not run on all our test browsers ) I guess we will be able to release riot@3 for the end of this year

[GianlucaGuarini]

[email protected] should be quite stable and I have optimized a lot the each rendering especially with the no-reorder attribute enabled. Please test it and let me know your feedback

[nodefish]

Is 3.0.0-alpha only available with in-browser compilation? Is the 3.0.0-alpha standalone compiler not functional at all? I've been using the alpha with in-browser but I need to switch to precompiled for various reasons.

Thanks.

[limodou]

I need 3.0.0 compiler too.

[nodefish]

FYI - If you don't need pre-processing, you can very easily use the in-browser compiler API to emit JS files. Here's a browserify transform:

var through = require('through2');
var riot = require('./lib/riot+compiler.js'); //3.0.0-alpha.10 (browser)

function isRiotTag(filename) {
    return /\.(tag)$/i.test(filename);
}

var chunks = [];

function transform(chunk, enc, next) {
    chunks.push(chunk);
    next();
}

function flush(callback) {
    var stream = this;
    var source = Buffer.concat(chunks).toString();

    try {
        source = source.slice(1); //remove invalid character at start of .tag files
        var js = riot.compile(source, true);
        chunks = [];
        this.push(js);
        this.push(null);
    }
    catch (e) {
        console.log('Error occurred');
        console.log(e);
    }
}


module.exports = function (file) {
    if (!isRiotTag(file))
        return through(); //not a .tag file? simple passthrough

    return through(transform, flush);
};

However, in my use case, pre-processing is preferable, so that's why I'm asking, as I'm wondering if I should write a module for it (shouldn't be very hard, but I just want to make sure I'm not reinventing the wheel. :) )

[GianlucaGuarini]

Is 3.0.0-alpha only available with in-browser compilation? Is the 3.0.0-alpha standalone compiler not functional at all?

The riot-compiler is also in alpha and it could be installed via npm npm i riot-compiler@next. The riot-cli alpha has not been released yet. I know that @aMarCruz is completely rewriting the compiler in order to generate source maps so please be patient.

[nodefish]

Sorry if this is a stupid question: since the CLI isn't out, then how can we use the 3.0.0 alpha compiler? Just require it in any script and call compile?

Thanks 👍

[GianlucaGuarini]

@nodefish no problem. Yes just requiring it should be enough the api is pretty simple https://github.com/riot/compiler/blob/b70d9ab0608d7e4132a02ecc54ea0d3c3206d8ed/test/specs/parsers/_suite.js#L37

[nodefish]

Thanks 👍

Gonna figure out how to add it to my build step w/ pre-processing. :)

[vitogit]

@cognitom the graph is great, is it updated ? is there any other sources of information about how Riot works internally?

[fabien]

@GianlucaGuarini would you recommend using next for new projects right now?

[GianlucaGuarini]

@fabien yes I could recommend it. Our unit test passes on all the browsers except a small issue with the <select> tags on ie9 but it's an edge case. Remember that it's still an alpha release and the core might change in case we will switch to more performant rendering strategies. The api should be frozen at this point because we have updated all the things we didn't like in riot@2

[fabien]

@GianlucaGuarini thanks - I will check it out! I was already using v2, but I think it's best to go forward with v3 then. Are there any particular incompatibility issues I should be aware of when upgrading my v2 code?

[avimar]

There are several -- we need an upgrade guide.

1. removed the automatic preventDefault from the riot DOM events. For onclick onsubmit and others you probably need to add a preventDefault.
2. Riot-route?
   ... others?

[sourcegr]

Also, the use of _refs_ for names/ids is something you should keep in mind

On Oct 24, 2016 7:11 PM, "avimar" [email protected] wrote:

There are several -- we need an upgrade guide.

1. removed the automatic preventDefault from the riot DOM events. For
   onclick onsubmit and others you probably need to add a preventDefault.
2. Riot-route? ... others?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/riot/riot/issues/1694#issuecomment-255786945, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ADwG7yh06qb00v9jGy7nXtumFRXszwL2ks5q3NjGgaJpZM4H0iWK
.

[fabien]

Do I gather correctly that you'd need ref attributes in place of id or name? What about the cases where those attributes would be a more natural fit, like <input name="foo">? How can these referenced elements be referenced? As before, straight on the current (this) scope?

Also, I don't think shouldUpdate has been implemented, yet it's checked-off from the list in this thread.

[juodumas]

Yes, elements with ref="foo" will be accessible as this.refs.foo. It will point to a tag for riot tags and dom element otherwise.

Values of id and name attributes will no longer be polluting this, and you will simply use <input ref="foo">. This is good, because name and id can be used for their intended purpose without side effects on this.

shouldUpdate is implemented: https://github.com/riot/riot/blob/fe4fc33/lib/browser/tag/tag.js#L122

[fabien]

@juodumas thanks! I found out that I was grepping v2.6.4 looking for refs and shouldUpdate, thinking I had checked-out next. Nevermind!

[fabien]

OK, looking at the shouldUpdate implementation, shouldn't data be passed to it as an argument? In order to work out if it indeed needs to update, based on that very data? Even though it's an optional argument? (perhaps an empty {} should be passed in that case?)

[GianlucaGuarini]

Hi everyone I have some good news.

We will release [email protected] really soon, we need to update the doc writing down a smooth migration path from riot@2.

Currently [email protected] has been released, and it should be stable, so please test it even if it will be hard to know what to test without having a list of the breaking changes :)

The riot team have recently discussed deciding to release [email protected] as it is, because it solves many riot@2 issues and it's a big improvement to the original codebase. We are planning further performance optimizations, compiler sourcemaps support and hot modules replacement for the future feature releases.

@tipiirai is really motivated and he is writing an experimental riot release on the experimental branch that should solve many performance issues and introduce new cool ideas for [email protected]

✌️

[Rayraegah]

@GianlucaGuarini Don't forget to update/add Riot 3.0.0 benchmark on js-framework-benchmark

[limodou]

@GianlucaGuarini Is there riot-compiler for 3.0.0 already?

[GianlucaGuarini]

@limodou https://github.com/riot/compiler/blob/master/CHANGELOG.md#v300

[GianlucaGuarini]

[email protected] is out! Let's move forward