Open SantoshSrinivas79 opened 9 years ago
Methods are good. This is not a replacement. I made this for server side rendering. Which I am going to talk tomorrow on MeteorHacks Show 2 :) On 2014 දෙසැ 15, සඳුදා at ප.ව. 6.50 fountainhead notifications@github.com wrote:
@arunoda https://github.com/arunoda coincidentally was just thinking of routers on the server. Sorry for the dumb question, but when does one use a router on the server?
I always call methods.
Can you provide some more direction on when routers can be useful on the server side?
— Reply to this email directly or view it on GitHub https://github.com/meteorhacks/picker/issues/1.
@arunoda, Thanks for the MeteorHacks Show2! In the Show you mentioned that you needed Picker for SSR but didn't go over why Iron-Router was not sufficient. Would you mind expanding a bit on what the motivation for Picker was? For example, what was missing from Iron-Router or what problems you ran into? (This would probably be good to add to the repo's readme if you're interested.)
Okay. I'll explain. It's not IR is not sufficient. It's a good. There are few reasons.
1) We needed a server only router We are using an our own router in the client. So, we can't use IR because of that.
2) IR API usage is hard to reason In our SSR demo site, we used client side router on the lib directory. Router seems to runs on both server and the client. (I hope) Then I wanted to create a new set of routes for SSR only for server. Then I got some error. I might have done anything stupid, but it didn't work.
3) Simple and Clean
We wanted middleware support and this filtering
api. I wanted to demo it easily without explaining a lot about router.
I'll add these in a much formatted way.
@arunoda coincidentally was just thinking of routers on the server. Sorry for the dumb question, but when does one use a router on the server?
I always call methods.
Can you provide some more direction on when routers can be useful on the server side?