#Working Code Isn't Working???

24 messages · Page 1 of 1 (latest)

sacred jay
#

I'm at a loss for words. Project A shows the below code to retrieve a list of businesses.

async readAccountAll(accountID: string, req: Request, res: Response) {
  // find the user by email
  const user = await this.accountRepository.findOne({
    where: {
      id: accountID,
      isActive: true
    },
    relations: {
      businessList: true
    }
  });
  // if user does not exist throw exception
  if (!user) throw new ForbiddenException('Unable to find user.');
  return user.businessList;
}

Project B, is a clone of Project A, and has been retooled for a product entity. I've also added a console.log to get the user data.

async readAccountAll(accountID: string, req: Request, res: Response) {
  // find the account by id
  const user = await this.accountRepository.findOne({
    where: {
      id: accountID,
      isActive: true
    },
    relations: {
      productList: true
    }
  });

  console.log('readAccountAll-user\n', user);

  // if user does not exist throw exception
  if (!user) throw new ForbiddenException('Unable to find user.');
  return user.productList;
}
#

The console.log() shows the below code:

 Account {
  id: 'id-here',
  firstName: 'Jared',
  lastName: 'Ledbetter',
  email: 'jared@carbondigital.us',
  phone: null,
  address: null,
  socialProfiles: null,
  accountRole: 'supporter',
  accountStatus: 'active',
  accountVerified: null,
  isActive: true,
  passwordChangedAt: '2023-02-02',
  passwordResetToken: null,
  passwordResetExpires: null,
  recordCreated: 2023-02-02T04:53:35.175Z,
  recordUpdated: 2023-02-02T11:13:53.186Z,
  productList: [
    Products {
      id: 'id-here',
      title: 'Carbon Digital',
      image: null,
      description: null,
      productType: 'single',
      priceUnit: 12,
      recordCreated: 2023-02-03T05:49:00.393Z,
      recordUpdated: 2023-02-03T05:49:00.393Z
    }
  ]
}
#

With the A & B code being nearly identical, and the user definitely being logged, my return should contain data. And yet, it's an empty object.

Any clues on why?

#

This is the expected output:

{
  "data": [
    {
      "id": "id-here",
      "title": "Carbon Digital",
      "image": null,
      "description": null,
      "productType": "single",
      "priceUnit": 12,
      "recordCreated": "2023-02-03T05:49:00.393Z",
      "recordUpdated": "2023-02-03T05:49:00.393Z"
    }
  ]
}
sacred jay
#

No. That wouldn't make any sense.

north shell
#

Why are you passing res there? What's the controller look like?

sacred jay
#

I was told to use @Res({ passthrough: true }) when using the @Param() decorator.

// route: /product/account/:accountId
@Get('/account/:accountId')
productReadAccountAll(
    @Param(':accountId') accountID: string,
    @Request() req,
    @Res({ passthrough: true }) res
) {
    this.productService.readAccountAll(accountID, req, res);
}
north shell
#

Yeah, that's alrigh then, (but still, passing the res and req to your serivce layer is not a good practise).
You're not returning anything from the route handler, so that's probbaly why you see an empty object in the response.

sacred jay
north shell
#

Please read the Controllers chapter in the docs. Using Res/Req directly is discouraged and is a remnant from express. You don't need that in NesJS, save from some specific cases.

sacred jay
#

This is interesting.

Note that when you inject either @Res() or @Response() in a method handler, you put Nest into Library-specific mode for that handler, and you become responsible for managing the response. When doing so, you must issue some kind of response by making a call on the response object (e.g., res.json(...) or res.send(...)), or the HTTP server will hang.

sacred jay
# north shell Please read the Controllers chapter in the docs. Using Res/Req directly is disco...

If @Res is needed with a @Param, then the rest will still need to be in the returned method below right? Proposed updated code options below.

Option 1: Removing the @Req but retaining the res.

// route: /product/account/:accountId
@Get('/account/:accountId')
productReadAccountAll(
    @Param(':accountId') accountID: string,
    @Res({ passthrough: true }) res
) {
    return this.productService.readAccountAll(accountID, res);
}

Option 2: Removing the @Req and the res.

// route: /product/account/:accountId
@Get('/account/:accountId')
productReadAccountAll(
    @Param(':accountId') accountID: string,
    @Res({ passthrough: true }) res
) {
    return this.productService.readAccountAll(accountID);
}

Which one of these is correct?
Based on express logic, neither should work.
Based on the limited description in the docs, I'm guessing #1 is the solution.
Based on your comments, I'm guessing #2 is the solution.

north shell
sacred jay
north shell
#

Where did you read Res is required with Param? It's definitely not

sacred jay
#

If it's not required, then I'll drop it and test again.

#

In short, if I'm not touching cookies or headers, then I don't need @Res passthrough, right?

#

Well, headers, cookies, local storage, etc.

north shell
#

Headers are in Req, I believe. But even then, it's better to use the Headers decorator.

#

Cookies would be one of the only reasons you would need Res

sacred jay
#

Sweet man. I can drop alot of express logic.