Don't hardly depend on iron:router - Flow Router Integration

[ghost]

I'd like to use the useraccounts package with the flow-router. Right now it's not possible to get rid of iron:router when using the useraccounts package because of the hard dependency on it.

My suggested solutions to fix this are either:

1. Make iron:router specific features optional. They are only available when the app uses iron:router. This can be achieved by making the dependency to iron:router weak and check the existence of Package['iron:router'] for the iron:router specific parts.
2. Use polymorphism to support multiple routers. Create a common router interface object that will delegate the execution to the router that is included in the app. This would be iron:router, meteorhacks:flow-router or a "no router" implementation.

[splendido]

Time to give feedback guys!

After almost three months playing around with the flow-router-integration branch,

• what do you think of it?
• is there anything you'd change?
• is there anything missing?

Unfortunately I had no chance to give it a try, nor I started to look at flow-router, but I'm sure you can make a very good review!

...I also guess @arunoda would be happy to hear about any addition we might expect form flow-router to get fully up and running! :-)

At this point we might start moving the more general parts about route configuration to useraccounts:flow-routing

[dandv]

I'm building a referral system with user-accounts and flow-router, so I'll be happy to give feedback within a week or so.

[splendido]

good to know @dandv, happy coding then!

[PhilippSpo]

@arunoda Is there a way, that a trigger can prevent the action from being executed? If not how are you supposed to do this? Because at the moment, the ensureSignedIn trigger cant render a signIn template instead of the original content, because of this.

Triggers are very similar to middlewares, but triggers don't have a next() argument. So, you've no way to block or wait the route.

[arunoda]

Yes it is. That's an issue. We are working on a way to that. Basically, we allow you to redirect within the trigger. It'll land in few days.

On Mon, Jun 15, 2015 at 1:20 AM Philipp Sporrer notifications@github.com wrote:

@arunoda https://github.com/arunoda Is there a way, that a trigger can prevent the action from being executed? If not how are you supposed to do this? Because at the moment, the ensureSignedIn trigger cant render a signIn template instead of the original content, because of this.

Triggers are very similar to middlewares, but triggers don't have a next() argument. So, you've no way to block or wait the route.

— Reply to this email directly or view it on GitHub https://github.com/meteor-useraccounts/core/issues/308#issuecomment-111870229 .

[PhilippSpo]

ok thanks for the info

[PhilippSpo]

@arunoda the desired behavior of useraccounts is, that once you visit a route that you are only allowed to see if logged in, then you should NOT get redirected to /sing-in BUT stay on the same route and see the signUp Template/Layout rendered and not the original content. With middlewares if you do not call the next() function (in the middleware) but call FlowLayout.render(...) you could achieve that. I don't see that working with triggers though. What is your take on that?

[arunoda]

If this is the case, then it's very easy. Just do it in the template level. I am quite not sure how to do it.

If this is the case, I believe you don't need to depend on the router at all. On 2015 ජූනි 22, සඳුදා at ප.ව. 7.24 Philipp Sporrer < notifications@github.com> wrote:

@arunoda https://github.com/arunoda the desired behavior of useraccounts is, that once you visit a route that you are only allowed to see if logged in, then you should NOT get redirected to /sing-in BUT stay on the same route and see the signUp Template/Layout rendered and not the original content. With middlewares if you do not call the next() function (in the middleware) but call FlowLayout.render(...) you could achieve that. I don't see that working with triggers though. What is your take on that?

— Reply to this email directly or view it on GitHub https://github.com/meteor-useraccounts/core/issues/308#issuecomment-114111488 .

[tjmonsi]

Hi guys,

Any timeline on when useraccounts be a full-fledged package for flow-router? I'm going to test this out though in my prototype though in the next few weeks along with Materialize...

[PhilippSpo]

@DenisGorbachev already has one open pull request that will get things working with FlowRouter v1.16.1. It will be fully functional if middlewares are not fully deprecated in 2.0 also. If you don't mind using submodules in your git repo than you can use that today. @splendido is on vacation, so it might take a week or two until we see more regarding useraccounts 2.0...

[DenisGorbachev]

@tjmonsi it's the https://github.com/DenisGorbachev/meteor-useraccounts-core, and using submodules is pretty simple with latest git, so feel free to give it a go :)

