A simple, intuitive view hierarchy means spending less time looking for pieces of code and more time being productive. We use this convention:
Generally speaking, when using laravel blade for building a website or web app you will have one general LAYOUT that is common for all your pages, then each PAGE will extend this layout to incorporate specific html code and content and, if needed, page-specific scripts and styles. Also each page may incorporate COMPONENTS that can be reused in other pages.
TIP Check out the useful templates we include in the package for each view layer.
THE @bring DIRECTIVE
Laravel includes a very useful component system that allows code reuse throughout your projects. The vibrant package adds the @bring tag helper to fully maximize its benefits.
To illustrate how to handle dependencies with @bring let's take the example of the bootstrap Popover component. This component depends on three plugins to work: jquery, popper and, of course, bootstrap. The 'traditional way' to call these plugins (via CDN or locally) would be to include them at the main layout. Instead, we will call them at the component level by using a single line of code:
Where 'bootstrap' is the name of a blade file we have created to 'bring' the plugins and dependencies when the component is used. For our bootstrap Popover component example, this package import file will look similar to this:
Note that each plugin has its own dependency file and that is possible and recommended to call packages inside packages. If the requested package was already asked by other component in the same page it won't be requested again. Now, we just need to init our bring engine by calling the @initBring at the beginning of our blade view. As in the template below.
The above sections and stacks are a mandatory convention to make @bring work properly.
TIP Components should bring their own packages, so no need to bring those at the page level.
You can use any view folder you want for your packages files. By default, the CM will look for
custom packages at the path view:
To change the custom packages folder, go to the 'vibrant' file in the config folder and modify the 'bring_imports_blade_path' parameter to your needs.
Similarly, you can pass the blade path of your package imports as a second parameter for @bring
So @bring will look for the package import file at the view path: 'yourApp::any.blade.path.bootstrap'
WORKING WITH VERSIONS
Optionally, you can pass the version parameter with @bring and make it available to the package view. This is useful especially when workong with cdn providers as cdnjs or unpkg. For example, imagine you want to bring Vuejs accepting versions. You simply need to create the package import file as follows:
Note that the '$version' parameter is always set for the import view file, even if the user is not passing the parameter, so you can use it safely. Now you can call the package passing the desired version with the @ symbol.
TIP Some of the most popular packages are included out-of-the-box, so you don't need to create the import files for these. Check the list of included plugins in the 'vibrant/imports' folder.
TURNING OFF @bring
You can easily turn-off @bring If for any reason you prefer managing your dependencies and plugins differently. For this, you can just remove @initBring in your views or do:
Once you do this @bring won't call any dependency anymore.