meteor-x-editable-bootstrap
meteor-x-editable-bootstrap copied to clipboard
Edited/updated values getting double-populated on DOM/template after editing.
I've noticed that for an example editable text field, if I edit the value and in the success
attribute I do a Meteor collection update with the newValue
the value gets double populated into the Meteor template. For example, if have a documentTitle
field set to Noodle Recipe and I update its value to Spicy Noodle Reciple after the update the Meteor template will show Spicy Noodle RecipeSpicy Noodle Recipe. I assume this is because x-editable and Meteor are both updating the DOM behind the scenes. x-editable does it after a successful edit and Meteor does it once it sees the value update in Mongo. To fix this I had to add data-display="false"
to all my x-editable fields to disable x-editable's updating.
It might be good if this was built in and/or at least mentioned in the docs.
@evolross I was having the same problem. I ended up implementing a probably wrong but temporary solution that removes the duplication. Do a return " "
after the update of the collection.
Col.update(id,{$set:{foo:foo}});
return " ";
Your way may be better, as adding data-display="false"
makes the DOM wait on the server to do the update and for Meteor to update the DOM, so there's a slight delay in seeing the value change. Nice to know there's options. Thanks.
I tried the return " "
at the very end of my success:
function after any updating happens and the field just turns red like it's failing validation. Which it shouldn't because I didn't change the validate:
code at all. Are you putting your return " "
at the end of the success:
function?
Also if this works I think you're doing the same thing I'm doing, which just eliminates x-editable from updating the value and waits on the server/Meteor to update the value... which on a slow server could make for a bad UI experience.
@evolross yeah I also noticed what you are saying. I agree data-display="false"
is a better solution. It would be a good idea to eventually fix it in the package. I would leave this issue open.
I posted a solution to this at http://stackoverflow.com/a/23144211/586086, mainly cause it also causes a sync error between the field value and the editable value. It's also linked from the main README.
I am seeing this same behavior, but can confirm that the data-display="false" fixes it.
@bryankennedy that only fixes some of it. You'll still notice irregularities if you are editing a field while its value changes; check out the SO link I posted above.
Mizzao do you have a solution that does not use CoffeeScript? I couldn't make it work.
The return " "; does not work as the field is not validated.
The data-display="false" method has another problem: If the field is empty, then nothing is shown (instead of the placeholder).
I'm also having this problem, and just ran into the issue @fercook is having.
This is a hokey work around in Meteor's Spacebars template language.
Example I'm working with, where I'm trying to check if the standard_name is Empty. If it is, then set data-display="true" so the Empty field shows up for editing.
<a data-name="{{long_name}}" href="#" data-type="text" data-display="{{#if standard_name}}false{{else}}true{{/if}}" data-title="Enter a standard name">{{standard_name}}</a>