[tjmonsi]

@PhilippSpo @DenisGorbachev Do i still need to do this? https://github.com/meteor-useraccounts/core/blob/master/Guide.md#flow-router-integration

Or should i just use this and just create my custom routes in flow-router? https://github.com/meteor-useraccounts/core/blob/master/Guide.md#templates

[DenisGorbachev]

@tjmonsi Yes, you need to do this, too. By the way, if you use the fork, then it's better to also use fork's documentation: https://github.com/DenisGorbachev/meteor-useraccounts-core/blob/flow-router-integration/Guide.md

[tjmonsi]

@DenisGorbachev after much re-reading... I now get the flow :P So that means I'll just git clone your copy, add useraccounts:materialize (i'm using that one), and then just use it for flow-router. Would it have any problems on production stage? I'm seeing problems as told by @PhilippSpo... did you guys fixed the problem? I'm going to use @arunoda's MUPX on digital ocean and would like to get some headsup on what I need to do so it works perfectly

[DenisGorbachev]

@tjmonsi if it works on localhost, it'll work on another machine, too. After all, it's just a client-side router :)

[PhilippSpo]

@tjmonsi I am currently using it in a client project, hostet on digitalocean, deployed via MUP ;)

[tjmonsi]

@DenisGorbachev @PhilippSpo :+1: Thanks guys for the replies. Will try it out within this week and post here my findings (if it is working smoothly or... well... has bugs :stuck_out_tongue: )

[PhilippSpo]

:+1:

[charleshan]

The branch is working for me but I had some trouble with git submodule errors. Instead of cloning, I used this command to add submodule and pull the branch. Much easier for noobs like me :)

$ cd your/project/path
$ git submodule add --branch flow-router-integration https://github.com/meteor-useraccounts/core.git packages/core

[DenisGorbachev]

Actually, I do the same :)

On Fri, Jul 3, 2015 at 12:53 AM Charles Han notifications@github.com wrote:

The branch is working for me but I had some trouble with git submodule errors. Instead of cloning, I used this command to add submodule and pull the branch. Much easier for noobs like me :)

$ cd your/project/path $ git submodule add --branch flow-router-integration https://github.com/meteor-useraccounts/core.git packages/core

— Reply to this email directly or view it on GitHub https://github.com/meteor-useraccounts/core/issues/308#issuecomment-118178594 .

[jshimko]

Hey friends. Been a while since I've used this package with Flow Router and I just discovered that it needs a little attention after the recent FR 2.0 releases. Where do things stand with 2.0 integration? Is anyone working on it? What else needs to be done? I have some time this week and would be happy to try to knock it out. I just don't want to duplicate any effort if someone else is already working on it.

[abernix]

I attempted to use the flow-router-integration branch with the new kadira:flow-router release yesterday and ran into issues.

Aside from this package needing to have weak dependencies on either flow-router (meteorhacks vs kadira) package it also needs a few special wrappers for integrating with the new kadira:blaze-layout (of course, assuming the desire of backwards compatibility with flow-router pre-2.0). So, some wrappers, etc. are in order.

Additionally, this got into a general question of the status of the talks I read somewhere about making the 2.0 version of meteor-useraccounts:core router-agnostic. So that might be the place to start. IronRouter compatibility is probably still a must.

I spent a half-hour or so on it yesterday just trying to hack it together for my existing purposes but then had to move onto something else (sticking to my previous pre-kadira:flowrouter implementation for now). My proof-of-concept actually doesn't need a super functional user accounts system, so I just went with a accounts-ui-only approach for now, but I will need to revisit this in a few weeks.

FlowRouter API might be maturing very quickly at the moment to help make this integration easier too and I haven't had a chance to keep up with that. At first glances though... FlowRouter._askedToWait might be worth taking a look at, as well as maybe seeing what projects like zimme:active-route are doing.

I'll help where I can.

[jshimko]

I've gotten just about everything on the flow-router-integration branch working with FR 2.0 (except for ensureSignedIn). See my branch here. But I was also under the impression that things were getting broken out into separate packages, so I won't bother with a pull request to the core repo. However, I use AT on just about every Meteor app I build, so I'd be happy to work on getting the new routing packages up and running.

So what's the current state of things? Is anyone working on the v2 branch or the routing packages?

https://github.com/meteor-useraccounts/core/tree/v2.0 https://github.com/meteor-useraccounts/flow-routing https://github.com/meteor-useraccounts/iron-routing

[abernix]

Simple enough, and there's no reason it won't work like this. I'll test your branch later, but a quick look at your branch shows the bare-bones changes necessary to get it working. I went too far and tried doing the rest of this before I face-palmed and realized that I just feature-creeped the hell out of myself.

I think (getting back to the original issue in this issue/ticket), "Create a common router interface object" is the next task. Not sure how I feel about the "no-router" aspect of this project? I'm not entirely sure how this package would work without a router at all as that seems like a large amount of the value that it provides (versus just doing Meteor-core accounts-ui). Thoughts?

I personally don't feel that flow-routing and iron-routing packages are really necessary - this seems to make things more complicated than they need to be. We can easily detect which router is installed (Package[kadira:flow-router]) and simply make them weak dependencies. It should be possible to install this package with either router (and I guess, theoretically, no router, though again, I don't seen the value) and it should work fine.

I'm not sure where 2.0 stands right now, but I kind of feel like this needs to be done to the 1.0 branch?

[abernix]

And the discussions are continuing about authentication in FlowRouter (for fixing ensureSignedIn), but this is a popular choice, and not sure if this idea of an AuthManager is going to develop into anything or if it's just going to be a best-practice blog post.

[abernix]

I guess people render the forms directly into other templates and stuff, so maybe that would be the reason for the "no-router" approach? Not sure, as I've never done it this way before. I prefer to have routes for everything. Input appreciated on this part.

[splendido]

@abernix thanks gor your thought! I've been out for more than one months and I'm now trying to get back to the project especially on v2.0

I think you already figured out the reason for the "no-routing" philosopy, at least in base packages: the simplest scenario would be having a single sing-in/sign-up form on your landing page and this would require no particular routing stuff for useraccounts itself, it could be a {> uaForm} put somewhere within your home page and that's it.

At the same time it might get overcomplicated to figure out an interface which would be able to play nice with both IR and FR. Moreover, who knows about other possible new routing packages we'll have in the furute...

Honestly, I think something like:

meteor add useraccounts:oauth meteor add useraccounts:bootstrap meteor add useraccounts:flow-routing

is not too much complicated a sequence of commands to be run once at the begininng of a project ;-) and this way the code could be lighter and easier to maintain. I hope this makes sense.

[splendido]

I think @jshimko will come out with a PR soon to update the flow-router-integration branch so to have people able to continue on it.

...but the goal is now bringing v2.0 branch to a published alpha version or something!

[splendido]

...yep! See #490

[ghost]

The interface can be more abstract and specific to the user accounts package. The point is that each router integration implements the same methods. Adding a new router integration would be also easy this way.

[splendido]

yes I see what you mean @Sanjo. I guess the configuration API will be the same (as long as possible) for all routing packages, but the actual code will defenitely be different.

What I meant is I don't thinks it is wise to write a single configureRoute method (or whatever) which automatically detects the intsalled routing package and then try to use slightly different code based on the context...

[PhilippSpo]

@splendido I also think that it would/could get complicated really quickly, when trying to have one package for all routers. Of course it would be cool to automatically detect the router being used, but this job can easily be done by the developer using the useraccounts package. And in the end the difference between the approaches is just that the (routing specific) code is separated into some packages and the logic which router is being used goes to the developer..

[rclai]

I am with @PhilippSpo. After further thinking, I think this is what should happen:

useraccounts:core should only give us all the at<Feature> templates and any other user account configuration related functionality.

And all the iron:router configuration stuff and the Iron Router plugin should be taken out and put into a separate helper package like useraccounts:iron-router-helpers or useraccounts:iron-routing. It makes sense because of how iron:router works. It renders stuff.

And for the kicker, we don't need any Flow Router integration because of its non-template-rendering nature and the fact that it is NOT tied to Flow Layout (now Blaze Layout), React or any template engine. Like @arunoda said, "we don't need to depend on the router at all". All someone needs to do is something like:

