Who uses what? (plugin wise)

[dagnelies]

Just out of curiosity. I have the feeling several plugin parts of Ractive are almost unused by anyone.

Personally, I have the feeling that the most widely used ones are:

• Components
• Partials
• Transitions

Edit: considering the answers, it appears following ones are indeed used pretty much:

• Decorators (especially for things that enrich a node, like a tooltip, I was enlighted)
• Events (apparently, these ones are mostly used for a standart set on events. Perhaps merging them all in a standard lib could prove useful.)

While the following ones are left rarely used:

• Adaptators (in my experience you don't want that because you usually need more control over how you communicate with the back end, the data itself, and how you deal with errors ...it can also be trivially done using an observer)
• Easings (default ones appear sufficient)
• Interpolators

...so I was curious if anyone of you use these at all IRL ...and please don't mention the "plugins" in resources, 90% of them are broken and unmaintained, but that's another topic.

[kouts]

I haven't used adaptors, easings, interpolators
I have created a custom event once just for normalizing the click event on checkbox across browsers.
I heavily use decorators, very useful for wrapping jQuery plugins functionality and stuff that does DOM manipulation.

[giovannipiller]

We use Decorators quite a lot, though I agree that most of their applications could be implemented via Components as well.

The main reason we're not doing so, is that Components seem to be more memory intensive.
Also, conventionally speaking, we try to avoid performing DOM changes, or attaching events, directly through the Components' javascript.

Custom events are nice to have, though I don't see me needing more than a couple.

[LeJared]

I've used custom events a lot, mostly for easy usage of drag & drop (eg. on-filedrag="" to abstract all those obscure dragstart, dragover, dragmove events and so on) or some short-cut keyboard-bindings (e.g. on-keyescape="", on-keyenter="", on-keytab="").

I also heavily rely on decorators. I use them for all kind of things. E.g. add char/line-counters, line numbers, autoresize and other functionality to input fields (in any desired combination). Add tooltips/popovers to all kind of elements.

I think, decorators are much more easy to use than a separate component in a lot of cases. Want to add some extra functionality to any existing element? Just add a decorator!

I don't use adaptors, easings and interpolators

[fskreuz]

I mostly use

• Components and partials (depending on the amount of logic)
• Events (cross-browser event inconsistencies, or merging events into one)
• Decorators (simple DOM manipulation/jQuery plugins integration)

I rarely use adaptors, and almost none of the animation stuff (transition, easing, interpolators)

please don't mention the "plugins" in resources

I actually use a few of them:

• Transitions - for quick animations. When it becomes complex, I often move out to CSS.
• ractive-load - for quick prototypes. When it becomes complex, I swap to a custom build.

But yeah, I agree. Generally, they're all dead. Typical open-source.

Easings (seems to overlap with interpolators)
Interpolators (seems to overlap with easings)

They're often confused with each other, but they're actually distinct pieces and work in tandem. The plugins page now has an updated description of them. TL;DR: Easing converts linear animation time to "squiggly animation time", Interpolators convert "squiggly animation time" to "squiggly values". Something like

const progress = easing(time)
const value = interpolator(startValue, endValue, progress)

[PaulMaly]

I use all of these things a lot, except Easings/Interpolators. But I think this stuff could be very useful in projects which work with a graphic or something like that. So, seems many people could need it.

Adaptators (in my experience you don't want that because you usually need more control over how you communicate with the back end, the data itself, and how you deal with errors ...it can also be trivially done using an observer)

I believe that Adaptors is one of the most unique features of Ractive. I think the main part of this feature is a filtering which data need to adapt. So, in theory, you can simulate Adaptors functionality via observers, but I don't think so you want to observe all the data at multiple times. Seems it can lead to big expenses.

Decorators (this one could be eaten up by components IMHO since they can provide the same functionality)

Hm, I think Decorators are cheaper than Components in most of the cases.

Events ( Personnally, I never had the need to write such a plugin since components can have their own events and for common DOM nodes, mapping on-* the the corresponding on* seem just fine to me)

In my last project, I used this one: https://github.com/ractivejs/ractive-events-keys
Simple and convenient to use.

[ceremcem]

I use components extensively ("everything is a component" approach) and rarely use partials (mostly for yielding inside components). Lately I saw what decorators can do, and now I'm simply (re)writing appropriate parts with decorators.

I've never used Easings, Interpolators and Adaptors (and I don't know what they are, actually).

Altough I use Events rarely, it's handy when it comes to on-longpress, on-keyenter, on-keytab etc...

I'm also looking for a way to improve inter-component communications where we can send/receive events to/from another components directly (by declaring only within the template, like drawing PCB's or function block diagrams). Lately, @evs-chris announced Custom event plugin init args support which makes me feel like it will help very much on this one.

[PaulMaly]

@ceremcem

I'm also looking for a way to improve inter-component communications where we can send/receive events to/from another components directly (by declaring only within the template, like drawing PCB's or function block diagrams).

I don't know your case detailed but you able to do that: playground

[ceremcem]

@PaulMaly Template should look something like:

Ractive.components.Foo = Ractive.extend({
  ...
  on: {
    error: function(ctx, reason){
      // do something with the error
    }
  }
})

new Ractive({
  el: 'body',
  template: `
    <Foo cls="someClass" />
    <Baz cls="someClass" />
    <Bar cls="anotherClass" on-error="someClass>>coordinateChange" />
    <button on-click="anotherId>>dostuff">Fire to Child</button>
  `
});

Foo and Bar are different components but displays same kind of value (eg. a tank level and errors), so they "subscribe" to the same "event source".

[evs-chris]

I use everything except easings (well, the usual suspects are built-in, but I've not felt the need for custom easings) and adapators. I think I would use adaptors if they were a bit more fleshed out e.g. could handle managing a firebase store.

I use partials nigh constantly.
Components are a close second.
Transitions have a pretty big benefit over css transitions (which they use under the hood anyway) in that you can actually animate a correct height.
Custom events I've just started using and liking it a lot, especially for specific key events, being able to have separate click and dblclick events that also work on mobile, and to string touch events together usefully and in a mouse-friendly way.
Decorators get a fair bit of use too, sometimes just for tracking certain nodes for a component, sometimes for third party integrations like Ace/CodeMirror, and sometimes for minor DOM manipulation/tooltip-like cases.

Surprisingly, I have used a custom interpolator for colors - that can take say '#919282 and animate it to rgba(14, 131, 88, 0.3). If you don't ever use ractive.animate, you have no use for interpolators (the plugin, not the mustache 😄).

But yeah, I agree. Generally, they're all dead. Typical open-source.

True, but to be fair, most interpolators, events, easings, and transitions are write-once plugins that basically require no maintenance. Some decorators fall in that category too.

@ceremcem you could probably achieve that by setting up a listener on the root instance that tracks components by their wid (*.render or *.init, where the last arg is the source instance). Then you could on-drag="@.root.registry.someUniqueId.fire('coordinateChange', @context)" or something like that. Methods would be a little bit cleaner than instance events in this case.

[dagnelies]

thanks for all your responses, I found some of them enlightning. I was thinking of making a learning resource for ractive, with demos, recipes, "how to" and such, but haven't come very far, it takes quite some time.

[ceremcem]

@evs-chris Thanks for the tip, here is the results