I’m not sure what the advantage of either true or false is exactly?
The extended option allows to choose between parsing the URL-encoded data with the querystring library (when false) or the qs library (when true). The “extended” syntax allows for rich objects and arrays to be encoded into the URL-encoded format, allowing for a JSON-like experience with URL-encoded.
Resurrecting this thread, because I suspect there will be users hitting a few road bumps with simple:json-routes and likely landing here for info.
We have managed to successfully upgrade to Meteor 3.0-beta.0. Among the many dependencies, we have simple:json-routes underpinning a REST API for managing user accounts.
We completely replaced connect with express in the locally forked package, so far with just one downside. With the connect router, the req.route property passed downstream was a string, representing the path. With the express router, req.route is an object, so to get the path you’d need to use req.route.path.
If anyone is interested, reply here and I can describe how to migrate a locally forked simple:json-routes, before a community supported version becomes available.
@filipenevola, I am happy to send a pull request to migrate this package and simple:rest-json-error-handler. We just need to discuss how to solve the req.route vs. req.route.path conundrum. Should we maintain compatibility, to minimise disruption as per the discussion in What impact does Webapp transition from connect to express have on community packages that use it?, or should we just accept that there will be a necessary disruption and just update the REAMDE with whatever breaking changes are identified?
The best way is to keep whatever Express is doing, in this case, changing to an object.
Maybe you could create both versions in your PR, and if the user provides a string, you emit a warning so they know they are doing something that can break in future releases.
About changelog, we should add a CHANGELOG.md in the root dir so we document break changes.
And yes, a PR would be welcome
Now, just to think outside of the migration discussion, I think we should adopt Express directly always. Then, part of these packages inside simple-rest would be unnecessary.
I added this as a TODO in README. I need to figure out how best to do it.
For now I added a section “Breaking changes” to the top of README.md in packages/json-routes, where it has a fair chance of being read. When I hit the wall with json-routes in the past, I went straight to the README in the root folder of meteor-rest, clicked the package name, and went to its readme.
If you don’t mind pushing CHANGELOG.md to the repo, just as a minimal template, I will fill it in from the READMEs of the packages.
Absolutely. It is a relief to not have to build myriad middlewares for every little thing, like it was the case with Connect.