X-editable and meteor: inline editing full working example?


Hello all,
I am new to meteor and I need some help with the x-editable port to meteor.
I added the following packages:

In my HTML I use

<template name="categoryValue">
        {{> xEditable type="text" success=onSuccess placement="right" }}
How can I attach the editing functionality to my ```{{name}}``` field? I have not been able to find a full working (simple) example in meteor. Am I using the right packages? Thanks a lot in advance for your help, I am open to any advice! Cheers, zxxz



the package I use is babrahams:editable-text, its’s really easy to implement:

{{> editableText collection="users" field="profile.address" placeholder="Address" inputClass="form-control" afterUpdate="updateOwnerLoc"}}

Hope it helps!


@dancering thank you very much! I tried immediately and indeed it’s easy to use…although it’s limited to text/text area fields :smile:
Unfortunately I need support also for select fields (dropdown) and inline editing form (ok/cancel). Pretty much what http://vitalets.github.io/x-editable/ supports.
Do you have any experience with the x-editable port to meteor?


Probably you have to check this one:

Meteor editable package

I think could be useful as you ask for.


I followed your advice but that package seems a bit bugged: I am also experiencing the issues reported on github but nobody provided fixes…I am not sure whether this package is still maintained.

I will continue testing the 8 packages found in atmosphere searching for x-editable…I hope I will have some luck! It’s a bit disappointing knowing that x-editable itself works like a charm…


It’s a bit dated and I haven’t seen what the packages are doing these days but I think this might help you:

See Andrew’s answer and my answer.


@gadicc Thank you for your link, I will check it out right away :wink:

In the meantime I tried https://atmospherejs.com/risul/bootstrap-x-editable and I came up with a solution that works.
What I needed to do is: use an edit link to show/hide the inline editing form, and save the collection after a modification.

I report here the code I wrote, in case it might be useful to someone else. I am not sure this is proper meteor coding (I am an old school Java developer…so I struggle with JavaScript :frowning: ). Comments are more than welcome!


<template name="categories">
    <table class="table table-striped table-hover ">
            <th class="col-md-1">&nbsp;</th>
        {{#each categories}}
            {{> category}}
<template name="category">
            <p id="text" class="editable" data-type="text" pk={{_id}}>{{name}}</p>
            <span class="pull-right">
            <a href="#" class="edit"><i class="fa fa-pencil fa-lg"></i></a>
            <a href="{{pathFor 'categoryValues'}}"><i class="fa fa-list-ul fa-lg"></i></a>


    categories: function() {
        return Categories.find();
    'click .edit': function(event, template) {
Template.category.onRendered(function() {
    var self = this;
        success: function(response, newValue) {
            Categories.update(self.data._id, {$set: {name: newValue}});

A bug in this solution is that while confirming a change, the on success runs and the collection is updated but the editable field stays in an unsaved state and the edited text is displayed twice…I will update the code here if I find a solution soon…

I personally found hard to get that you have to access the context through the parameter template for events, while the context is this in onRendered.
What took me a fair share of debugging was the fact that the context fields are accessible through [template|this].data.field, and not directly (I missed the .data part, but the official documentation saved me :slight_smile: ). It feels like a bunch of examples on the net use some kind of old syntax, or I cannot read anymore (both are very well possible).


Yeah, there was a big change before Meteor 0.8 (with the “Spark” rendering engine) and after (the “Blaze” engine). The latter is much faster / efficient, at the trade off of no longer supporting some older (and non-efficient) patterns. But with a good understanding of the engine, you can work around almost anything, as was shown in the SO thread (I’m pretty sure we solved the problem you mention but I admit I haven’t touched x-editable since my contribution there).

Re the API, yes, it’s a bit confusing, as new parts of Meteor came out with different requirements… the API could either be inconsistent, or all old code could be instantly broken. MDG went with the former, but now that we’ve been using all the different parts for some time now, we have a good idea of exactly what we need, and the next version of Blaze is planned to have the same API everywhere (particularly the use of this in life cycle callbacks, events, helpers, etc).


@gadicc Thanks for your feedback. I am so fascinated by Meteor that I can live with those hiccups…especially knowing that there is such a great community!
If I stick with x-editable, I will most likely fork the project and try to extend it with what I need…hoping that it might be useful to someone else.