Cannot read property 'form' of undefined

[zachdixon]

I'm trying to set up the useraccounts:bootstrap package and I'm getting this error. I'm sure it's probably because I'm not configuring something correctly or not including some package.

I have:
service-configuration
useraccounts:bootstrap
accounts-password
accounts-facebook
accounts-google

When I do something like {{> atForm state="signUp"}} then it works, but breaks again any time I click on something in the form

Also, the normal form with username/password/etc isn't showing up, which I'm guessing might have to do with it? The facebook and google buttons show up and show up as configured since I did the ServiceConfiguration stuff.

Any ideas?

[zachdixon]

So I think I figured out the problem. I've read through the docs probably 20 times but couldn't figure it out until I went to this example and copied the config. After looking through here, I'm guessing the line I was missing was AccountsTemplates.init(). Unless I'm mistaken, this wasn't mentioned in the docs?

Great package though, loving the customization and I'm putting it into a modal which I couldn't do with the default accounts-ui. Thanks a ton!

[splendido]

Hey @zachdixon,
I've just realized I already changed the docs for or the new upcoming version which I was to release a couple of days ago.
Then I decided to wait until I get another couple of things done, but you're making me notice that was a really bad choice!

I'm really sorry, I'm going to release it today.

Good you managed to initiate it!
...don't forget to remove .init () with the new version ;-)

Please let me know if you have any other questions!

[zachdixon]

No worries, thanks for getting back to me. So just making sure, the docs are for the updated release and once I update my package, I won't need the init() anymore, correct?

Also, I'm wondering if there is a way to turn off the redirect after a valid form submission from sign in/up? I have the forms in a modal and just need it to stay on the current page.

[splendido]

Yes, docs are for the (now) current release (1.2.1)!
And no more need to call .init()

...for the redirect there's something I use internally, but could be the way to go for your use case.

AccountsTemplates.avoidRedirect is used at this line to select whether to redirect or not...
I use it in conjunction with ensureSignedIn to keep the user on the same page after the login on a protected page.

The long story short: set

AccountsTemplates.avoidRedirect = true;

every time you open your modals.

I more than sure that this should work!

Let me know

[splendido]

...in case it works, it would be very useful if you could share your setup.
I'd like to start collecting some good examples about how to do some particular things, and your case seems a good one!

Tnx again

[zachdixon]

Perfect, that worked, thanks!

So in my particular setup, I have a modal template that watches a session variable 'currentModal' and renders when it exists. I can pass in a number of dynamic templates to render into the modal (just to make it reusable). So all I do is set my 'currentModal' session to an object that renders the atForm template. From there, your package takes care of the rest, no routes or anything which is nice.

I'm doing it this way since a user can see every page of my app, but can only use certain parts without being signed in (this way they see what features they're missing out on). So when they sign in/register, I don't want it redirect, since Meteor is awesome and just updates everything based on the currentuser.

I plan on launching my app in the upcoming weeks and I can let you know when I do so you can put it on your example list if you want :)

[splendido]

You'll say I'm curious...
How do you hide the modal after successful atForm submission?
Simply checking Meteor.user()?

...I'll wait for your launch!
Fingers crossed ;-)

[bobmonsour]

Luca, I just updated and tripped over the removal of AccountsTemplates.init(). Since it was a "breaking" change, it's something you might want to highlight in the docs. It threw an error since I still had it, but was surprised by the error. Fortunately, I watch this repo and see the conversations, but I had skimmed over the references to init. But when I got the error, I came back to find it in this thread. I guess it worked out as it should, but I'm not sure others will be so lucky, particularly if they're using the package, but not watching the repo. Food for thought...mangare!

[splendido]

Hi Bob, I'm sorry for it.
I agree it should be made as clear as possible.
I put it on the History.md file, but I'm going to add a breaking change now to get it even clearer.

What would you suggest for those who are not looking a the repo?
keeping a fake init method which warns them it's no more necessary and should be removed?
...perhaps this is the best option
Thoughts?

[splendido]

I'm closing this, since it's solved, but I'll wait for your answer ;-)

[bobmonsour]

Hi Luca, no worries. I'm not sure what the right way is to handle this kind of situation. I'm pretty new to open source development. I just took a look at the history.md and see it there. It's the first time I've ever looked there. The way I think about it is that you need to decide how backward compatible you'll be from release to release. Perhaps you want to set it up, sort of like Meteor, where changes from .1 to .2 do not break anything, but changes from 1. to 2. can break things. I don't know what's typical, but it has me wanting to lock down which version of useraccounts I deploy with so that I know it's one that I have tested my app with. I hope that's helpful.

[splendido]

Yes, you're right!
This was a 'backward incompatible' change and should have been shipped with a major release: see semver.
I'll add it back with just a warning to warn people about this minor change.

In any case locking the version is a good idea I guess, just to prevent unwanted updates of the package.
...at least until we'll have a proper testing environment set up. :(

Thanks as usual for the precious feedback!

[splendido]

patch release v1.2.3 with backward compatibility restored!

[zachdixon]

@splendido , sounds like a good fix to the issue. As for your question, yes I'm watching Meteor.user() in a Tracker.autorun and setting the Session 'currentModal' to undefined. Anytime I set that session var, it pops open the modal. So far this seems like a pretty good fit for my needs, haven't run into any issues yet. Much better than calling a modal init etc. every time :)