These are chat archives for ractivejs/ractive

1st
Mar 2018
Chris Reeves
@evs-chris
Mar 01 2018 05:51
question of the day: is anyone actively using edge builds for anything production-ish?
I ask because I'm about to push an update that doesn't detach everything during a shuffle, and while the test suite passes, it's a pretty big change
Cerem Cem ASLAN
@ceremcem
Mar 01 2018 11:02

question of the day: is anyone actively using edge builds for anything production-ish?

it's me

lately I started using 0.9.13 though...
kouts
@kouts
Mar 01 2018 13:18
Quick question: Can I have something like this or equivalent?
on-click="{{#if some.property}}action{{/if}}"
Larry Osborn
@larryosborn
Mar 01 2018 13:27
This works {{#if some.property}}on-click="action"{{/if}}
kouts
@kouts
Mar 01 2018 13:37
thanks @larryosborn !
Joseph
@fskreuz
Mar 01 2018 14:03
@ceremcem you can use stats from jsDelivr to infer what versions and variants of Ractive are in use https://www.jsdelivr.com/package/npm/ractive
You can ask @MartinKolarik anything related to jsDelivr :grin:
Juan C. Andreu
@andreujuanc
Mar 01 2018 14:53
martin uses ractive in jsdlivr right?? C:
Cerem Cem ASLAN
@ceremcem
Mar 01 2018 14:55
@fskreuz I'm using ractive from npm
@andreujuanc yes, AFAIK
Cerem Cem ASLAN
@ceremcem
Mar 01 2018 15:01
does anyone uses Pug? I can't manage to add the {{extra-attributes}} with Pug syntax
Chris Reeves
@evs-chris
Mar 01 2018 16:09
@ceremcem I took a swing at it. Looks like you have to set doctype to html to get singular boolean attrs
Cerem Cem ASLAN
@ceremcem
Mar 01 2018 17:01
thanks! @evs-chris it turns out that it was something I have to add in aktos-io/scada.js@4c36967
Martin Kolárik
@MartinKolarik
Mar 01 2018 19:26
@andreujuanc Martin uses Ractive everywhere he can :grin:
@fskreuz we resolve tags to the actual versions though so you won't be able to get monthly stats for "edge" easily
Martin Kolárik
@MartinKolarik
Mar 01 2018 19:32
also, about 11.5M Ractive jsDelivr hits are from one of my projects so it might not be a very representative sample in this case :D
if we ever manage to implement stats for how many unique websites use a specific npm package from jsDelivr, then it might get more interesting
Chris Reeves
@evs-chris
Mar 01 2018 19:45
that's a nice sized project
Juan C. Andreu
@andreujuanc
Mar 01 2018 22:02
@MartinKolarik me too :beers:
I'm implementing our company's api in graphQL, that thing plus ractive gonna give us a big boost for our development team :sparkles:
Juan C. Andreu
@andreujuanc
Mar 01 2018 22:10
@ceremcem I used to use pug when it was called Jade. Miss the old name a lot D:
Martin Kolárik
@MartinKolarik
Mar 01 2018 22:12
oh I also used Jade and I don't miss it at all :laughing:
Juan C. Andreu
@andreujuanc
Mar 01 2018 22:12
xD xD xD
i hate anything xml related xP
Paul Maly
@PaulMaly_twitter
Mar 01 2018 22:13
@evs-chris Sorry about off topic, but how about to little bit simplify Ractive's syntax by restricting event handler by methods only?
Instead of doing this:
    <button type="button" on-click="clickedproxy">Push me!</button>
    <button type="button" on-click="['clickedArray', 'Hello, World!']">Push me!</button>
    <button type="button" on-click="@this.clickedMethod('Hello, World!')">Push me!</button>
Cerem Cem ASLAN
@ceremcem
Mar 01 2018 22:13
@andreujuanc Jade was charismatic, Pug is the most possible ugly rename
@PaulMaly_twitter I remember that discussed earlier, in a github issue
I may find it
Paul Maly
@PaulMaly_twitter
Mar 01 2018 22:14
Do this:
    <button type="button" on-click="fire('clickedproxy')">Push me!</button>
    <button type="button" on-click="fire('clickedArray', 'Hello, World!')">Push me!</button>
    <button type="button" on-click="clickedMethod('Hello, World!')">Push me!</button>
Martin Kolárik
@MartinKolarik
Mar 01 2018 22:14
yeah there was a very long discussion about that
ractivejs/ractive#1172
Paul Maly
@PaulMaly_twitter
Mar 01 2018 22:15
Maybe, I wasn't a part of this. I just don't like to have too much syntax options
This is clickedproxy too ['clickedArray', 'Hello, World!'] much @this.clickedMethod('Hello, World!') for me )))
@MartinKolarik thanks for the link
Chris Reeves
@evs-chris
Mar 01 2018 22:17
the plain expression version (last) is the most
useful, but the others are very handy in different situations
Juan C. Andreu
@andreujuanc
Mar 01 2018 22:19
I do use plain proxies a lot
Paul Maly
@PaulMaly_twitter
Mar 01 2018 22:19
I believe that using build-in method fire() is a good alternative for this
Juan C. Andreu
@andreujuanc
Mar 01 2018 22:19
and array time to time
Paul Maly
@PaulMaly_twitter
Mar 01 2018 22:19
Besides it is more obvious
Juan C. Andreu
@andreujuanc
Mar 01 2018 22:20
last comment on that issue states more or less what you are saying @PaulMaly_twitter , right?
'There is no need to call a method that will fire your event. You would call @this.fire('eventName', event, data) in your template and that's it.'
Chris Reeves
@evs-chris
Mar 01 2018 22:20
the proxy and array forms handle context for you
and is mainly why they exist
Juan C. Andreu
@andreujuanc
Mar 01 2018 22:21
@context?
Cerem Cem ASLAN
@ceremcem
Mar 01 2018 22:31
@evs-chris as the topic is opened, I want to ask one thing: this works but this isn't
only change is from <aaa on-click="x" to <aaa on-click="[x, @index + 5]"
is this normal?
Chris Reeves
@evs-chris
Mar 01 2018 22:36
components are a special case
Paul Maly
@PaulMaly_twitter
Mar 01 2018 22:36
@evs-chris I think the context could be a optional and self-handed, because we don't need in in all cases.
Chris Reeves
@evs-chris
Mar 01 2018 22:36
I think only plain proxies work on components
Paul Maly
@PaulMaly_twitter
Mar 01 2018 22:37
on-click="fire('custom:event', @context, 'Hello world')"
Btw, in most of the cases first argument (ctx) is disturbs me
Cerem Cem ASLAN
@ceremcem
Mar 01 2018 22:39
A-HA! I faced with this problem hundred times and now I see the problem as I write that to you: it must be on-click="['x', @index + 5]"; I was omitting the quote around x
Paul Maly
@PaulMaly_twitter
Mar 01 2018 22:39
Very often I forget about it because it isn't necessary and write my handler like this:
on: {
     'custom:event': function(param) {


      }
}
Cerem Cem ASLAN
@ceremcem
Mar 01 2018 22:40
Paul Maly
@PaulMaly_twitter
Mar 01 2018 22:42
So, I believe we should roll off unevident arguments handling
<button on-click="fire('first', 'Hello world')">First</button>
<button on-click="fire('second', @context, 'Hello world')">Second</button>