// /client/lib/user-auth.js
FlowRouter.triggers.enter([function (context, redirect) {
  if (! Meteor.user()) {
    redirect('/sign-in');
  }
}]);

// Set up all the routes to the useraccounts templates manually
FlowRouter.route('/sign-in', {
  action: function () {
    // FlowLayout.render('layout', { main: 'atSignIn' });
    // BlazeLayout.render('layout', { main: 'atSignIn' });
    // React.render(<MeteorTemplate template=Template.atSignIn />, mountNode);
  }
});

Tracker.autorun(function () {
  // If for some reason we detect that the user was logged out
  if (! Meteor.user()) {
    // FlowLayout.render('layout', { main: 'atSignIn' });
    // BlazeLayout.render('layout', { main: 'atSignIn' });
    // React.render(<MeteorTemplate template=Template.atSignIn />, mountNode);
  }
});

So what I envision the ideal path to be is to take the iron:router stuff out and put it in a separate package. Any iron:router user will just need to install that package and everything should still work fine. Then any other person using Flow Router with whatever templating engine can take advantage of the atTemplates and now everyone's happy.

Let me know your thoughts. I would be glad to help if you guys are on board with this.

[tjmonsi]

I like the idea. Would it be already be useful with the current iteration of useraccounts?

On Tue, 4 Aug 2015 20:20 Richard Lai notifications@github.com wrote:

After further thinking, I think this is what should happen:

useraccounts:core should only give us all the at templates and any other user account configuration.

And all the iron:router configuration stuff and the Iron Router plugin should be taken out and put into a separate helper package like useraccounts:iron-router-helpers or useraccounts:iron-routing. It makes sense because of how iron:router works. It renders stuff.

And for the kicker, we don't need any Flow Router integration because of its non-template-rendering nature and the fact that it is NOT tied to Flow Layout, or Blaze Layout, or any template engine. Like @arunoda https://github.com/arunoda said https://github.com/meteor-useraccounts/core/issues/308#issuecomment-114137621, "we don't need to depend on the router at all". All someone needs to do is something like:

// /client/lib/user-auth.js FlowRouter.triggers.enter([function (context, redirect) { if (! Meteor.user()) { redirect('/sign-in'); } }]);

