Hello,
Router.current() is only defined on the client.
How to get the current route name on server ?
Mickael.
Hello,
Router.current() is only defined on the client.
How to get the current route name on server ?
Mickael.
Template.foo.helpers({
myHelper : function() {
const controller = Iron.controller();
console.log(controller);
}
});
The contoller object will have the current path and other properties that might be what you are looking for.
The code above give’s you an idea of how to access it in a helper function. hope this helps
Are you on the client ? My question was on the server side.
im not so sure how you would get that info on the server side unless you passed it in with a call to a meteor method. In that case you could get the path from the controller object to pass along.
To just query that info on the server at any point in time. I dont know of a way to do that.
I will read through the iron:router documentation tho and look further. I also use iron:router so I am curious now. If i find out anything I will post it here.
I think that routers like Iron and Flow are client side only. Then, you can send by parameters current route name for your Meteor methods.
I read through the documentation which can be found here http://iron-meteor.github.io/iron-router/ and maybe @MickaelFM is referring to creating a server side route (which is possible), and then when that route handler fires seeking a way to find information about the URL’s path or the name of the route
But for a client side route, I agree this information would need to be passed to the server as a parameter when calling a Meteor method
Yes, that’s exactly that. I made an analytic tool that is unaware of routes. So inside it, I would like to know on which route I am. Easy on the client, not so on the server.
I wonder if you could implement a request handler using the webapp package instead of creating a server side route using iron:router and then inside that handler access the information you need using the connect node module’s api
WebApp Documentation
Connect Documentation
My (simple) analytic package is based on Iron-Router.
Router.onBeforeAction(function() {
logVisit();
this.next();
});
So it would be somewhat hard to communicate between the two, no ?
I was thinking server side routes would be defined not with iron:router but with the web app package and the code called inside your current server side routes would reside in the handler defined for that same route just now defined using the web app package. Now as for the information you need to collect on the server about the current path of the request being handled, that information may available through the “connect” node module’s API (which i believe the web app package is built on top of and will make available in the request handler). I will try to build what I am referring to this weekend and then share it if it works. I am not sure it will work out … so fingers crossed haha
Side question: So Iron Router is not dead? Do you use it for produciton?
I am only using iron:router for my personal side projects. My employer doesn’t use MeteorJS at the moment for any of our client work … but that may change in the near future, I am a strong advocate for Meteor internally. For any client work where I would use MeteorJS I would use iron:router if I was using Blaze. I dont see any issues with doing so
Although I believe this router is the only community router being actively developed at the moment that will allow you to use both Blaze or React
I may be wrong about iron:router and whether it is still being actively maintained
For me it is not dead at all, I use it on many websites.
@brianmulhall was it a question?
According to Atmosphere, latest release was v1.1.2
in Feb 13, 2017, seems pretty dead to me
hmmm … maybe it would be a good idea if we could figure out which packages people care about and need maintainers. and then try to match some people with the abandoned ones. I’d like to maintain a package that could use some help
What importance does it make if the last release was from 2017 ? It works. If only we had the possibility to know the name of the current server route… I think I will implement it myself.
it would be nice if bugs were getting fixed tho and if new features got added from time to time … it is still useful. I agree with that.
Also using it in production but our subscriptions are in the template.
@MickaelFM so i think my idea to create a single server side route using the web app package is not going to work. I feel like this topic explains why it would fail pretty well. Some other people in that topic had used flow-router on the client side and then used express or the web app package on the server side with some success