web-dev-qa-db-fra.com

Vue.js: Meilleure façon d'implémenter MPA (application multi-pages) dans laravel

Je regarde autour de moi depuis un bon moment, mais je n'ai rien eu de convoquant.

Quelle sera la meilleure approche et pratique pour implémenter Vue MPA architecture dans laravel.

Cherché un peu. Mais il n'y a rien qui vous donnera une idée claire. Votre réponse vous aidera beaucoup, veuillez être brève.

Il sera également utile de répondre au point:

  • Est-ce une bonne idée d'utiliser juste laravel comme API de données, et de garder Vue séparé de laravel?
  • Meilleure approche pour la mise en œuvre hybride de SPA et MPA.
javascriptlaraveldesign-patternsvue.jsmultipage
16
Gammer

Quelques options que j'ai déjà utilisées:

Utilisez Laravel pour rendre l'application "vue principale" + connect vue.js.

Fondamentalement, laravel rendra l'application Vue et chaque demande passe par une API.

  1. Facile à installer
  2. Authentification + validation utilisateur est plus facile (vous pouvez utiliser laravel gestionnaire de session pour cela - pas besoin de construire/utiliser des jetons ou autre chose. "Pas besoin de vous soucier de l'état de votre application".)
  3. Facile à "déconnecter" de Laravel - si vous choisissez à l'avenir de découpler l'application SPA.

Utilisez laravel (ou Lumen) uniquement comme API, et sur un autre serveur rendez un SPA.

Cela peut prendre plus de temps, car vous devrez configurer un serveur supplémentaire, préparer une origine croisée, etc.

  1. Aussi facile à configurer, mais peut prendre plus de temps que l'option # 1
  2. Vous devrez créer quelque chose pour la validation des utilisateurs/la gestion des états, etc.
  3. Facile à placer dans laravel, si vous décidez à l'avenir d'utiliser "une seule application".
  4. Peut être plus facile à maintenir/à mettre à l'échelle (si vous avez une équipe frontend, ils n'ont pas besoin de se soucier de laravel - de même pour votre "équipe laravel", ils "n'auront pas besoin de se soucier" l'extrémité avant)

Laravel + Vue = "une application"

Vous pouvez utiliser Laravel pour rendre toutes les vues + vues pour les composants/éléments de la page.

  1. Facile à installer. Vous avez laravel + vuejs, et ils sont déjà prêts à être utilisés ensemble. https://laravel.com/docs/5.5/frontend#writing-vue-components
  2. Pas si facile à découpler. Dans ce cas, vous devrez créer les mêmes vues pour vue.js. Cela peut prendre du temps.
  3. Il s'agit du "développement web traditionnel" (à mon avis). Si je devais démarrer un projet comme celui-ci aujourd'hui, je ne créerais pas toutes les pages dans Vue.js + quelque chose dans Laravel (Contrôleur + nouvelle route) pour rendre cette vue. Si vous faites cela (encore une fois - à mon avis), c'est juste un travail supplémentaire. Si vous êtes inquiet pour le référencement, il existe des "solutions de rechange"/options supplémentaires.

-

Toutes les options sont testables + évolutives.

Cela dépend aussi de la façon dont vous démarrez ( Dois-je m'inquiéter de la façon dont je vais découpler l'application à l'avenir? Laravel + Vue sera pour bon? ), comment votre équipe fonctionnera ( L'équipe front-end a-t-elle vraiment besoin de configurer laravel ou doit-elle seulement se soucier de le code frontal? ), etc.

Je ne sais pas si j'ai répondu à votre question, sinon, veuillez laisser un commentaire.

20
Eduardo Stuart

Vous n'avez rien trouvé de clair car il n'y a vraiment rien d'autre à dire que "ce qui vous convient et les besoins du projet ". Si vous vous êtes retrouvé très incertain, n'hésitez pas à vous lancer dans tout ce qui vous semble logique, puis réajustez la structure lorsque vous gagnez en expérience.

Lisez également des livres sur l'architecture du système, ceux-ci vous aideront beaucoup.

Est-ce une bonne idée d'utiliser juste laravel comme API de données, et de garder Vue séparé de Laravel?

Par cela, je suppose que vous voulez dire un SPA? Honnêtement, si votre demande est petite, je vois que ça va.

Les applications plus importantes ont tendance à être difficiles à maintenir si elles étaient SPA.

Lire: https://medium.com/@NeotericEU/single-page-application-vs-multiple-page-application-2591588efe58

Si vous finissez par utiliser Laravel comme point de terminaison de l'API, alors utilisez la version simplifiée de celui-ci, Lumen , car il est livré sans lame et quelques autres trucs. Lumen est version allégée pour agir comme un point de terminaison API.

Meilleure approche pour la mise en œuvre hybride de SPA et MPA.

D'après mon expérience ayant tenté de construire plus de 4 projets en tant qu'hybrides, voici ce que j'ai trouvé la structure la plus optimale:

Mon exemple portera sur une application qui enregistre les "publications".

1. Utilisez un modèle de conception de référentiel.

Celui-ci vous évitera beaucoup de maux de tête dans la maintenance de votre code et maintiendra un concept DRY (Ne vous répétez pas)) sur votre code.

  • Créez un répertoire App\Repositories\

Créez une nouvelle classe PostsRepository. Celui-ci sera celui qui communique avec la base de données et contient l'essentiel de la logique.

  • Créez le répertoire App\Services\

Créez une nouvelle classe PostsService. Celui-ci aura le PostsRepository dans son constructeur.

La classe de service sera une manipulation prenant la saisie de l'utilisateur, que ce soit à partir du contrôleur Web ou du contrôleur API.

<?php

namespace App\Service;

use App\Repositories\PostsRepository;

class PostsService;
{
    protected $repository;

    public function __construct(PostsRepository $repository)
    {
        $this->repository = $repository;
    }
}
  • Faites une séparation entre les contrôleurs Web et API.

Pour les contrôleurs Web, vous créez le contrôleur comme d'habitude:

php artisan make:controller PostsController

Pour les contrôleurs API, vous créez le contrôleur pour qu'il se trouve dans un dossier Api.

php artisan make:controller Api\PostsController

La dernière commande va créer le répertoire App\Http\Controllers\Api et y placer le contrôleur.

Récapitulation

Nous avons maintenant différents contrôleurs pour renvoyer des résultats appropriés au point de départ (web/api).

Nous avons des services que les deux contrôleurs (web/api) envoient leurs données à valider (et font prendre les mesures par le référentiel).

Exemples:

<?php

namespace App\Http\Controllers;

use App\Service\PostsService;

class PostsController extends Controller
{
  protected $service;

  public function __construct(PostsService $service)
  {
      $this->service = $service;
  }

  public function index()
  {
     /**
     * Instead of returning a Blade view and
     * sending the data to it like:
     *
     *          $posts = $this->service->all();
     *          return views('posts.index', compact('posts'));
     *
     * We go ahead and just return the boilerplate of 
     * our posts page (Blade).
     */
     return view('posts.index');
  }
}

...

<?php

namespace App\Http\Controllers\Api;

use App\Service\PostsService;

class PostsController extends Controller
{
  protected $service;

  public function __construct(PostsService $service)
  {
      $this->service = $service;
  }

  /**
  * Returns all posts.
  *
  * A vue component calls this action via a route.
  */
  public function index()
  {
     $posts = $this->service->all();

     return $posts;
  }

  /**
  * Notice we don't have a store() in our
  * Web controller.
  */
  public function store()
  {
     return $this->service->store();
  }
}

...

<?php

namespace App\Services;

use App\Repositories\PostsRepository;

class PostsService extends Controller
{
  protected $repository;

  public function __construct(PostsRepository $repository)
  {
      $this->repository = $repository;
  }

  public function all()
  {
     $posts = $this->repository->all();

     return $posts;
  }

  public function store()
  {
     $request = request()->except('_token');

     $this->validation($request)->validate();

     return $this->repository->store($request);
  }

  public function validation(array $data)
  {
      return Validator::make($data, [
          'content' => 'required|string|max:255',
          //
      ]);
  }
}

Dans notre PostsRepository, nous appelons en fait des méthodes qui enregistrent les données. Par exemple. Post::insert($request);.

2. Dédiez un groupe d'API

Route::prefix('api/v1')->middleware('auth')->group(function() {

    Route::post('posts/store', 'Api\PostsController@store')->name('api.posts.store');

});

Donner à l'API route une ->name() aide lorsque vous effectuez des tests de phpunit.

3. Vues de la lame

Celles-ci devraient être simplifiées.

views/posts/index.blade.php:

@extends('layouts.app', ['title' => trans('words.posts')])

@section('content')
  <!-- Your usual grid columns and stuff -->
  <div class="columns">
     <div class="column is-6">
         <!-- This comp. can have a modal included. -->
         <new-post-button></new-post-button>
     <div class="column is-6">
          <posts-index-page></posts-index-page>
     </div>
  </div>
@endsection

4. Vue structure.

https://github.com/pablohpsilva/vuejs-component-style-guide

Donc, ces composants Vue pourraient vivre dans resources/assets/js/components/posts/ Où à l'intérieur de /posts/ J'aurais des dossiers intitulés par exemple IndexPage, CreateModal, EditModal avec chaque dossier ayant son .vue et README.md.

J'utiliserais le <posts-index-page> Dans index.blade.php Et je déposerais le <post-create-modal> Et <edit-post-modal> Quand je veux.

Tous les composants vue utiliseront le point de terminaison API que nous avons spécifié dans notre fichier Routes.

9
Shafiq al-Shaar