FlowRouter.route('/sign-in', { action: function () { // FlowLayout.render('layout', { main: 'atSignIn' }); // BlazeLayout.render('layout', { main: 'atSignIn' }); // React.render(, mountNode); } });

Tracker.autorun(function (c) { // If for some reason we detect that the user was logged out if (! c.firstRun && ! Meteor.user()) { // FlowLayout.render('layout', { main: 'atSignIn' }); // BlazeLayout.render('layout', { main: 'atSignIn' }); // React.render(, mountNode); } });

So what I envision the ideal path to be is to take the iron:router stuff out and put it in a separate package. Any iron:router user will just need to install that package. Then any other person using Flow Router with whatever templating engine can take advantage of the atTemplates and now everyone's happy.

Let me know your thoughts.

— Reply to this email directly or view it on GitHub https://github.com/meteor-useraccounts/core/issues/308#issuecomment-127581562 .

[abernix]

Ok, I can absolutely see different packages being a benefit for 2.0, and I break stuff up into packages internally - I fully understand the light-weight aspect of it. My only defense for keeping it in a single package is for easier on-boarding of new users. Auto-detection is always nice for new users, and I really don't know how many routers there are going to end up being. It's not out of the question that a router will be "built-in" at some point.

But really, I was really trying to address the problem for 1.0 users though, assuming that 2.0 is a bit off. I guess this all depends on the timeline for a 2.0 branch. :smile: I feel like many people are actively switching to flow-router right now (as in, yesterday) so perhaps a short-term solution (which @jshimko basically has) would be nice. Additionally, I feel like having flow-router in a separate branch right now might be actively discouraging users from using this (very good) package. The use seems to be dropping on Atmosphere... or perhaps everyone is doing local clones? I know I am.

[abernix]

@rclai, I think that's the right idea. Though, I do think any requirement to add a different package will obviously have to come in a 2.0.0 release, and that's fine. So for @tjmonsi, I think that change would be too large for a 1.0.0 release because it would be a breaking upgrade for those already using iron-router.

[splendido]

I'm still of the idea that also a usraccounts:flow-routing will be necessary to provide users with routes configured out of the box with a very few lines...

The thing is that some internal template initialization should be addressed within FR triggers before actual rendering, and I think letting also this part to the developer would be too much complicated and not that intuitive...

[splendido]

about taking IR stuff out of the current version: we can do it very quickly, but I wouldn't bump to 2.0 (which would be the correct thing to do btw...).

We might think about a minor bump including some warning in case AccountsTemplates.configureRoute is called without the useraccounts:iron-routing package installed... Does it make sense? I obviously like to get people easily out of the IR dependency as quick as possible ;-)

[rclai]

Yes, I was thinking that as well, just wasn't sure if you were comfortable doing that (the minor bump).

[rclai]

The problem with having routes configured for Flow Router is that it will tie it to a specific template engine, which Flow Router was specifically designed not to do (@arunoda correct me if I'm wrong).

How would you tackle that?

[splendido]

That's a good point! I've read about the Blaze/React alternatives, but I actually had no time to have a look at FR yet... :(

Perhaps in this case the rendering engine could be autodetected within the useraccounts:flow-routing package? ...and we're back to the previous point! But maybe it would be easier in this case?

[jshimko]

Or we could just make the rendering engine a configuration option for people using useraccounts:flow-router.

[rclai]

That would be cool. Can we figure that out later though, perhaps in a separate issue? I don't think that it stops us from doing what is actionable now (if you're in agreement), which is to de-couple the iron:router features to another package, and let core be only atTemplates and the user account-related config functionality. What do you think?

[abernix]

@splendido is right and ease-of-use route-creation (i.e. useraccounts:flow-routing, etc.) will be needed. I'm all about simplicity and ease of getting up-and-running (as I'm about to make very clear) :smile:.

Why not have a default configuration, with just one package, that just works? Pick a router and go for it (iron-router is great). Keep the code well compartmentalized within the package, but have it integrated in the package. Make the dependency on this router weak: true. Then, if someone wants to add an override package (useraccounts:flow-routing?), fine, it will take the place of the default configuration and it will force that router. None of the built-in functionality will run.

In the case that someone does add useraccounts:flow-routing then have it (for now) just use BlazeLayout. I think that's fine for the short term and covers (guessing here) 90-95% of the users. Then, as @jshimko says, make it a configuration option in the future (3.0?).

Overall, my feelings are...

• Leave this 1.0 branch in the dust. So many people are already probably forked into this flow-router-integration branch, if they want to stay there, they can stay there. I believe it will keep working as long as it's dependency stays as the meteorhacks:flow-router version, right? Anyone using the official version will see that a new 2.0 branch is out that they need to make changes for.
• Obey semantic versioning - Why make a warning? The warning is in the version number.
  • Change milestones on other non-iron-router/flow-router related stuff to a 3.0 milestone - get to it soon.
  • Make a new 2.0.0 release which implements the rest of what has been suggested everyone, as I tried to summarize above, and release it asap.

It just seems like this router thing is the most pressing thing for this package right now to keep it moving forward with a strong user-base. I'm a big proponent of this package over the alternatives, and again, I feel like usage is dropping because use is getting too complex. Keeping things agnostic is well and good, but on-boarding should be stupid easy (almost as easy as accounts-ui).

[splendido]

I'll try to get IR stuff out into useraccounts:iron-routing tonight then! ... @jshimko: could you do the FR part on useraccounts:flow-routing? v1.11.1

[jshimko]

@splendido Yep. :)

[splendido]

ok guys, I've just pushed some commits to core to get rid of IR stuff and then I've also initialized the iron-rounting repository.

Tomorrow I'll have a bit of testing and I'll try to add something about this new scenario into the README. ...a comprehensive Quick Start section seems to be missing.

If you're quicker than me, I'll happily accept PRs ;-)

[splendido]

...please note that you now need to define routes after the usual AccountsTemplates.configure({}) block since routes are now defined on the fly and some configuration should be set in advance for everything to work correctly.

[splendido]

The counterpart for FR should follow soon on flow-rounting

[rclai]

@splendido this is great! I'm glad that after 100 comments on here things are now mobilizing :smile: