When using Express normally you use app.post('/path') or app.get('/path') to define routes.
Does Express also provide a function to define routes like this app.route('POST', '/path') (where route is the function I'm looking for)?
You can programmatically select method with bracket notation. For example:
app['post']('/path')
app['post']('/path-2')
app['get']('/path')
Related
Right now I have two routes, invoking the same method.
Let's say the method's name is myMethod
And two routes are / and /:params
router.get("/", myMethod);
router.get("/:param", myMethod);
Since in both cases I have to invoke the same method, I want to use a single route to invoke the myMethod. Something like this,
router.get('/' or '/:param', methodName);
If it is possible, then how can I do this?
You can use an array :
router.get(['/', '/:param'], myMethod);
I'm just trying to get a grasp of what middleware refers too. At first I thought it was functions used in the framework express. Although now I'm getting a sense that they simply just refer to functions that get in the middle between asynchronous functions.
I know it's common to see next() get used to move from one middleware to the next. Both express and mongoose have the next() call with similar names. I'm concerned as I don't see mongoose or express refer to each other in their documentation. So this leaves me to believe the context of their middleware is just for themselves.
http://mongoosejs.com/docs/middleware.html
http://expressjs.com/en/resources/middleware.html
When combining express with mongoose are all the middlewares lined up together/concatenated or is it separate?
e.g. together/concatenated
- calling next() on mongoose will also trigger expresses middleware function
e.g. Separate
- mongoose just has it's middleware next() just move for pre/post hooks
- express also just has it's middleware next() just move towards it's supported middleware functions
Short answer: they're separate.
Longer answer: By convention, most middleware stacks implement some kind of next function to call in order to proceed down the stack and call each middleware function in turn.
It's a matter of scope. Express and Mongoose both have their own independent middleware stacks, so what the next function does depends on where it gets called. As a general rule of thumb, every function-- including the anonymous functions used for callbacks that accept a next parameter-- have their own scope.
Consider the following really brief example of differently scoped, but otherwise identical parameter names:
function doSomething(arg) {
console.log(arg)
function doSomethingElse(arg) {
console.log(arg);
}
doSomethingElse('different');
}
doSomething('original');
// Outputs
// > 'original'
// > 'different
Even though doSomething and doSomethingElse both have a parameter called arg, the value logged to the console by doSomethingElse is the value actually passed to that function-- the value of arg as scoped to the function it was called in, not the scope surrounding it.
This is true for Mongoose middleware applied within Express middleware (or vice-versa): they just happen to share a similar, conventional parameter name.
As a learning experiment, you should deviate from conventions for a moment (but not forever; conventions exist for a reason!) to name your Express and your Mongoose next parameters something else in a single file-- expressNext and mongooseNext, perhaps-- to help differentiate them in your mind.
I know i18n-abide add a req.gettext but how to handle strings outside a route/controller?
I mean for example, if I have strings to be translated in a mongoose schema file how can I use the gettext method?
I am setting-up the server response of a query to couchbase and want to use handlerbars to render the response data.
I understand that the best practice is to have my helper functions into a separate file and not be embedded in a script tag in my html file.
My question is what is the best practice or technique to pass the data from the server response to my hanldbars helper file to then be manipulated?
I am using hapijs on the server and jQuery on the client.
Well I might be wrong, but following this example I found, it seems like you export the helper file like you would any other module with the module.exports
http://codyrushing.com/using-handlebars-helpers-on-both-client-and-server/
According to the API documentation for hapi the helper file must export a single method with the signature `function(context).
Helpers are functions used within templates to perform transformations
and other data manipulations using the template context or other
inputs. Each '.js' file in the helpers directory is loaded and the
file name is used as the helper name. The files must export a single
method with the signature function(context) and return a string.
Sub-folders are not supported and are ignored. Defaults to no helpers
support (empty path). Note that jade does not support loading helpers
this way.
https://github.com/hapijs/hapi/blob/master/docs/Reference.md#route-options
In my app.js file, I use app.set(valName, value) to pass several config values to my routes.
I then pass the app to my routes: app.use('/', require('./routes/index')(app));
I can then easily use app.get(valName) to retrieve the values in the routes.
My question is: wouldn't it be easier to just use app.valName = value; and then just access app.valName in the route?
Do I have to use the .set and .get? Or will this be violating something?
Do I have to use the .set and .get? Or will this be violating something?
Do you have to? No. Should you? Yes!
By setting your application properties directly to the app object (e.g. app.valName = value;), you may be overwriting properties that Express has initialized for internal use.
You can see from Express's source code that Express applications create the following properties in their init function:
this._baseRoutes = {};
this.cache = {};
this.settings = {};
this.engines = {};
this.defaultConfiguration();
And even more properties are set after the defaultConfiguration function is executed. This means that if you want to have a property named cache, settings, or engines, just to name a few, you will be stepping on Express's toes and will probably cause something to go wrong when your application is running.
You can see from the source of app.set that application settings are sorted in a settings object, not directly in the application object. This is to prevent what I just described above: conflicts with internal property names.