...


on: {
      first: function(msg) {},
      second: function(ctx, msg) {}
}
I think it's more transparent and the main thing is uniform
And we can remove additional syntax
Cerem Cem ASLAN
@ceremcem
Mar 01 2018 22:50
@PaulMaly_twitter I'm confused, why should fire('method_name' is used then? Couldn't it be simply on-click="first('Hello world')"?
Chris Reeves
@evs-chris
Mar 01 2018 22:50
@ceremcem ah! I forgot that restriction was removed
Paul Maly
@PaulMaly_twitter
Mar 01 2018 22:51

fire('method_name'

not method_name but custom event name

Cerem Cem ASLAN
@ceremcem
Mar 01 2018 22:51
why? where is the distinction between an event and a method in this approach?
Paul Maly
@PaulMaly_twitter
Mar 01 2018 22:52
Right now we have too many syntax options for this:
If I want to call instance method I do that: on-click="set('foo', 'bar')"
But if I want to trigger event: on-click="event_name"
But if I want to trigger event with additional params: on-click="['event_name', 'Hello world']"
It's too much syntax options for me
Especially if we can do all this using only methods syntax:
So if I want to trigger event with or without additional params I just call the method: on-click="fire('event_name', 'hello world')"
single syntax
Paul Maly
@PaulMaly_twitter
Mar 01 2018 22:58
I can make it is more transparent: on-click="@this.fire()" or use context instead of instance on-click="@context.set()" but still have single sintax

I like Pros described by @Rich-Harris in the issue above:

Pros:

  • eliminates code from the codebase - makes it slimmer, more maintainable
  • reduces the amount of stuff newcomers have to learn
  • removes potential confusion
  • we don't lose any expressive power
Cerem Cem ASLAN
@ceremcem
Mar 01 2018 23:03
I also don't like having too many options from time to time and I even don't understand the distinction between events and methods (OK, practically events gets the @context variable as the first argument automatically) but this might also removed (maybe in the future)
the most argument I agree with is "reduces the amount of stuff newcomers have to learn" thing. this would really worth it.
Paul Maly
@PaulMaly_twitter
Mar 01 2018 23:04
Methods can't be listened and not bubbling)))
I think it's not a question about differences between these two features. It's all about event-directive syntax only
Chris Reeves
@evs-chris
Mar 01 2018 23:07
I believe the reason that the plain proxy event is in there is without it, it seems the instance event system is not a primary feature. If you primarily use instance events, calling fire for each one is a bit painful.
as far as code elimination, plain proxies are turned into expressions at parse time, and the array structure is one conditional check after the expression is called
Paul Maly
@PaulMaly_twitter
Mar 01 2018 23:09
Hm, I don't think so. Seems, we already have fire() method to triggering events, why we should use another thing to do the same?
Chris Reeves
@evs-chris
Mar 01 2018 23:10
so, not much code to eliminate after the two systems were merged
Paul Maly
@PaulMaly_twitter
Mar 01 2018 23:10
maybe, but I think the main part of this is : reduces the amount of stuff newcomers have to learn & removes potential confusion
Chris Reeves
@evs-chris
Mar 01 2018 23:11
also, won't be going back to direct method calls, because it creates a second context for directives (will stay on-click="@.fire(...)" rather than on-click="fire(...)")
there was a fair amount of confusion caused by that in the past
I'm not opposed to removing the proxy forms if there is a strong consensus to do so
Larry Osborn
@larryosborn
Mar 01 2018 23:13
I use plain on almost all the events in my templates. I feel like I’d end up having to write a bunch more boiler plate for all my events if it was removed.
Paul Maly
@PaulMaly_twitter
Mar 01 2018 23:13
for me it looks as an identical code
Chris Reeves
@evs-chris
Mar 01 2018 23:14
as it stands, I use each form depending on what I need in different circumstances
I agree that having too many options can be a bad thing, but sugar can also be a good thing
Joseph
@fskreuz
Mar 01 2018 23:15
(arrives to the scene of the crime)
Chris Reeves
@evs-chris
Mar 01 2018 23:15
case in point: es6 object shorthand { foo }
Joseph
@fskreuz
Mar 01 2018 23:16
I'd like to think of them as 2 totally different systems, each with their own uses: events and methods. Everything else (shorthands, arrays, and stuff) - sugar. :tada:
Paul Maly
@PaulMaly_twitter
Mar 01 2018 23:16
I believe Svelte has made a right choice: https://svelte.technology/guide#event-handlers
Joseph
@fskreuz
Mar 01 2018 23:18
There may be overlaps, but there are cases where one cannot be replaced by the other.
Paul Maly
@PaulMaly_twitter
Mar 01 2018 23:18
@fskreuz yep, but one of this systems have two different syntax for one case - triggering event
on-click="event_name" & on-click="['event_name', param]"
for me it's one case - triggering event
Chris Reeves
@evs-chris
Mar 01 2018 23:19
svelte is not exactly an apples to apples comparison
Joseph
@fskreuz
Mar 01 2018 23:19
That's part of the "sugar" I just mentioned. I personally don't use it, but I also don't mind having it there if someone else likes using it/finds it more convenient.
Paul Maly
@PaulMaly_twitter
Mar 01 2018 23:20
sugar?
which of these two?

svelte is not exactly an apples to apples comparison

yep, it's just a good design

Cerem Cem ASLAN
@ceremcem
Mar 01 2018 23:23
90% I use on-click="doSomething" form, so +1 for simple syntax. when I write events, I use the context variable 70%, so +1 for events/methods distinction (otherwise I have to type on-click="myMethod(@context)" every time). but the on-click='["method", "arg1", "arg2"]' form is really hard to type. if it would be possible, I might ask for changing this form to on-click="event, 'arg1', 'arg2'"
Chris Reeves
@evs-chris
Mar 01 2018 23:26
depending on your editor, it can be (as I use it) on-click=['event', arg1, 'arg2'] - the parser doesn't care about quotes for expressions
Larry Osborn
@larryosborn
Mar 01 2018 23:30
is array syntax needed with a spread operator available?
Chris Reeves
@evs-chris
Mar 01 2018 23:32
for events?
Paul Maly
@PaulMaly_twitter
Mar 01 2018 23:33
on-click="event:{spread}" like this?
Larry Osborn
@larryosborn
Mar 01 2018 23:33
yeah for events
Chris Reeves
@evs-chris
Mar 01 2018 23:33
['event', arg1, arg2] is sugar for @.fire('event', @context, arg1, arg2)
Larry Osborn
@larryosborn
Mar 01 2018 23:35
could on-click=“‘event’, arg1, arg2” be sugar for @.fire(‘event’, @context, arg1, arg2)
Cerem Cem ASLAN
@ceremcem
Mar 01 2018 23:36
@evs-chris is there a real distinction between events and methods? Can't we say "an event is a @.get('method')(@context)?
Paul Maly
@PaulMaly_twitter
Mar 01 2018 23:36
@evs-chris Which of these call will creates a new context?
@.fire('event', @context, arg1, arg2) or fire('event', @context, arg1, arg2)
Larry Osborn
@larryosborn
Mar 01 2018 23:36
Seems like a minor thing, but the array brackets always confuse me when I see them, even though I know what it means.
Cerem Cem ASLAN
@ceremcem
Mar 01 2018 23:37
@larryosborn +1 on this
Joseph
@fskreuz
Mar 01 2018 23:37
@PaulMaly_twitter @ceremcem Before methods, Ractive had a funny way to send args to events (iirc, :-separated, i.e. on-click="eventName:arg1:arg2:..."). Ractive then gained the ability to parse expressions. The old syntax was on one end of the spectrum, the methods (expressions) on the other. The array syntax (on-click='["event", "arg1", "arg2"]') was a compromise to preserve the conciseness of the old one while remaining a valid expression for the other... or at least that's how I remembered the tale. :grin:
Chris Reeves
@evs-chris
Mar 01 2018 23:38
you can already have multiple expressions in an event, so to do that, we'd need a sigil or something
Paul Maly
@PaulMaly_twitter
Mar 01 2018 23:38
@evs-chris So, can I use this: ``on-click="fire('event', @context, param)" instead sugar now?
Chris Reeves
@evs-chris
Mar 01 2018 23:39
this is valid on-click="@.set('foo', 42), @.root.doSomething(), false"
so a set, a call to a root instance method, and cancel bubbling and prevent default with the false
@PaulMaly_twitter yes, but @.fire
Larry Osborn
@larryosborn
Mar 01 2018 23:41
ouch
Chris Reeves
@evs-chris
Mar 01 2018 23:41
sugar is optional
Cerem Cem ASLAN
@ceremcem
Mar 01 2018 23:42
a-ha! chaining in the event directive is new to me and that's what I was looking for in many cases :+1:
Paul Maly
@PaulMaly_twitter
Mar 01 2018 23:42
@evs-chris I don't understand difference between @.fire() and fire() if I use resolveInstanceMembers=true
Chris Reeves
@evs-chris
Mar 01 2018 23:46
the former is unambiguous, so it can't accidentally lead to tears
Paul Maly
@PaulMaly_twitter
Mar 01 2018 23:46
How about context?
Chris Reeves
@evs-chris
Mar 01 2018 23:48
unless you pass a context, it will make one up against root for you
Paul Maly
@PaulMaly_twitter
Mar 01 2018 23:48
ok, seems I got it
thanks!