These are chat archives for reactioncommerce/reaction

10th
Feb 2015
lovetostrike
@lovetostrike
Feb 10 2015 02:05
@aaronjudd is there any undesired effect to add ReactionCore.Subscriptions.shops?
Aaron Judd
@aaronjudd
Feb 10 2015 02:42
@lovetostrike it’s already always subscribed in the routing.coffee, ShopController
lovetostrike
@lovetostrike
Feb 10 2015 02:44
yes, but what if I want the ready() function of the handle?
The problem I was facing is that Shops db isn't ready when I was pulling social url for the footer
Aaron Judd
@aaronjudd
Feb 10 2015 02:46
ah, should be ok
you’re putting in the template script for footer? is that at the app level? or in core?
lovetostrike
@lovetostrike
Feb 10 2015 02:47
sounds good, thanks :)
oh
I'm checking {{#if urlReady }} in the template
and in the footer.coffee, urlReady return ReactionCore.Subscriptions.shops.ready()
Aaron Judd
@aaronjudd
Feb 10 2015 02:48
should be ok, in either case, but I was thinking that all templates loaded from core should have the shops subscription, but that might not be true at the app level
lovetostrike
@lovetostrike
Feb 10 2015 02:49
the app footer is replacing the core footer
Aaron Judd
@aaronjudd
Feb 10 2015 02:49
yeah, ok, that makes sense then
lovetostrike
@lovetostrike
Feb 10 2015 02:49
cool
Juan David Pastas
@juanpastas
Feb 10 2015 19:47
@aaronjudd thanks.
Bogi
@boboci9
Feb 10 2015 19:54
I was experimenting with the address forms, did it ever happen that the values from the address were not correctly displayed for the region, postal etc? For me it happens only sometimes and I am trying to debug were is it going wrong but I can't seem to figure it out. What I noticed is that instead of {{>afFieldInput name="postal" value=defaultPostal}} is I use {{>afFieldInput name="postal" defaultValue=defaultPostal value=postal}} I always get the correct value which seems correct but then how is the initial version also working sometimes?
Aaron Judd
@aaronjudd
Feb 10 2015 19:55
you’re referring to the auto-population of those values?
or just generally, when loading an existing address, those fields aren’t populated?
Bogi
@boboci9
Feb 10 2015 19:57
yes I am, in add form the default values should appear while in edit the values from the address
when I load an existing address 3 fields are not populated: postal city and reagion while the rest are
Aaron Judd
@aaronjudd
Feb 10 2015 20:04
just looked into it, yes, it looks like there is a bug there. defaultPostal,etc should check if there is already a value (right now it’s overriding with locale)
should be “return value if there is one, return null if edit, return locale if new"
Bogi
@boboci9
Feb 10 2015 20:07
but it is not doing it all the times, sometimes it is working correctly but I can't figure out how
Aaron Judd
@aaronjudd
Feb 10 2015 20:08
change it to something that is not your locale. then it will show the locale, and not your actual entry
I added an item to #315 for this
Bogi
@boboci9
Feb 10 2015 20:09
yes but also my solution is not working for the country if I add {{>afFieldInput name="country" options=countryOptions defaultValue=defaultCountry value=country}} it will always add the country from the locale
Aaron Judd
@aaronjudd
Feb 10 2015 20:29
I see what you are seeing, I have to dig into it a bit more, I’m thinking.. the defaultValues logic there should be applied tothisAddress, removing defaultValue, value, and the helpers
I’m thinking that’s what @aldeed is suggesting here: aldeed/meteor-autoform#490
Bogi
@boboci9
Feb 10 2015 20:31
yes that is a good point, I will see if I can do that for you, but I also get an issue when I am trying to save, sometimes the edit form works perfectly sometimes my server method gets called twice and once with the correct values, and once with the initial values that were in the form and it resets the values
Aaron Judd
@aaronjudd
Feb 10 2015 20:34
I’d probably change that logic as well now (I’m seeing code that was written, well, when things worked a bit differently) - I’d use the autoform meteormethod=“addressBookUpdate" and type=“method” approach now
and remove the meteor.call from the submit event
Bogi
@boboci9
Feb 10 2015 20:35
there is a comment in the edit.coffee regarding this # TODO: This should be handled by autoform, but something# is not triggering js on the rendered template # this approach works for now, but not optimal
Aaron Judd
@aaronjudd
Feb 10 2015 20:36
guess it doesn’t work anymore lol
Bogi
@boboci9
Feb 10 2015 20:36
:) I will make some research see if the meteormethod and type=method would fix the issue
Aaron Judd
@aaronjudd
Feb 10 2015 20:36
I didn’t even see that comment, just was looking directly at the code (code blinders)
Bogi
@boboci9
Feb 10 2015 20:55
for me it is working now if I just take out the whole 'submit #addressBookEditForm': (event,template) -> lines 18-29