Download the PHP package telkins/laravel-validation-rulesets without Composer

A simple way to keep your Laravel validation rules a bit more DRY.

This package provides a relatively simple way to organize, reuse, and DRY up your Laravel validation rules. It was put together after working with Laravel for quite some time and specifically while building an API that also uses Laravel Nova to manage resources. There was a need to provide validation on the Laravel Nova side of things on a field-by-field basis. Then, on the API side of things, there was also a need to provide those same validation rules. These could be on a field-by-field basis or by resource.

So, by using this package, one can create two kinds of reusable rule sets. The first kind of rule set is what is referred to as a field rule set. A field rule set is a class that implements the Illuminate\Contracts\Validation\Rule interface. It can contain any number of Laravel's validation rules, as well as any other rule that implements Illuminate\Contracts\Validation\Rule.

The second kind of rule set is what is referred to as a resource rule set. This doesn't really have any direct relationship to anything that currently exists within Laravel. Rather, it's a convenient way to group rules for a given resource. It provides rules common to updating and creating as well as creation- and update-specific rules. This is quite similar to how Laravel Nova behaves with individual fields. Currently, the creation and update rules merge in any common rules, again, in the same way that Laravel Nova does with resource fields.

The result of these new classes is that one can more easily put field- and resource-specific rules in individual classes, which can then be used, reused, and tested in a way that many might prefer.

Installation

You can install the package via composer:

Field Rule Sets

A field rule set is intended to be a validation rule object that can be applied or used for validating a single field or attribute. It's similar to Laravel's validation objects that implement Illuminate\Contracts\Validation\Rule. The main difference is that these field rule sets allow a user to list one or more validation rules in a set that will be applied to the field or attribute. The code itself is inspired by Juampi Barreto's medium.com article, "Laravel 5.5 validation ruleception (rule inside rule)".

Many times the same handful of validation rules need to be applied to a given field, like an email address or a password or something. It's certainly easy enough to enter 'required|email|max:255' each time it's needed. It's also possible to create a validation rule that simply implements Illuminate\Contracts\Validation\Rule, but this requires writing all of the various validation code oneself, even though it's already there in the Laravel framework.

So, now one can simply create a new field rule set, and then provide the various validation rules that should apply. This class is now quite portable and reusable as well as easily testable.

Making a new field rule set

The package includes an artisan command to create a new field rule set.

This field rule set will have the App\Rules\FieldRuleSets namespace and will be saved in app/Rules/FieldRuleSets.

You can also indicate a custom namespace like App\MyFieldRules, for example:

This field rule set will have the App\MyFieldRules namespace and will be saved in app/MyFieldRules.

In any case, you should wind up with a file that looks similar to this:

One simply fills in the various validation rules that should be used to validate the field to which they are applied. For example:

One can also use other field rule sets, any object that implements Illuminate\Contracts\Validation\Rule, or closures. The only thing one must remember to do is to keep each rule as its own element in the array.

Implicit rules

According to Laravel's documentation on using implicit extensions, "For a rule to run even when an attribute is empty, the rule must imply that the attribute is required." Out of the box, the following code shows us which rules Laravel considers implicit:

When there is a need to use one or more of these implicit rules with field rule sets, there are two ways to do so:

• Use the implicit rule(s) within the field rule set, but be sure to make the field rule set class implement Illuminate\Contracts\Validation\ImplicitRule. This simply indicates to Laravel's validator that it is, in fact, an implicit rule.
• Instead of using implicit rules within a field rule set, remove it and have it alongside the object.

For example, this field rule set uses required and indicates to Laravel's validator that it is implicit by way of the ImplicitRule interface:

One can use the following artisan command, with the implicit option, in order to create a new field rule set that implements Illuminate\Contracts\Validation\ImplicitRule:

The alternative is to not use required nor Illuminate\Contracts\Validation\ImplicitRule within the field rule set and instead use the implicit rule alongside the field rule set object whenever it's used. Here is how its usage might look from within a form request:

Usage

To use a field rule set in a form request:

To use a field rule set in a form request where it might require the whole request data context:

This is necessary when applying validation rules that require the greater context of the request that needs to be validated. For example, if you wish to use the confirmed validation rule, then the object needs to be able to access all of the request attributes and their values. Simply pass that data into the constructor.

To use a field rule set except for one or more of the rules:

Resource Rule Sets

A resource rule set is intended to encapsulate all of the rules that go into validating a new or updated resource. It is a collection of attributes and the various rules that should be applied to them in order to validate them. The resource rule set takes some inspiration from Laravel Nova's validation in that they allow users to define "common" rules, creation rules, and update rules. Creation rules and update rules merge in any "common" rules that might be defined.

Making a new resource rule set

The package includes an artisan command to create a new resource rule set.

This resource rule set will have the App\Rules\ResourceRuleSets namespace and will be saved in app/Rules/ResourceRuleSets.

You can also indicate a custom namespace like App\MyResourceRules, for example:

This resource rule set will have the App\MyResourceRules namespace and will be saved in app/MyResourceRules.

In any case, you should wind up with a file that looks similar to this:

One simply fills in the various validation rules for the specific resource. For example:

One can also use field rule sets, any object that implements Illuminate\Contracts\Validation\Rule, or closures. The only thing one must remember to do is to keep each rule as its own element in the arrays.

Usage

To return the resource rule set's "common" rules:

To return the resource rule set's creation rules:

To return the resource rule set's update rules:

To use a resource rule set in a form request that handles storing a new blog post:

To return the resource rule set's "common" rules for an individual field:

To return the resource rule set's creation rules for an individual field:

To return the resource rule set's update rules for an individual field:

Testing

Changelog

Please see CHANGELOG for more information on what has changed recently.

Contributing

Please see CONTRIBUTING for details.

Credits

• Travis Elkins
• All Contributors

License

The MIT License (MIT). Please see License File for more information.