DEV Community: Krzysztof Szala

New GitHub Issues – first impressions

Krzysztof Szala — Fri, 15 Oct 2021 13:02:39 +0000

GitHub is working on a new version of their project managing application, which will be tightly coupled with whole GitHub flow by itself. The project is currently in limited public beta – you can sign up here and wait for the access.

First impressions

I had the opportunity to use it for a while, and here are my quick first impressions:

It's kept in GitHub convention, with all pros and cons of its UX design.
You can create many views for each project, and switch between them smoothly.
All views can work in list or board layout, and you can switch them any time.
Creating a new item in the board layout is basically narrowed to its name. You can't and any extra fields, labels etc.
To add extra fields like iteration number, maybe some other option – you need to switch to list mode.
Every item can be converted to issue, you just need to choose one of your repositories.
Automation for every column was replaced with workflows. This new approach looks very promising, but for now, it offers only basic default workflows. You can turn them on and off, change their settings a little, but you cannot create your own. It's marked as "coming soon".
It's fast! One thing I truly hate in JIRA is its performance. GitHub Issues is fast as hell, but to be honest – it looks poor even compared to old projects version.

What is missing?

What should be added before taking it serious:

We must be able to edit items from each type of layout, not only from the board one.
It should be possible to add a description for the item draft.
There must be some kind of summary preview like in old version of GitHub projects.

Should I use it?

