Download the PHP package bradietilley/laravel-rules without Composer
On this page you can find all versions of the php package bradietilley/laravel-rules. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download bradietilley/laravel-rules
More information about bradietilley/laravel-rules
Files in bradietilley/laravel-rules
Package laravel-rules
Short Description Fluent rules for form requests in Laravel
License MIT
Informations about the package laravel-rules
Laravel Rules
Rules provides an elegant chainable object-oriented approach to defining rules for Laravel Validation.
Installation
Grab it via composer
Versions
- PHP 8.1 and 8.2 @ Laravel 10 → v1.2.0
- PHP 8.2 and 8.3 @ Laravel 11 → v1.3.0
Documentation
Rules → A quick overview
This produces a ruleset of the following (when passed to a Validator
instance or returned from a your \Illuminate\Foundation\Http\FormRequest->rules()
method):
Rules → Available rules
Every rule you're familiar with in Laravel will work with this package. Each core rule, such as required
, string
, min
, etc, are also available using their respective methods of the same name in camelCase. Parameters for each rule (such as min 3
and max 4
) in digitsBetween:3,4
are made available as method arguments, such as: ->digitsBetween(min: 3, max: 4)
.
The ->rule()
method acts as a catch-all to support any rule you need to chuck in there, such as in the short interim after new rules are added and support is added to this package.
For example:
Rules → Conditional rules
You may specify rules that are conditionally defined. For example, you may wish to make a field required
on create, and sometimes
on update. In this case you may define something like:
The conditional rules that you provide (in the example above: required
and sometimes
) may be of any variable type that is supported by the ->rule()
method (as documented here).
Rules → Reusable rules
The ->with(...)
method in a rule offers you the flexibility you need to specify rule logic that can be re-used wherever you need it.
Here is an example:
The ->with(...)
method accepts any form of callable
, such as
- Closures (e.g.
function () { }
) - Traditional callable notations (e.g.
[$this, 'methodName']
) - First-class callables (e.g.
$this->methodName(...)
) - Invokable classes (e.g. a class with the
__invoke
magic method) - Whatever else PHP defines as
callable
.
Customisation → Macros
This package allows you to define "macros" which can serve as a fluent way to configure common rules.
For example, the following code adds an australianPhoneNumber
method to the Rule
class:
The downside to using Macros is the lack of auto-completion and intellisense. Macros are not for everyone.
Customisation → Custom Rule
class
You may wish to use your own Rule
class to provide your own customisation. This can be achieved by registering your Rule class via your AppServiceProvider
or a similar place.
This allows you to customise any aspect you wish:
About → Benefits
Better syntax
Similar to chaining DB column schema definitions in migrations, this package aims to provide a clean, elegant chaining syntax.
Parameter Insights
When dealing with string-based validation rules such as decimal
, remembering what the available parameters can become a nuisance. As methods, you can get autocompletion and greater insights into the parameters available, along with a quick @link
to the validation rule documentation, to better understand how the validation rule works.
Variable Injection
Instead of concatenating variables in an awkward manner like 'min:'.getMinValue()
you can clearnly inject variables as method arguments like ->min(getMinValue())
Conditional Logic
Easily add validation rules based on conditions, using the ->when()
and ->unless()
methods, as well as by passing in conditional states into methods such as ->requiredIf($this->method() === 'POST')
.
Wide Support of Rules
Not only does it support all core-Laravel rules, but it also supports any custom rule classes that you define.
Fully Customisable
Full customisation using custom rule classes
About → Performance
The performance of this packages varies as does natural PHP execution time. A single validator test that tests a string and integer with varying validity (based on min/max rules) results in a range of -20 microseconds to 20 microseconds difference, with an average of a 14 microsecond delay.
The more the package is utilised in a single request, the less relative overhead is seen. For example, running the same validation rules with 20 varying strings and integers can result in an average of 9 microseconds or even less.
The overhead here is considered negligible.
Side Feature → The ValidationRule
class
An optional, different approach to a typical implementation of the ValidationRule
interface is the BradieTilley\Rules\Validation\ValidationRule
class which hanldes the horrible signature of the Closure $fail
argument and forced void
return type inside the abstract class, allowing your rule classes to ship with cleaner syntax.
To get started, simply extend the BradieTilley\Rules\Validation\ValidationRule
class in your custom rule class. And instead of defining a validate
method, define the run
method.
So instead of this:
You would have this:
Why
Single line failures
Because of the void
return type of the validate
method, you cannot return $fail('Some error message');
in a single line, and if you adhere to any of the common code styles out there you also have to have an empty line before a return;
statement (unless it's the first line in a body). This cleans things up a bit by allowing that clean single line return:
Readability
By enforcing a return type (static
in this case), this forces you to specify at least some form of a response rather than ambiguous empty return;
statements that get used for pass and failure results. Although you could return $this;
, it obviously encourages you to do the right thing and return a result. This improves readability by forcing you to explain the exit result:
Failure syntax
Invoking a method is always visually cleaner than invoking a Closure
variable. This provides a cleaner syntax:
Method signature
The $fail
parameter of the validate
method is messy. It's a Closure
that requires importing at the top, and if you enforce generics in your project, the $fail
parameter requires a type hint that explains any arguments and return types. Removing this type hint means the docblock is purely to say "Run the validation rule." which is superfluous and can be removed too.
Issues
If you spot any issues please feel free to open an Issue and/or PR and I'll address the issues.