The many places for functions

[matthew-dean]

Okay, this may be obvious to everyone else who uses Ractive, and not an issue, but I find remembering all the places where to put functions when making a new Ractive maddening.

If I want to have a type of evaluation function like {{ somefunc(val) }}, I have to do this:

ractive = new Ractive({
    el: $target[0]
    , template: $template.html()
    , data: ractiveData
});

...and then I think, "Wait, never mind, I can't do anything with this; I need to put it inside my data." So then I have to do this:

ractiveData.somefunc = function() {  // stuff };
ractive = new Ractive({
    el: $target[0]
    , template: $template.html()
    , data: ractiveData
});

(If you're asking, "Why not just expand data{} and put the function there" it's because I often have generic functions that pass in data to make a Ractive, and while the data changes, the functions do not, because the functions are a requirement of the template not the data, so the functions have to be attached after the data object is received.)

Later, I decide to call a custom function within an element like:

<button on-click="preset({ render: [{ keypath: 'data.LAST_INVOICE',  id: 'invoice_body' }]  })" />

Inevitably, that's where I go wrong. I usually make the mistake of putting the function attached to the data, or if I defined the custom functions, and decide to add an evaluation function later, I usually make the mistake of putting those functions together. Instead I need to do:

ractiveData.somefunc = function() {  // stuff };
// ractiveData.preset = function() // stuff };  NOPE
ractive = new Ractive({
    el: $target[0]
    , template: $template.html()
    , data: ractiveData
    , preset: function() { // stuff }
});

Then, later I want to fire an event delegate, so it looks like:

ractiveData.somefunc = function() {  // stuff };
// ractiveData.preset = function() // stuff };  NOPE
ractive = new Ractive({
    el: $target[0]
    , template: $template.html()
    , data: ractiveData
    , preset: function() { // stuff }
//  , nextStep: function(e, args) { }  NOPE, HAHA SUCKER
//  , prevStep: function(e, args) { }   
});
ractive.on({ 
    , nextStep: function(e, args) { }  //and I always forget the event var being passed in here
    , prevStep: function(e, args) { }
});

So, in the end, I end up with this "spread out" effect.

Now, I'm sure for developers familiar with the internals of Ractive, the mental models for each of these differences makes their placement more obvious than it does to me. But, for me, it's 3 different ways of "registering" functions for Ractive, with 3 different locations for that registration, and with some (or one) type passing in an undeclared event, and the others not. (I sometimes mistakenly put the event var in data functions or custom functions.)

To me, this spread out and inconsistent model doesn't make sense. I'd rather tell Ractive: "HEY MY CUSTOM FUNCTIONS ARE HERE" in one place and then use them where I want and how I want in my template, to evaluate things as helper functions or when firing events, whether that's as a delegate or not. And I wish events were attached to this.event or some such mechanism so that I wouldn't have to remember which function type passes in an event.

It's also frustrating because Ractive is so generous about scope with keypaths, where it searches up the object for a matching key, but with functions, it punches me in the face repeatedly and tells me I look ugly if I put them in the wrong place.

I should say: I absolutely love Ractive probably over any templating or data binding system I've used. But this particular facet makes me crazy.

Or maybe I'm doing all of this wrong and there's something incredibly simple that I'm not seeing.

Help and/or counselling wanted. Thank you for your time.

[JonDum]

You are confusing event method calls and data functions.

This looks up the function on the data object, calls it, and renders the return value:

{{ someFunc(foo) }}

new Ractive({
   data: {
       someFunc: function() { .... }
   }
});

This calls a method on the ractive instance to handle an event:

<div on-click='{{ handleClick(event) }}'>

new Ractive({
   data: {
       someFunc: function() { .... }
   },
   handleClick: function() {
   });
});

Right now that's the way it is, but I agree it's a bit confusing. There are some discussions going on about whether to deprecate the method call syntax in favor of event name syntax to unify this confusion since you aren't the only one confused.

[matthew-dean]

You are confusing event method calls and data functions.

I believe you. I am indeed confused.

This looks up the function on the data object, calls it, and renders the return value
This calls a method on the ractive instance to handle an event

I'm sure there's a difference between those two statements, other than one gets passed an event object. But a "method" and a function are not really two separate things in JavaScript... So, to me, that's more just a way of talking about Ractive. So maybe it takes a greater conceptual knowledge of Ractive to get it. I mean, I get that they're looking at different parts of the ractive instance. But it's always seemed odd to me that functions for the template are on the data object, since data is just data, and the functions operate ON the data. So it's almost as if (in the mental model), you're calling a function that acts upon itself. If you can't get() or set() functions in the data object (or maybe you can, but that's weird), then why are they IN the data? In other words, it's a mix of types. The data property of the Ractive instance points to an object, of which all is data, or some is data, and some is actually not data, depending on if functions are present. To me, functions available to the template should be somewhere else. So maybe that's what's really tripping me up; I don't really understand the rationale for why functions which operate on a data set should pretend to be part of that same data set. Why is it designed that way?

[Madgvox]

The issue is that each of the functions do have distinct uses, and ractive expects completely different things from them. This means it would be very difficult/impossible to adequately combine them. As @JonDum said, using a function inside a keypath is related to data; the function is expected to return some kind of result to be rendered to the template. Thus it makes contextual sense for the functions to be accessible in the same way as other data, namely from the data attribute.

Meanwhile, event functions are most appropriate attached to the ractive instance itself, since that's the context ractive is accessing when it resolves those references. This allows you to call built-in ractive methods from your template, like so:

<button on-click="toggle( 'foo.bar.baz' )">Toggle Button</button>

A custom event function is basically an extension of the ractive prototype, and therefore it makes sense to place them on the ractive instance itself. These aren't expected to return a result to be rendered in the template. They're a fundamentally different type of function from data functions, and they have different expected inputs and outputs. Combining these functions in one spot would cause more confusion than they prevent.

[matthew-dean]

Combining these functions in one spot would cause more confusion than they prevent.

I'm not necessarily saying they need to be combined in one spot. Just maybe some way for it to make more intuitive sense. What you say about their context makes sense, but they're also both in not that dissimilar JavaScript contexts.

If it were more like this, it might be more intuitive:

<button on-click="this.toggle( 'foo.bar.baz' )">{{ getButtonTitle() }}</button>

That would intuitively communicate that one is on the instance (this) and one is a function returning a result. Just a suggestions.

[evs-chris]

Here's my rule of thumb:

1. Is its result output into html in some way? Yes - it goes in data. (event handlers don't ever hit html)
2. Is it meant to handle an event? Yes -
   1. Do you want to call it like a function in the handler? Yes - stick it on the Ractive instance.
   2. Do you want it to bubble automatically or subscribe to it using on? Yes - pass it to on directly.

One thing that does help is to register your common helpers in the global Ractive data registry:

Ractive.defaults.data.helper = function() { return "yep"; };

new Ractive({
    el: 'main',
    template: '{{helper()}}'
});

Outputs:

yep

[evs-chris]

Also, for functions in data, it is a bit confusing until you realize that they're also just references that you're calling, and references have to live in data at this point because that's the only way to resolve them. It also gives you the ability to switch them at runtime. If there are any lurking LISPers, this is where they should jump out from behind a bush and say something about "the code is data and the data is code".

[Madgvox]

Also, for functions in data, it is a bit confusing until you realize that they're also just references that you're calling

That's what I was attempting to get at in my post, but that's a way more concise way of putting it.

[matthew-dean]

@evs-chris Thanks for the rules of thumb! That helps.

If there are any lurking LISPers, this is where they should jump out from behind a bush and say something about "the code is data and the data is code".

There's actually a spray you can get if you have too many LISPers in your bushes.

[martypdx]

If it were more like this, it might be more intuitive:

<button on-click="this.toggle( 'foo.bar.baz' )">{{ getButtonTitle() }}</button>
That would intuitively communicate that one is on the instance (this) and one is a function returning a result. Just a suggestions.

You'd still have ambiguity of this between template data and ractive instance:

{{#each items}}
    <li on-click='this.set("selected", this.foo)'>what is this?</li>
{{/each}}

Which is why the controller method is implicitly on ractive. If we opened event methods up to chaining, it could allow you do this:

{{#each items}}
    <li on-click='get( "items" ).someMethod( this )'>what is this?</li>
{{/each}}

In other words give a bridge back from event handlers to data.

[matthew-dean]

Okay, well I think you've all indulged my rant which had no specific request, but you all gave a lot of good explanations, thank you.

@martypdx That would be a cool idea. I actually had this come up. I simplified my example, but I wanted to fire two methods for one click. I basically had to rewrite one method so it fired the other. A lot of this I run into because of the way I'm abstracting out Ractive creation. It's more of a generic loader, with both page data and template arbitrary for each page. That means that I end up putting more interaction logic into the template, rather than adding various bits to my ractiveloader file that may be needed for a particular page.

Anyway, I'll close this since @JonDum said similar issues have already been raised and are being discussed.

[Rich-Harris]

Referencing #1172 so I can find this issue again, should I ever need evidence that the proxy event syntax adds an unnecessary layer of confusion.

[matthew-dean]

One thing I don't know if I mentioned with this: I often find myself having to refactor my data structure because of the current approach for methods. That is, often my data has a natural "root" node that actual represents my data. But as soon as a want to add a function available to my templates, I end up moving the data down one level into a "root" or "data" or "top" node, or whatever I end up naming it, so that it's separate from functions. It's really weird that functions are inside data, especially when they're returned with get(). Not sure why you'd ever want to "get" a function, although I understand that just happens because they're stuffed within the data model.

[heavyk]

dude, you are the king of bringing old conversation a new wind... lol

[matthew-dean]

@heavyk YES.

Wait... is that good? lol

[matthew-dean]

Just to document to this thread in case someone comes back to it later, but I just came across the syntax in Vue.js that basically does what I'm describing (methods are separate from data, which seems saner):

http://vuejs.org/guide/index.html#Handle_User_Input

[Rich-Harris]

Methods are separate from data in Ractive (or, rather, data is separate from methods) – the only difference is that a Ractive component's methods aren't inside a methods object. Isn't this issue about reducing the number of places to put functions?

[matthew-dean]

Methods in templates? Don't those still have to be within the data object?

[Rich-Harris]

No, all of a component's methods are available to event handlers, like so:

<button on-click='set('foo', foo + 1)'>add 1 to foo ({{foo}})</button>

That goes for built-in methods as well as ones you specify within new Ractive or Ractive.extend: http://jsfiddle.net/0s0ek1zu/

Functions exist in data when they need to be accessible to expressions in templates, and Vue copies this behaviour:

var ractive = new Ractive({
  template: '{{double(foo)}}',
  data: {
    foo: 42,
    double: x => x * 2
  }
});

[matthew-dean]

@Rich-Harris Oh... Vue.js has good documentation, except that it weirdly says almost nothing about what you can use in mustache expressions. At least nothing I could easily find, so I didn't see that.

Regardless, the same thing I said before about having to insert functions into data to be available to expressions, and that often causing model refactoring still holds true. I'd still prefer that a data model only held data, and that adding a function wouldn't require fundamentally changing the data model.

[Rich-Harris]

Vue.js has good documentation

It really does. It does a lot of things right!

I'd still prefer that a data model only held data

Have you tried this trick? It gives you that separation and lets you share helpers efficiently between components.

var helpers = Ractive.prototype.data;

helpers.double = x => x * 2;
helpers.triple = x => x * 3;

var ractive = new Ractive({
  template: `
    <input type='number' value='{{foo}}'>
    <p>twice {{foo}} is {{double(foo)}}</p>
    <p>three times {{foo}} is {{triple(foo)}}</p>`,
  data: {
    foo: 1
  }
});

Ultimately, functions do need to be data (if you want to get all Zen about it, functions are data in this context) because they can change. For example if you're doing dataviz you might have xScale and yScale functions that convert values to x and y coordinates for plotting – those functions need to be replaced if the dimensions of the plot change. Another important distinction is that data functions have no side-effects (or ought not to), whereas a component's methods mostly do exist for their side-effects – it would be weird to have the two things, which do very different jobs but just happen to all be functions, jumbled up in the same place.

[matthew-dean]

Whaaaa? That's a cool trick. Although I guess in that case you're modifying the base prototype?

FYI - I've had some back-and-forth tweets with the Vue.js account on Twitter, and passed along your comment, and the response was, "No, Vue.js doesn't work that way." (Re: functions being on data.) They are indeed attached to the "methods" property, which seems very intuitive. So I'm not sure about the idea that a) functions do need to be data, or b) they should be data. Data is what I serialize and send to my database, and when I update my model, data is what I send from the backend and update the front end. None of that includes functions. Data consists of integers, objects, arrays, and strings. Databases do not house functions (typically)

Even in how Ractive is using them, functions are not "data", since they "act" on data. Sure, they're required on the data property, but that doesn't make them data. The fact that they may be needed in the template context doesn't make them data either, even if they are called in a similar "context" to data.

Stepping back, even if, academically, you could somehow convince me of the argument that template functions should somehow be considered "data", regardless of how "data" is defined anywhere else, that still doesn't solve the fact that it's still terribly inconvenient to have functions on the data object, even with the particular hack you showed, or any other workaround hacks I've used. So, either way, this architecture feels wrong, both intuitively in terms of what data is, and practically, in terms of setting up a Ractive object. It still seems like the wrong approach.

[matthew-dean]

As a library dev, I know the worst can be, "But x does this better; can't you do x?" So I'm trying to avoid saying that, and just approach the feature on Ractive's terms. Having used Ractive quite a bit by now, function/method declaration & usage still trips me up.

[Madgvox]

One of the nice things about Ractive is how hackable it is. It's relatively trivial to extend ractive to implement this behavior yourself: https://jsfiddle.net/aeddLb44/

That said, I think that "you can do it yourself" isn't really an excuse. I certainly think there's merit in the idea of at least cosmetically separating methods from data. Internally, it could do a slightly fancier version of the snippet I made above, but no great shifts in functionality need take place. I think the question is more whether ractive should inherently include the option, or if we leave it as an optional snippet you can implement yourself if you so desire.

[Rich-Harris]

Although I guess in that case you're modifying the base prototype?

Yes, though you can also add helpers to a specific component class, and each instance of that component gets access to the helpers without needing to faff around with anything non-serialisable: http://jsfiddle.net/1x4uLnmy/

They are indeed attached to the "methods" property, which seems very intuitive.

My mistake – turns out properties of data are wrapped in accessors, and properties of methods are bound to the instance (whereas Ractive's sit on the component prototype), and the resulting instance is a mixture of both (data silently overrides methods in case of conflicts). So you can in fact do either, though functions are only updateable (in cases like xScale) if they live on data.

Both approaches have their merits. One advantage you do get from treating functions as data in Ractive is that they propagate, so non-isolated components can use helpers defined on parents – so this works, but this doesn't. (For simple expressions you can solve this with Vue.filter, but you need a different syntax.)

So I'm trying to avoid saying that, and just approach the feature on Ractive's terms

It's cool, I know it comes from the right place! I am sympathetic to what you're saying – really. I'm just not sure how to address the aesthetic concerns without breaking other things (like being able to update functions dynamically), other than mixing data and instance methods together in the same place when it's time to retrieve references, which seems like fertile ground for confusion.

Here's where I think we disagree: your view (correct me if I'm putting the wrong words in your mouth) is that the important distinction is between data (strings and arrays and objects) and things that act on data. One on side you have things that can be represented as JSON, and things that can't. It is, I agree, a very natural-looking distinction.

But I think the distinction between things that determine what gets rendered (data including functions) and things that determine how the instance behaves (methods) is more important. If we were being all MVC about it, the M is data-including-functions, the V is the template, and the C is the methods. You call a method when you want something to happen.

After all, the fact that some things are functions and some aren't is neither here nor there – you could have {{str.toUpperCase()}} or {{date.getHours()}} in a template and you'd be calling a function! And if you wanted to use Lodash methods in your template, where would you put them? With either Vue or Ractive you would have to put _ on data (or Ractive.prototype.data or whatever).

So to me, the question isn't 'what is this thing?' (function or not-function), it's 'what is this thing for?'.

Side-note: I find the easiest way to keep data from the server separate from helpers is simply to have top-level properties, so I do ractive.set('user', ajaxResponse) rather than ractive.set(ajaxResponse).

Sorry, that turned into a very long response. Hope it at least sheds some light on my way of thinking about it, even if it doesn't totally convince you – would be interested to know what anyone else out there following this thread thinks.

@Madgvox

One of the nice things about Ractive is how hackable it is. It's relatively trivial to extend ractive to implement this behavior yourself: https://jsfiddle.net/aeddLb44/

Ha! I never thought of that. That's pretty cool.

[fskreuz]

Just throwing this in, there were several discussions related to the stuff mentioned above (was to comment this morning but ehh... I thought it would be opened up by the others).

• Events hash like Backbone #1458 (Proposing a DOM event handling hash)
• Functions outside data #956 (has @Rich-Harris 's favorite helper prototype hack)
• define event handlers in Ractive.extend() #360 (a central events hash)
• actually, there's more linked to the above one way or the other

By the way, it also reminds me of other frameworks:

• Ember actions
• Meteor helpers and events
• Backbone (mentioned in one above)

But before anything else, the issue above seems like the job of a computed property.