Is it ready for business use? No, definitely not (it's still in beta stage, right?). There is a long way ahead of them, but I support the whole project strongly because it's time to break the dominance of JIRA in project managing software. So, keeping the fingers crossed!

Using data sets in your Jest tests

Krzysztof Szala — Thu, 02 Sep 2021 07:37:54 +0000

Data sets or data providers in testing are powerful tools, which can let you keep your test clean and simple. Checking only happy path doesn't prove your application works as expected. High-quality unit tests need to check many cases with different data. Let us consider such a case:

We hire moderators for keeping the order in our social media service. Each moderator has his own base salary, but for their action they can earn some additional penalties and bonuses. Penalties are expressed with percentage by which the salary will be reduced. While bonuses are just values which will be added to the base salary. Important business logic – the penalties are handled BEFORE bonuses, so even if moderator got 100% penalty, it can still get some money with additional bonuses. Here is the salary calculation equation:

FINAL SALARY = (BASE SALARY - PERCENTAGE OF BASE SALARY) + BONUSES

A simple implementation of business logic described below would look like this:

class SalaryService {
  static getFinalSalary(
    baseSalary: number,
    penalties: number,
    bonuses: number
  ): number {
    return baseSalary * (1 - penalties / 100) + bonuses;
  }
}

Ok, now is time to coverage our code with some unit tests:

describe('SalaryService', () => {
  describe('getFinalSalary', () => {
    it('returns calculated final salary', () => {
      const result = SalaryService.getFinalSalary(10, 50, 2);

      expect(result).toBe(7);
    });
  });
});

This is a perfectly fine test, it is short and clean. But it doesn't prove that tested code fulfills business requirements because it can just always return 7. We need to check our method against more than just one case. Three different input sets will be enough for now. So, what we do with our test? Copy and paste like this?

describe('SalaryService', () => {
  describe('getFinalSalary', () => {
    it('returns calculated final salary', () => {
      const result = SalaryService.getFinalSalary(10, 50, 2);

      expect(result).toBe(7);
    });

    it('returns calculated final salary', () => {
      const result = SalaryService.getFinalSalary(0, 50, 3);

      expect(result).toBe(3);
    });

    it('returns calculated final salary', () => {
      const result = SalaryService.getFinalSalary(20, 100, 1);

      expect(result).toBe(1);
    });
  });
});

It doesn't look good – we duplicate lots of code. And this is simple example, image if it would be something far complicated. Luckily, there is a great solution for such an issue – data sets!

Data sets or data providers allow us to rerun the same test with different sets of input values. So first we should gather our data in one consistent array:

const dataSet = [
  [10, 50, 2, 7],
  [0, 50, 3, 3],
  [20, 100, 1, 1],
];

Then we need to rewrite our test a bit our test. Remove all duplicated code, and leave just one test. Now we pass our dataSet as argument to .each() at test implementation or test suit level. In the callback, we will receive parameters with values passed in each row of our data set:

describe('SalaryService', () => {
  describe('getFinalSalary', () => {
    const dataSet = [
      [10, 50, 2, 7],
      [0, 50, 3, 3],
      [20, 100, 1, 1],
    ];

    it.each(dataSet)('returns calculated final salary', (baseSalary, penalties, bonuses, expectedValue) => {
      const result = SalaryService.getFinalSalary(baseSalary, penalties, bonuses);

      expect(result).toBe(expectedValue);
    });
  });
});

Ok, it looks better now – we don't have code duplication anymore, and we test many cases with one more generic test. But when you look at our data set, you will probably find it quite hard to read. Without checking the callback arguments, we don't have any what each value represents. Let's fix it.

const dataSet = [
  { baseSalary: 10, penalties: 50, bonuses: 2, expectedValue: 7},
  { baseSalary: 0, penalties: 50, bonuses: 3, expectedValue: 3},
  { baseSalary: 20, penalties: 100, bonuses: 1, expectedValue: 1},
];

As you can see, we've replaced our nested arrays with much more explicit objects. Now everyone, who looks at this data set, will understand what it contains. We need also to change the way how these values are passed to our test body. Change:

(baseSalary, penalties, bonuses, expectedValue)

to destructuring assignment:

({ baseSalary, penalties, bonuses, expectedValue})

You can also use data set values in test description – it can be helpful when some test won't pass. This is what our refactored test case look like. Now we can say it's data-driven test!

describe('SalaryService', () => {
  describe('getFinalSalary', () => {
    const dataSet = [
      { baseSalary: 10, penalties: 50, bonuses: 2, expectedValue: 7 },
      { baseSalary: 0, penalties: 50, bonuses: 3, expectedValue: 3 },
      { baseSalary: 20, penalties: 100, bonuses: 1, expectedValue: 1 },
    ];

    it.each(dataSet)(
      'returns calculated final salary ($baseSalary, $penalties, $bonuses)',
      ({ baseSalary, penalties, bonuses, expectedValue }) => {
        const result = SalaryService.getFinalSalary(
          baseSalary,
          penalties,
          bonuses
        );

        expect(result).toBe(expectedValue);
      }
    );
  });
});

Now, when you get any errors related to tested method, it's going to be very easy to add another case which will cover it. Remember – always write your test against as many worthwhile cases as you can invent!

Ps. Data sets support is included in Jest since version 23. If for some reasons you're still using an older build, check jest-each npm package, which provides the same functionality.

Native enums are coming to PHP

Krzysztof Szala — Thu, 08 Jul 2021 13:30:41 +0000

The next bigger version of PHP is going to be released in November 2021. Version number 8.1 will come with few interesting changes, but for the most of the developers, the most significant one will be implementations of enumerated types.

What enums are? Enumeration types are basically yet another data type, which contains a list of predefined values. It's a very convenient solution, when you want to force the developer to pass only a specified range of cases. Here is a quick example. For some reason (god only knows why), You are dealing with seasons. Instead of working with strings like "Spring", "Summer", "Autumn" and "Winter", you can create Season enum:

enum Season{
  case Spring;
  case Summer;
  case Autumn;
  case Winter;
}

New you can request to pass in your function the Season enum type:

function(Season $season){
  if($season === Season::Summer){
    echo 'It summer! It must be hot!';
  }
}

Backed enums

You can also create enum with assigned scalar value for every option. It is helpful, when you want to, e.g. pass your data to a database. It's called backed enums. Here is and example:

enum DayOfWeek: int {
  case Monday = 1;
  case Tuesday = 2;
  case Wednesday = 3;
  case Thursday = 4;
  case Friday = 5;
  case Saturday = 6;
  case Sunday = 7
}

Calling specific enum options will return something resembling an object. Object with two properties – name, and value. So, you can access enum data in similar way to objects parameters.

DayOfWeek::Friday->value // It will return 5

Ok, we know how to get value of enum options. What about the reverse direction? How to get enum name, knowing just it's value? PHP introduces two "static" method, which can be call on the enum – ::from() and ::tryFrom().

DayOfWeek::from(5)

Will result with:

DayOfWeek Enum:int
(
    [name] => Thursday
    [value] => 4
)

Remember that backed enums can contain cases only of one type – for example integer like in the example above. It's not possible to mix types, neither mix cases with values and pure cases (it's term for case without assigned value). So, there are only two types of enums in PHP – pure and backed ones.

