-
-
Notifications
You must be signed in to change notification settings - Fork 109
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
autocomplete constructor is not dealing with reactive variables properly #30
Comments
also, I have two autocomplete inputs on the same page. |
What do you mean by 'init is not called'? What init are you referring to? I think the issue is caused by the fact that you are passing a reactive value Could you create a demo app so that I can debug this? Just factor out the part with the autocomplete and provide some way of changing the user value. Meanwhile you can test it or use as a workaround without If that's not the problem, then I don't understand what the following means; could you explain it more concisely?
|
Thanks a lot. I am referring to the init function in template.coffee that gets hooked up to the render callback. # Set nodes on render
init = ->
console.log('AutoComplete inited'); // I added this
@data.ac.element = @firstNode
@data.ac.$element = $(@firstNode)
@data.ac.tmplInst = this
Template.inputAutocomplete.rendered = init
Template.textareaAutocomplete.rendered = init the inputAutocomplete template is nor rendered the second time. I have the editor bound to a reactive datasource. After I insert the record, meteor keeps the client local value. Everything gets hooked up. After mongo accepts the value, it pushes the server copy of the record back to the client and tries to re-create the autocompletes, but the render never gets called. Thanks a lot. Kyle |
The render is only called once in Blaze (meteor/meteor#2001 and meteor/meteor#2010). We don't have a good way to deal with reactive updates to data passed to the I recommend you take reactive variables out of the autocomplete instantiation for now, until Meteor resolves some issues that allow us to use them properly in UI components. P.S. Please fence in your code blocks as I have done for you. Makes things much easier to read. |
I refactored to handle the db insertion asynchronously and only put the record into edit mode after the callback was invoked. That took care of it. Thanks. One minor suggestion to allow better reuse of functions. please pass the rule along with the doc when invoking the rule callback: rule.callback?(doc, rule) # Notify that the item has been selected |
I'm going to keep this issue open so that we can see if other users have issues passing reactive variables to autocomplete and to keep it on the list of things to fix. |
and also the element for context. That is fine -- your issues ;-). |
Mind putting the callback suggestion in a separate issue? It's going to get lost in this thread for sure. |
will do |
It seems that if you just change the data-context AutoComplete is in, it causes autocomplete to stop working. |
Yep, we don't support dynamic changes to data contexts right now. Hopefully this will be fixed with updates to Blaze. In the meantime, mind letting me know what you're changing in the data context? |
I'm not actually using the data for anything in the autocomplete. {{#with object}}
<input type="text" name="utilityType"/>
<input type="date" name="expDate"/>
{{> selectUtilitySuppliers}} <!-- this is the template with the autocomplete form field -->
{{/with}} So, on the 'change' events, I update the data instead of having save buttons that both dismiss the form and save all the form fields at once. |
@Neobii, can you show the contents of the https://meteor.hackpad.com/Blaze-Proposals-for-v0.2-hsd54WPJmDV is tracking API changes that may be able to help us resolve this problem, whatever its cause. |
It doesn't have that error, but I'm going to try to pass in the data context in the helper like |
So, that doesn't work, the only thing that happens is the autocomplete template doesn't show up. I'll make a reproduction for you. |
@Neobii and @KyleDFulton, the latest commit c79402f gives a workaround for this until the new Blaze Component API is released. Can you try it with your app and let me know if the errors persist? |
Although this is fixed in 0.4.4, I'm keeping this issue open so we can have a better long term solution that doesn't involve re-rendering. However, it doesn't even appear that things are really "re-rendering" in Blaze. For example, the contents of the input are preserved even in the example app given in #35 across a re-render. |
@Neobii and @KyleDFulton: This issue is fixed on the Please give it a try and feel free to comment in this thread if there are still issues. |
Likely, this is not an autocomplete issue, but more of a question. Using meteor 0.8.0 and autocomplete 0.3.0, I am running into a strange situation where my autocomplete gets constructed on spacebars more times then init gets called. Deps is firing my spacebars template multiple times -- the last time, the render is not called on the most recently constructed autocomplete objects, leaving the autocomplete empty.
There are no errors. It does appear to be a race condition... If I put a breakpoint in the defs.js file within the meteor packages on the 'pendingComputations.push(this);' line, the second set of constructors are not invoked and the previously constructed and initialized/rendered autocomplete inputs are hooked up.
Does anyone have any idea about what could cause this behavior?
template use below:
user settings below:
Thanks,
Kyle
The text was updated successfully, but these errors were encountered: