If you've made it this far, you probably want to know some of the superpowers that Fraction has, right? From here on, things get more interesting, in terms of features. Before diving into the reading, keep in mind that everything you'll see here is directly associated with the Laravel Way, but without resorting to nonsense.
Deferred Actions
As part of Laravel 11, you can trigger deferred actions simply by using the deferred method following the action declaration:
// app/Actions/CreateUser.php
execute('create user', function () {
// ...
})->deferred(name: 'createUser', always: true);Behind the scenes, this will register the action as a deferred action, using the Illuminate\Support\defer function.
The
deferredactions only returnstrue, when executed successfully.
Queued Actions
You can trigger queued actions simply by using the queued method following the action declaration:
// app/Actions/CreateUser.php
execute('create user', function () {
// ...
})->queued(delay: 10, queue: 'actions', connection: 'redis');Behind the scenes, this will register the action to dispatch the Fraction\Jobs\FractionJob job, which will execute the action in the background.
The
queuedactions only returnstrue, when executed successfully.
Rescued Actions
You can trigger rescued actions simply by using the rescued method following the action declaration:
// app/Actions/CreateUser.php
execute('create user', function () {
// ...
})->rescued();Behind the scenes, this will register the action to execute the function inside the rescue Laravel's function, which aims to do not stop the execution of the application in case of an error. You can also pass a default value to the rescued method, which will be returned in case of an error:
// app/Actions/CreateUser.php
execute('create user', function () {
throw new Exception('ops!');
})->rescued(default: false);$result = run('create user'); // falseLogged Actions
Do you, like me, sometimes need to know when an action was executed? With that in mind, you can trigger logged actions simply by using the logged method following the action declaration:
// app/Actions/CreateUser.php
execute('create user', function () {
// ...
})->logged(channel: 'stack');Behind the scenes, this will write a log to the requested channel to help you understand the exact moment the action was performed. The log output will be written as follows:
[2025-05-31 21:04:10] local.INFO: [<app.name>] Action: [<action name>] executed.Keep in mind the log is written right after the process is dispatched, which means the log output does not represent the exact moment the action logic was executed. For situations where you are interacting with deferred or queued actions, you might see a difference between the log time and the actual execution time of the action logic, due to the way these actions are processed.
Ignoring Helpers at Runtime
Now that you've read about helpers, you might be wondering if there's a way to ignore a specific helper to be applied to an action at runtime, am I right? The answer is: yes, you can determine an action as, for example, deferred, but ignore the deferred at runtime:
You don't need to do anything special in the action itself:
// app/Actions/CreateUser.php
execute('create user', function () {
// ...
})->deferred();Since you may still need to perform this action as deferred at any time, you need to interact with the run function to bypass the deferred helper at runtime:
// ...
run('create user', deferred: false); This way, the action will still be logged as a deferred action, but it will not be executed as a deferred action at the runtime you want to avoid. The same applies to the other helpers, such as queued, rescued, logged, and then.
Here is the complete list of options you can use to ignore helpers at runtime:
| Term | What |
|---|---|
deferred: false | To ignore deferred actions |
queued: false | To ignore queued actions |
rescued: false | To ignore rescued actions |
logged: false | To ignore logged actions |
logged: false | To ignore logged actions |
then: false | To ignore hooks |
