Don't hardly depend on iron:router - Flow Router Integration #308
Comments
|
makes sense @sanjo! Probably solution 1. is the easier/quicker at the moment. Could you make a PR about this? Solution 2. sounds better! But perhaps is something that could be better integrated into a |
|
+1 for the ability to use flow-router instead of IR. |
|
@splendido let me know, if you need to any help? Just tag me or send me an email. |
|
Hello @arunoda! I really need to find some spare time to draw the skeleton for the new useraccounts@2.0 :( I'm thinking to provide two independent routing packages:
without any doubts, it would be awesome having you involved in the package for the flow router ;-) Lets keep in touch! |
|
sure. Thanks. |
|
+1 to support flow-router. Is there any way I can help with it? |
|
...to get started even before I can manage to complete the new skeleton, we could play around on a new branch for I've just created a new flow-router-integration branch! Most of the routing set up is done in setupRoutes which now calls regular IR API. Something else can be found here for the Other Let me know! |
|
+1 to flow-router & useraccounts! |
|
Please all, les try out the current status for the Flow Router intergration! I'd say the only way to do so is to locally clone See also the Working Locally section on the README.md |
|
@splendido trying the flow router branch. I may have messed something up but I am getting the following error: #simple accounts config for now
AccountsTemplates.configure
defaultLayout: 'mainLayout'
homeRoutePath: '/'
defaultContentRegion: 'main'
showForgotPasswordLink: true
AccountsTemplates.configureRoute('signIn');
AccountsTemplates.configureRoute('forgotPwd');
AccountsTemplates.configureRoute('enrollAccount');<template name="mainLayout">
{{> Template.dynamic template=main}}
</template>EDIT1: this happens on all routes. An easy example is the enroll account route. EDIT2: the full trace: |
|
At the moment you need to set the AccountsTemplates.configure({
defaultLayout: 'masterLayout',
defaultLayoutRegions: {},
defaultContentRegion: 'main'
});But you are right that this should not happen, because |
|
It works! Thank you much @PhilippSpo! |
|
I'm using the flow-router-integration branch locally with no problem. I'm having trouble when I try to deploy however. It seems to be using master. (it errors out on bad key defaultLayoutRegions, for example) How would I use this branch in production? (I'm using Heroku with build pack meteor-buildpack-horse). |
|
Thats a great question ...I had the same issue today an scalingo.io .. |
|
where are you keeping the local clone of the repo? As a tricky workaround, you can always change the version number with something like |
|
I cloned the useraccounts core package in |
|
...just a silly pointer, the submodule is then pointing to the |
|
Not with this branch but I have pushed a branch of this to production before. I believe I bumped the version number. Be sure your not using sym-links, they don't work (which makes sense but it is easy to forget). |
|
My clone of the repo is in /[myproject]/packages and is the right branch (I can see the flow-router changes). Meteor doesn't seem to be picking it up in production however. I thought I'd be able to change the version number as was suggested with something like: meteor add meteor-useraccounts:core@1.8.1 but that says no such package. What am I doing wrong there? |
|
I removed the package from the packages folder and did the following: cd packages/
git clone https://github.com/meteor-useraccounts/core.git --branch flow-router-integration
cd ..
git add packages/core/and then committed the whole thing. So in this case a didn't use a submodule and it seems to work fine. |
|
Ah! In your .meteor/packages do you have |
|
+100 for flow-router + useraccounts! |
|
@DenisGorbachev the branch works quite well for now. User Accounts v2 is in the works. |
|
@Kestanous Thanks for the tip, I'll check it out. |
|
I would love to see iron-router removed as a dependency from this package. I followed all the instructions in this thread about using flow-router instead, but I'm still seeing iron-router get installed somehow. Every since switching to flow-router I feel like I actually understand what is going on in my app. |
|
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. 😄 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. |
|
@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 |
|
I'm still of the idea that also a 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... |
|
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 |
|
Yes, I was thinking that as well, just wasn't sure if you were comfortable doing that (the minor bump). |
|
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? |
|
That's a good point! Perhaps in this case the rendering engine could be autodetected within the |
|
Or we could just make the rendering engine a configuration option for people using useraccounts:flow-router. |
|
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 |
|
@splendido is right and ease-of-use route-creation (i.e. Why not have a default configuration, with just one package, that just works? Pick a router and go for it ( In the case that someone does add Overall, my feelings are...
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 |
|
I'll try to get IR stuff out into |
|
@splendido Yep. :) |
|
ok guys, I've just pushed some commits to core to get rid of IR stuff Tomorrow I'll have a bit of testing and I'll try to add something about this new scenario into the README. If you're quicker than me, I'll happily accept PRs ;-) |
|
...please note that you now need to define routes after the usual |
|
The counterpart for FR should follow soon on flow-rounting |
|
@splendido this is great! I'm glad that after 100 comments on here things are now mobilizing 😄 |
|
Good job guys. @rclai yes flow-router's idea is to decouple and use it with different layout engines. I think the idea is successful with since now we can use both Blaze and React with FlowRouter. |
|
@rclai I'm sorry you guys had to wait 100 comments before getting things moving on... Hopefully things will get better also thanks to contributions from the community... |
|
@arunoda I'm glad you like it! |
|
I've just pushed a first version of flow-rounting! Please let me know in case you get a chance to play a little with the new packages and find some problem! |
|
@splendido Will try in a few, but how will it work with let's say, useraccounts:materialize? |
|
Hi @splendido Had to use this with a simple project and here's what I got: and it still loads iron router dependencies because it tries to load useraccounts:core. It messes up with the already loaded FlowRouter. |
|
Here's what it is loading in my dependencies: While I already have these: I think I'll try forking useraccounts:core and useraccounts:materialize and maybe remove the dependencies on iron router, then just try to play with it (Might just plan on using FlowRouter as is to define the routes) |
|
Ok I got it working now, Forked your useraccounts:core (just found out that the core dependencies on Iron Router was removed yesterday, used mine for now) Then did this... It is currently working... for now... will update in a few |
|
Sorry, I should have mentioned I still haven't published the new changes. Then:
should be enough to go, provided you have local clones for |
|
The useraccounts:flow-routing package is out! ...please report problems in separate issues from now. |
|
...please try it out and in case you like it, star it both on atmosphere and github ;-) |
and others
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:
Package['iron:router']for the iron:router specific parts.The text was updated successfully, but these errors were encountered: