Mobio Technological Solutions Blog

Mobio Solutions

Category Archives: Laravel

Laravel Route Tips to Improve Your Routing

Originally published at laravel-news.com

The Laravel router has a great, well-polished API when you first dive into Laravel as a beginner or newcomer to the framework. What follows is not anything hidden or new, but a few tips that should help you when you’re learning Laravel 5.

The documentation is excellent, and the tips that follow supplement and piece together a few parts that will help you get a quick jumpstart on learning how to use routing in your Laravel applications.

Custom Namespaces

As outlined in the documentation, if you want a group of routes to use a namespace like App\Http\Controllers\Admin, you can define a namespace using the fluent routing API introduced in Laravel 5.4:

Route::namespace('Admin')->group(function () {
    // Controllers Within The "App\Http\Controllers\Admin" Namespace
});

This is exactly the technique used in the RouteServiceProvider found in each Laravel project:

protected function mapWebRoutes()
{
    Route::middleware('web')
         ->namespace($this->namespace)
         ->group(base_path('routes/web.php'));
}

Because the routes/web.php file has a namespace, our Admin namespace relatively.

To create controllers in the App\Http\Controllers\Admin, you can run the following console command:

php artisan make:controller -r Admin/UsersController

Within our previous routing example, our definition might look like this in the routes/web.php file:

Route::namespace('Admin')
    ->prefix('admin')
    ->group(function () {
        Route::resource('users', 'UsersController');
    });

Route Macros

The Router is macroable, which means if you have a group of routes that you want to provide via a package or reusable groups of route definitions, you can define a macro in a service provider.

For example, maybe you have some shopping route for an e-commerce store that you ship as a package, and allow users to override or customize some parts of the routes:

// Inside a service provider boot()

public function boot()
{
    Route::macro('shopRoutes', function ($prefix) {
        Route::group([
            'prefix' => $prefix,
            'middleware' => ['shopping'],
        ], function () {
            Route::get('products/{product}', 'ProductsController@show');
            // ...
        });
    });
}

Then the consumer could call the macro in a new Laravel application within routes/web.php:

collect(config('languages'))->each(function ($language) {
    Route::shopRoutes($language);
});

Or perhaps an alternate implementation might look like:

Route::macro('shopRoutes', function ($languages) {
    Route::group([
        'prefix' => '/{language}',
        'middleware' => ['shopping'],
        'where' => ['language' => implode('|', $languages)],
    ], function () {
        Route::get('products/{product}', 'ProductsController@show');
        // ...
    });
});

The macro examples are abstract, but you get the idea. I would suggest that you only use route macros if it makes sense to your use-case. You’ll know when the timing is right!

Debugging Routes

I appreciate that in a Laravel application, the web.php file (and api.php file) is a self-documenting file about the routes to which my application is capable of responding. I prefer to define every route instead of using resources because I appreciate the documentation aspect of this file.

If you find yourself trying to find a route or debugging all possible defined routes, the artisan route:list command is helpful:

artisan route:list
+--------+----------+----------+------+---------+--------------+
| Domain | Method   | URI      | Name | Action  | Middleware   |
+--------+----------+----------+------+---------+--------------+
|        | GET|HEAD | /        |      | Closure | web          |
|        | GET|HEAD | api/user |      | Closure | api,auth:api |
+--------+----------+----------+------+---------+--------------+

The route:list command is useful to see the name of the route and the attached middleware. Which brings me to the next tip, naming routes.

Named Group Routes

A common convention in Laravel is naming routes, which allows you to easily reference the name of the route and avoid hard-coding the root-relative URI in your templates. In some applications hard-coding the URI is fine, in other cases, the named routes allow the following:

{{ route('admin.users.show', ['user' => $user]) }}
{{-- /admin/users/2 --}}

When you are defining a group of routes, for example, our admin example, you can also prefix the name of the route on the group:

Route::namespace('Admin')
    ->prefix('admin')
    ->name('admin.')
    ->group(function () {
        Route::resource('users', 'UsersController');
    });

The above prefixed name would generate route names like the following for the users resource controller:

  • admin.users.index
  • admin.users.store
  • admin.users.create
  • admin.users.show
  • admin.users.update
  • admin.users.destroy
  • admin.users.edit

Learn More

Read through the entire routing documentation and the resource controllers section of the controllers documentation. I reference the resource controllers section to try and ensure that most of my routes represent a REST verb and for route naming conventions.

Originally published at laravel-news.com

Laravel version 5.5.20 Released

  • Laravel v5.5.20 was tagged yesterday with some testing assertions, route updates, and Blueprint time precision. Multiple changes and fixes were also merged, see the full release notes for details.
  • Among the new features, some TestResponse methods were added for convenience around validation and asserting JSON responses:
  • The assertJsonMissingExact() method, related to the assertJsonMissing() method, fails when all of the JSON attributes exist in the response.
  • Release Highlights
  • Added
    • Added TestResponse::assertJsonMissingExact() (#21881)
    • Added assertValidationErrors() and assertJsonCount() to TestResponse (#21917)
    • Added allOnQueue() and allOnConnection() for job chaining (#21765)
    • Support variadic arguments on fluent Route::middleware() (#21930)
    • Added precision to Blueprint::time() (#21936)
    • Added Router::apiResources() method (#21956)
    • Support graceful handling of SIGTERM in queue workers (#21964)
  • Changed
    • Added “kin” as an uncountable word (#21843)
    • Improved geo spatial support (#21919)
    • Include job name in the MaxAttemptsExcededException (#21941, #21943)
    • Support rendering multiple @verbatim and @php blocks (#21900)
    • Moved InteractsWithRedis to Illuminate\Foundation\Testing (#21967)
    • Don’t bind macro when it is not a Closure (#21980)
    • Check for before() method on policies classes (#21989)
    • Detect lost pgbouncer connections (#21988)
  • Fixed
    • Fixed BroadcastController namespace issue (#21844)
    • Fixed eager loading HasManyThrough relations with custom intermediate and local key (#21902)
    • Use table aliases when calling self-referencing HasManyThrough relation (#21883)
    • Fixed Vue component file name in React present (#21945)
    • Reverted changes to BadMethodException in #20196 (#21929)
  • Courtesy: Laravel Official Blog
  • New Route Methods introduced in Laravel 5.5

    Laravel 5.5 shipped a couple of convenient shortcuts to the Laravel Router class that eliminates the need for creating a controller or closure only to return a simple view or redirect. If you missed them in the release notes, let’s look at them briefly, they are sure to simplify your code and remove a couple of files.
  • The Route::view method
  • The Route::view method eliminates the need for routes that only need a view returned. Instead of using a controller or a closure, you can define a URI and a path to a view file:
  • Read More on Laravel official Page