I do “get it properly” and understand that we don’t do our subs in the routing later, hence we’ve no data in this layer to do auth checks. Doing auth checks at the template level sounds a little more attractive when we start thinking about components.
1 Like
Yes, I’m well aware that there’s separate packages for this, I just don’t think it was clearly explained to the community why they weren’t combined, or I missed a blog post.
1 Like
Awesome, I was worried that we’d only get SSR if using React.
1 Like
One thing I did notice is a flash of the {{else}} content until my user is logged in client side.
If I refresh the page, I see the “welcome” area for a split second until my user is logged in automatically.
Any ideas around this?
<template name="layout">
{{#if currentUser}}
{{> sAlert}}
<div class="container-fluid">
<div class="row">
<div class="col-sm-2 col-md-2 sidebar">
{{> Template.dynamic template=sidebar}}
</div>
<div class="col-sm-10 col-sm-offset-2 col-md-10 col-md-offset-2 main">
{{> Template.dynamic template=content}}
</div>
</div>
</div>
{{else}}
{{> welcomePage}}
{{/if}}
</template>
It’s because your subscriptions aren’t loaded yet.
1 Like
How can I check if subscriptions have loaded in my Template?
{{#if Template.subscriptionsReady}}
4 Likes
flow router level subs this way in helper
FlowRouter.subsReady("currentCategory")
For template level there is premade generic helper
{{ #if Template.subscriptionsReady }}
And you can always use your own helper to monitor it, for example we have this on onCreated
var this.contentSub = this.subscribe("categoryProducts", this.slug);
And than helper
isContentReady: function(){
Template.instance().contentSub.ready();
}
Mby I have something wrong in that code, I was dumbing it down for example purposes and translating from coffee.
1 Like
FWIW you should do subscriptions in the template
So am I correct in assuming that in my template or layout I should first get the user data, do an auth check - if fails, redirect, if successful then subscribe to the data the page needs? Makes sense.
Correct. You don’t need to redirect at all.
Just show the login form.
Once you user logs in back, no need to do anything. He can just use the app.
No need to mess around with the redirectUrl kind of thing when user logged in.
2 Likes
Yeah the worst thing is when an app doesn’t take you to the right place after logging in, it’s much easier to just avoid the whole problem by not redirecting.
2 Likes
Of course, usually in other apps I’ve written with traditional server side frameworks, after login I’d redirect the user back to their intended page. The reason I suggested redirects at all was simply to ensure the url always reflects the current state eg. If the user needs to login and we’re going to show a login form, then I’d assume the url should reflect that. I think there’s valid arguments for both sides in this scenario.
Though thinking about it now, I guess we could treat login via a route param as opposed to a /login route.
1 Like
A url is a shareable and immutable representation of app state. Following this logic,
Auth status is not a part of shareable app state,
Even if it were, it would not be something you’d want to expose. Imagine you distinguish between such states like /posts/whenLoggedin vs /posts/whenLoggedout since you won’t directly show contents of /posts/whenLoggedin without actually checking auth, auth state in url just does not make sense
Also, a url like /login still does not make sense. Why would any one actually want to share the login link to an app? They would need to share it in a typical request response app because that’s where any other protected link would have to redirect anyway.
But what if you could avoid that whole “redirect to login, in the meantime keep a reference to the previously requested url, then redirect the user to that url once auth completes” crap that we had to eat all these years? It turns out, we actually can avoid it.
I find route based auth to be a case of stockholm syndrome where we should break our mental/emotional chains and see it for what it is, a workaround to a problem that we could not solve more elegantly until template/layout based auth 
7 Likes
Thanks for laying this out there, I hadn’t thought about the whole auth flow in this way before, but it makes a lot of sense!
1 Like
Apollo rockets were meant to be used once and discarded… Is that how you build apps? Not sure the correlation to routing. Routing is a very important part of an app, if you build a large app… you’ll want to make sure routing is standard well documented maintained and updated part of your code… not an unmaintained section that may or may not work in a few months. I really enjoyed working with Iron Router… that’s why it upsets me it’s no longer maintained. Not sure about you’re argument on this.
1 Like
To me, this is one of the last things that needs to be focused on. As others above have said, there exist wonderful community solutions built by motivated and talented people. Instead, we could have a wonderful official solution built by motivated and talented people.
It doesn’t surprise me that IR is going out of business, if the rumors are true. I think the creators started to realize that FR had the better approach. Instead of abandoning their project, they could divert their traffic to FR, officially deprecate IR, and join forces with @arunoda. Or maybe they got busy in other aspects of life.
For those that are using IR, you pretty much already know how to use FR, but it could take several hours to convert your app depending on how big it is. This is because your app is most likely structured entirely differently if you use IR, and made use of its many features.
I look forward to innovation in routing. Perhaps you take my metaphor too literally. We’ve had apps in production since Meteor 0.6 and iron router hasn’t stopped working.
My point is only this: don’t let better be the enemy of the good enough. Some people are hesitant to build something with Meteor because they feel routing is “too important” to be entrusted to a third-party package and should be part of the core. In my experiencing iron-router has ‘landed us on the moon’ (our Meteor app has generated over $1M in revenue for us), so don’t let lack of technical perfection stop you from creating something of value and getting traction in the near-term.
10 Likes
I also had an HTTP request->response mentality when I started building a meteor application. Then I got punched in the face and got better
You as a developer may not need routing to make your app working fine. Me as a customer/user expect routing in your app, so I can get an inside link and share it with people or put it in my bookmarks or even pinned tab (except for tiny amount of apps where there’s nothing to link anyways, but they’re far from being a majority of single page apps).
Punching user in the face, even hitting his knee with an arrow won’t make him think that he doesn’t need what he does.
1 Like