Enumerated Methods

The above features are present in most of the programming languages which support enums. But PHP will go one step further. It provides Enumerated Methods Enums will work in some way like classes. You will be able to add your method, implement interfaces, even use traits. Look at this:

enum MatchStatus {
  case NotStarted;
  case FirstHalf;
  case SecondHalf;
  case FinishedRegularTime;
  case FinishedAfterPenalties;

  public function type(): string {
    return match($this) {
      Status::NotStarted => 'Not started',
      Status::FirstHalf, Status::SecondHalf => 'Ongoing',
      Status::FinishedRegularTime, Status::FinishedAfterPenalties => 'Finished',
    };
  }
}

We've created enum MatchStatus which contains some soccer event statuses. Then we implement type() method, which will return status type as string value. This is how we can use it:

$matchStatus = MatchStatus::SecondHalf;
$matchStatus->type();

The result of calling type method will be 'Ongoing' string. If you haven't used PHP8 yet, You can be not familiar with match expression. Read about it here.

More information and examples of use you can find in RFC of enums.

What's your opinion about PHP enumerated types? What do you think about syntax, and rich enum features, which are not usually presented in other languages? Was it worth to wait? Share your thoughts!

Injecting request object to a custom validation class in NestJS

Krzysztof Szala — Wed, 12 May 2021 11:24:20 +0000

I'm a big fan of how NestJS handle validation using class-validator library. There are many advantages of using an external library for validation. For most of the typical cases default integration via ValidationPipe is good enough. But as you know, daily work likes to verify and challenge us.

A few days ago I had a specific need – I needed to validate something with ValidatorPipe and class-validator library, but one of the validation factors, was user ID. In this project, user ID is pulled out from JWT token, during the authorization process, and added to the request object.

My first thought was – just use the Injection Request Scope, like we can do it in NestJS services:



constructor(@Inject(REQUEST) private request: Request) {}

Obviously – it doesn't work, otherwise this article wouldn't be here. Here is a short explanation made by NestJS creator, Kamil Myśliwiec:

Ok. So, there is basically no simple way to get request object data in custom validation constraint. But there is a way around! Not perfect, but it works. And if it can't be pretty, at least it should do its job. What steps we need to take, to achieve it?

Create Interceptor, which will add the User Object to the request type you need (Query, Body or Param)
Write your Validator Constraint, Extended Validation Arguments interface, use the User data you need.
Create Pipe, which will strip the request type object from User data context.
Create the appropriate decorators, one for each type of request.
Use newly created decorators in Controllers, when you need to "inject" User data to your validation class.

Not great, not terrible. Right?

Interceptor

Create Interceptor, which will add User Object to request type you need (Query, Body or Param). For the demonstration purposes, I assume you store your User Object in request.user attribute.



export const REQUEST_CONTEXT = '_requestContext';

@Injectable()
export class InjectUserInterceptor implements NestInterceptor {
  constructor(private type?: Nullable<'query' | 'body' | 'param'>) {}

  intercept(context: ExecutionContext, next: CallHandler): Observable<any> {
    const request = context.switchToHttp().getRequest();

    if (this.type && request[this.type]) {
      request[this.type][REQUEST_CONTEXT] = {
        user: request.user,
      };
    }

    return next.handle();
  }
}

Custom validation decorator

Write your Validator Constraint and custom decorator, Extended Validation Arguments interface, use the User data you need.



@ValidatorConstraint({ async: true })
@Injectable()
export class IsUserCommentValidatorConstraint implements ValidatorConstraintInterface {
  constructor(private commentsRepository: CommentsRepository) {}

  async validate(commentId: number, args?: ExtendedValidationArguments) {
    const userId = args?.object[REQUEST_CONTEXT].user.id;

    if (userId && Number.isInteger(commentId)) {
      const comment = await this.commentsRepository.findByUserId(userId, commentId); // Checking if comment belongs to selected user

      if (!comment) {
        return false;
      }
    }

    return true;
  }

  defaultMessage(): string {
    return 'The comment does not belong to the user';
  }
}

export function IsUserComment(validationOptions?: ValidationOptions) {
  return function (object: any, propertyName: string) {
    registerDecorator({
      name: 'IsUserComment',
      target: object.constructor,
      propertyName: propertyName,
      options: validationOptions,
      validator: IsUserCommentValidatorConstraint,
    });
  };
}

If you don't know how to inject dependencies into a custom validator in class-validator library, this article can help you.

My ExtendedValidationArguments interface looks like this:



export interface ExtendedValidationArguments extends ValidationArguments {
  object: {
    [REQUEST_CONTEXT]: {
      user: IUser; // IUser is my interface for User class
    };
  };
}

It allows me to use valid typing in ValidatorConstraint. Without it, TypeScript will print out an error, that the _requestContext property doesn't exist.

Stripping Pipe

Create Pipe, which will strip the request type object from User data context. If we don't do that, our DTO object will contain attached previously request data. We don't want that to happen. I'm using here one of the lodash function – omit(). It allows removing chosen properties from an object.



@Injectable()
export class StripRequestContextPipe implements PipeTransform {
  transform(value: any) {
    return omit(value, REQUEST_CONTEXT);
  }
}

New decorators

Creating new decorators is not necessary, but it's definitely a more clean and DRY approach than manually adding Interceptors and Pipes to the methods. We're going to use NestJS built-in function – applyDecorators, which allows merging multiple different decorators into a new one.



export function InjectUserToQuery() {
  return applyDecorators(InjectUserTo('query'));
}

export function InjectUserToBody() {
  return applyDecorators(InjectUserTo('body'));
}

export function InjectUserToParam() {
  return applyDecorators(InjectUserTo('params'));
}

export function InjectUserTo(context: 'query' | 'body' | 'params') {
  return applyDecorators(UseInterceptors(new InjectUserInterceptor(context)), UsePipes(StripRequestContextPipe));
}

To add your user data, just decorate your controller's method with one of the above decorators.



  @InjectUserToParam()
  async edit(@Param() params: EditParams){}

Now, if you wanted to use your IsUserComment decorator in EditParams, you will be able to access injected user data.



export class EditParams {
  @IsUserComment()
  commentId: number;
}

And that's all! You can use this method, to add any data from the request object to your custom validation class. Hope you find it helpful!

You can find an example repository on my GitHub.

In case you use in your ValidationPipe whitelist: true parameter, and above example doesn't work for you – check this issue.

This article is highly inspired by the idea I've found in this comment on GitHub.

PS. It's just proof of concept, and this comment ownership validation is a simple example of usage.

How to fix zsh icons in Visual Studio Code terminal?

Krzysztof Szala — Thu, 06 May 2021 13:42:48 +0000

Zsh is a popular UNIX shell used by many Linux and macOS users around the globe. It's even more powerful when you use it with a configuration framework like Oh my zsh and a fantastic template like Powerline10k. So, we set up our new shiny shell, everything works great in our terminal. Time to write some code. We run Visual Studio Code, open a built-in terminal and... something is not right. What happened to our beautiful template? Where are our sexy icons?

The solutions for that is simple, try to follow the steps below:

Download the latest version of Hack Nerd Font, for example from here. Choose the file with ttf suffix.
Extract it from the archive.
Move all ttf files to /usr/share/fonts directory (or ~/.local/share/fonts/ if you don't want to use them globally).
Open Visual Studio Code settings and find Terminal font section.
Change Terminal › Integrated: Font Family attribute from Monospace to Hack Nerd Font.
You can also change it directly in settings.json file (look for it in .config/Code/User directory). The property you are looking for is terminal.integrated.fontFamily.
Restart Visual Studio Code.
Enjoy your new terminal font, which should now look correctly!

Ps. It will work the same way for macOS users, but the font installation process is a little different.

How to output raw SQL with filled parameters in TypeORM?

Krzysztof Szala — Mon, 19 Apr 2021 14:46:28 +0000

Even though TypeORM provides more or less good ORM feeling, many times you have to use Query Builder instead of ORM mechanisms. It is important to check how the query will look like (for example for performance reason). So, you need to get somehow raw SQL from Query Builder, to run it manually against your database.

Although TypeORM provides getSql() method, it isn't handy for developers because it doesn't fill parameter placeholders. Let's pretend we have a simple TypeORM query builder code:

createQueryBuilder('user')
  .where('id = :id', { id: 1 })
  .andWhere('name = :name', { name: 'Chris' })
  .orderBy('id', 'DESC')
  .getSql(),

As the result of the getSql() function, you will get probably something like this:

SELECT
  users.id,
  users.name
FROM users
WHERE 
  id = ? AND
  name = ?
ORDER BY id DESC

You must admit it isn't very helpful because you need to replace manually each ? with related value. Here is a quick snippet, which will help you:

let [sql, params] = query.getQueryAndParameters();
params.forEach((value) => {
  if (typeof value === 'string') {
    sql = sql.replace('?', `"${value}"`);
  }
  if (typeof value === 'object') {
    if (Array.isArray(value)) {
      sql = sql.replace(
        '?',
        value.map((element) => (typeof element === 'string' ? `"${element}"` : element)).join(','),
      );
    } else {
      sql = sql.replace('?', value);
    }
  }
  if (['number', 'boolean'].includes(typeof value)) {
    sql = sql.replace('?', value.toString());
  }
}); 

console.log(sql);

query variable is SelectQueryBuilder<Entity> type. Your query will be outputted in a much clearer way. Now it can be directly used as SQL script in any RDB client:

SELECT
  user.id,
  user.name
FROM users
WHERE 
  id = 1 AND
  name = "Chris"
ORDER BY id DESC

If you're using Visual Studio Code as your IDE, you can try the snippet below:

"Print to console SQL query with filled params": {
  "prefix": "sqldump",
  "body": [
    "let [sql, params] = query.getQueryAndParameters();",
    "params.forEach((value) => {",
    "  if (typeof value === 'string') {",
    "    sql = sql.replace('?', `\"\\${value}\"`);",
    "  }",
    "  if (typeof value === 'object') {",
    "    if (Array.isArray(value)) {",
    "      sql = sql.replace(",
    "        '?',",
    "        value.map((element) => (typeof element === 'string' ? `\"\\${element}\"` : element)).join(','),",
    "      );",
    "    } else {",
    "      sql = sql.replace('?', value);",
    "    }",
    "  }",
    "  if (['number', 'boolean'].includes(typeof value)) {",
    "    sql = sql.replace('?', value.toString());",
    "  }",
    "});"
  ]
}

Now you can use the sqldump shortcut to print out the whole snippet. Quick and easy! :)

Edit: 08.11.2021
I've changed a little the snippet, and now it handles array type parameters as well.

Validating numeric query parameters in NestJS

Krzysztof Szala — Mon, 12 Apr 2021 13:29:00 +0000

Another day, another short article. Today we will focus on validation of numeric query parameters.

Everyone values his/her time, so here is TL;DR:

Each query parameter comes as string, so it's not possible to validate numeric params correctly. Simple solution – use @Type() decorator from class-transformer library, and declare numeric field as Number. I.e. @Type(() => Number)

Let's take an example URL address with few query parameters:

https://awesomesite.com/users?country=6&name=joe

Our controller would probably look like this:

@Controller('users')
class UsersController{
  @Get()
  getUsers(@Query() queryParams){}
}

Ok, at the beginning we've extracted our query parameters with @Query() decorator. Time to impose some validation on them. Here is our validation class:

class GetUsersQuery{
  @IsInt()
  country: number;

  @IsString()
  name: string;
}

We've defined very basic validation constraints for country and name fields. Then we need to do a little change in our controller method.

@Controller('users')
class UsersController{
  @Get()
  getUsers(@Query() queryParams: GetUsersQuery){
    console.log(queryParams)
  }
}

Ok. Time to check if our validation works correctly. Let's try to send GET request for previously mentioned URL. Everything should be just fine, right? Well, not really, here is what we got:

{
    "statusCode": 400,
    "message": [
        "country must be a number conforming to the specified constraints"
    ],
    "error": "Bad Request"
}

What? But country is anumeric field! It's even an integer! Unfortunately, not for our application. Let's try to make one step back, and remove validation, then check what kind of parameters will query object contain.

{ 
  country: '1',
  name: 'joe'
}

Ok, now you can see, that each field is passed as a string value. Even an integer field. What can we do with it? After all, we need to validate whether the country field is an integer, or not, right?

Once again, class-transformer library has a simple solution for us. Use @Type decorator, and declare country field as Number:

class GetUsersQuery{
  @IsInt()
  @Type(() => Number)
  country: number;

  @IsString()
  name: string;
}

Now our request will pass validation, and the response object will look like this:

{ 
  country: 1,
  name: 'joe'
}

Country field has numeric type now. When we send an invalid value, for example, a string, we'll get:

{
    "statusCode": 400,
    "message": [
        "country must be an integer number"
    ],
    "error": "Bad Request"
}

But for integer type parameter it will pass. Finally, our integer validation works now correctly. Hope this short article will help you to validate numeric values passed through URL parameters. Cheers!

Validating nested objects with class-validator in NestJS

Krzysztof Szala — Fri, 02 Apr 2021 15:49:14 +0000

Today I have for you a quick and short article. Maybe it will help someone. I'm using class-validator for request validation in NestJS really often. A few days ago I needed to validate a nested object. Quick look to the class-validator validation:

If your object contains nested objects and you want the validator to perform their validation too, then you need to use the @ValidateNested() decorator:

import { ValidateNested } from 'class-validator';

export class Post {
  @ValidateNested()
  user: User;
}

But for some reason It doesn't work in NestJS! Here is an easy solution. Install class-transformer package, if you haven't done it yet. Then import @Type() decorator, and declare the type of validating object with it. Check this out:

import { ValidateNested } from 'class-validator';
import { Type } from 'class-transformer';

export class Post {
  @ValidateNested()
  @Type(() => User)
  user: User;
}

Now our NestJS application will validate User object correctly. If you need to validate an array of objects, use each: true:

export class User {
  @ValidateNested({ each: true })
  @Type(() => Post)
  posts: Post[];
}

Hope it will be useful for you! Cheers!

Custom validation with database in NestJS

Krzysztof Szala — Sat, 27 Mar 2021 17:33:17 +0000

NestJS is an outstanding web framework which supports natively TypeScript out of the box. Its maintainers and community provides great and large documentation, which leads us by hand through the most important parts of the framework.

But when you start to write an application for serious, you figure out quickly, it doesn't coverage some very typical cases (at least for me).

Framework provides several ways for validation data coming with requests. We can basically use Pipes, a feature called schema-based validation (using joi library) or integration with class-validator library through ValidatorPipe. And the last one is my favorite one. Why? The main reason is that you can keep your whole validation definitions outside the controller. It's a great way to separate different concerns.

Class-Validator library is a powerful tool, which brings whole set of differential validation decorators like @Length(10, 20), @IsInt(), @Contains('example') etc. I won't introduce to you how to use basic validation in NestJS, documentation explains it quite accurately.

But what if you would like to create your own validator, and use it with class-validator library? Easy, just quick look at the documentation and you can write your own rules and can use it with @Validate() decorator. Better! It's fabulously simple to write own decorators and have your whole request validation class consists.

Problems start when we are forced to check something for example in persistent storage, like database. In short – we must inject some dependency responsible for interacting with the database. Dependency like e.g. UserRepository which is obviously responsible for users entities.

Luckly for us, class-validator provides very handy useContainer function, which allow to set the container to be used by class-validor library.

So add this code in your main.ts file (app variable is your Nest application instance):

useContainer(app.select(AppModule), { fallbackOnErrors: true });

It allows class-validator to use NestJS dependency injection container.

Then we can create a repository, which will query our database:

@Injectable()
class UserRepository {
  async getOneOrFail(userId: number): Promise<UserEntity> {
    // some code which fetch user entity or throw exception
  }
}

Ok, let's write a Validator Constraint which will hold our own validation logic. As you can see, our dependency is simply injected into the class constructor:

@ValidatorConstraint({ name: 'UserExists', async: true })
@Injectable()
export class UserExistsRule implements ValidatorConstraintInterface {
  constructor(private usersRepository: UsersRepository) {}

  async validate(value: number) {
    try {
      await this.usersRepository.getOneOrFail(value);
    } catch (e) {
      return false;
    }

    return true;
  }

  defaultMessage(args: ValidationArguments) {
    return `User doesn't exist`;
  }
}

Don't forget to declare you injectable classes as providers in the appropriate module.

Now you can use your custom validation constraint. Simply decorate class property with @Validate(UserExistsRule) decorator:

export class User {
  @IsInt()
  @Validate(UserExistsRule);
  readonly id: number;
}

If the user doesn't exist in the database, you should get error with default message "User doesn't exist". Although using @Validate() is fine enough, you can write your own decorator, which will be much more convenient. Having written Validator Constraint is quick and easy. We need to just write decorator factory with registerDecorator() function.

export function UserExists(validationOptions?: ValidationOptions) {
  return function (object: any, propertyName: string) {
    registerDecorator({
      name: 'UserExists',
      target: object.constructor,
      propertyName: propertyName,
      options: validationOptions,
      validator: UserExistsRule,
    });
  };
}

As you can see, you can either write new validator logic, or use written before validator constraint (in our case – UserExistsRule class).

Now we can go back to our User class, and use @UserExists validator instead of @Validate(UserExistsRule) decorator.

export class User {
  @IsInt()
  @UserExists();
  readonly id: number;
}

Hope this little article will help you with many common scenarios during your application development with NestJS framework. I use that technique almost every day!

Dive into PHP8. Part 1 - Constructor Property Promotion

Krzysztof Szala — Tue, 14 Jul 2020 07:11:14 +0000

A new major version of PHP is set for an official release on December 3. Along with numerous bug fixes and small improvements, developers from around the globe will also get some new interesting features. The list isn't closed yet, but, despite that, we may already check what we can expect. I'm going to prepare a series of short articles, and each one will focus on something else. Let's start!

In the first post, I would like to introduce to you Constructor Property Promotion. A concept well known in languages such as Hack, Korlin or TypesScript is going to be introduced in PHP 8. How does it work and in what kind of situations can it be useful? Let's look at the example below:

Simple Value-Object, right? We deal with classes like these almost every day. Isn't it a little annoying that we must write the whole boilerplate code to set those values from constructor to class properties? Constructor Property Promotion feature will solve that problem for us, and enable writing the kind of code presented above more simply and shortly. Check it out:

We can simply add an access modifier before the type declaration of the constructor parameter, and that parameter will be automatically assigned to the class property with the same name. We can say that parameters which have a set access modifier are promoted.

It's possible to mix promoted properties with regular properties declaration. Here is an example:

The example provided above is equivalent to the code below:

Constructor Property Promotion will be available only for regular classes and traits. We won't be able to promote properties in interfaces and abstract classes (although we can declare __constructor() method in them).

If you use a lot of Value Object (VO) or Data Transfer Object (DTO) – Constructor Property Promotion will shorten and simplify your code. A similar feature has been requested for comments several times, but only the implementation written by Nikita Popov got enough positive votes and will be merged into the new PHP version. You can read more about it in this RFC.

In the next part of our "Dive into PHP8" series, we will be talking about the implementation of Union Types. Stay tuned!

This article was originally published on my company's blog. You can check it here.