Map ctx.request.params to corresponding method parameters

It would be great if we could map ctx.request.params to same named method arguments:

  @Get('/:id/:name/:value')
  index(name, value, ctx, id) {
    return { /// Considering #505 is implemented
      name,
      value,
      id,
      params: ctx.request.params
    };
  }

It would be better if we could map them irrespective of order, based on names.

[LoicPoullain]

Interesting. This would solve the naming issue indeed. But in this case, Foal will have to manually parse the path /:id/:name/:value to know the parameters which is already done under the hood by Express.

This may also generate conflicts in large apps with many sub-controllers (see example below).

@Get('/users/:userId')
class UserController {
  @Post('/friends/:friendId')
  deleteUserRelationShip(ctx, friendId) {
    // Is it `friendId` or `userId`?
  }
}

Maybe we could also pass the params object as second (optional) argument and take advantage of es6 syntax like this?

@Get('/:id/:name/:value')
index(ctx, { id, name, value }) { // equivalent to index(ctx, params)
  // do something with the variables "id", "name" and "value".
   return ...
}

@Get('/users/:userId')
class UserController {
  @Post('/friends/:friendId')
  deleteUserRelationShip(ctx, { friendId }) { // or { friendId, userId }
    ...
  }
}

[geekflyer]

following up on my comment on #490:

The issue is basically with the current design of FoalTS encourages type-unsafe access of context properties.

Let’s describe this using an example taken from the docs:

import { Contains, Length } from 'class-validator';

export class SocialPost {

  @Length(10, 20)
  title: string;

  @Contains('hello')
  text: string;

}

import { Context, HttpResponseCreated, Post } from '@foal/core';
import { ValidateBody } from '@foal/typestack';
import { SocialPost } from './social-post.validator';

export class SocialPostController {

  @Post()
  @ValidateBody(SocialPost)
  createSocialPost(ctx: Context) {
    const body = ctx.request.body;
    // do something with the body
    return new HttpResponseCreated();
  }
}

In the example above ctx.request.body and body is basically implicitly any.

This means I can accidentally type stuff like:

body.message (which would yield undefined) instead of body.text.

Normally I would expect the Context interface to have a generic type parameter to pass in the body type, but even this isn’t the case, so I can’t do things like:

export class SocialPostController {

  @Post()
  @ValidateBody(SocialPost)
  createSocialPost(ctx: Context<SocialPost>) {
    const body = ctx.request.body;
    // do something with the body
    return new HttpResponseCreated();
  }
}

In other frameworks this is usually solved more elegantly by having parameter decorator, i.e.:

export class SocialPostController {
  @Post()
  createSocialPost(@ValidateBody(SocialPost) body: SocialPost) {
    // do something with the body
    return new HttpResponseCreated();
  }
}

I’m aware I could do

const body = ctx.request.body as SocialPost but I find that rather unwieldy, especially since the validation and type cast now appear on very different lines in the code, making it more likely that one would accidentally not keep them in sync (i.e. validate as B, but cast to A).

Imo the nicest way I’ve seen this solved is in plumier: https://plumierjs.com/docs/refs/validation#validate-request-body