How to handle Vue "el" pointer with multiple layouts (Laravel MPA) - laravel

So i have a laravel application that i built and is live using Laravel without Vue.js. Now, finding out about vue.js and its lightweight + numerous additional features for improved user experience, i have decided to include it and rebuild my app into components with much better reactivity.
The only issue is, with my little research, i found out that the main vue element in the resources/js/app.js points to an #app element in views/layouts/app.blade.php which would be fine if perhaps i had an SPA or and MPA that starts from there.
However, in my implementation i have different layout files for both back end and user section of my app, and i don't know how to go about it ( which element to point the vue object to).
Here's what i would like to have though, if possible. I would want a commons.js to have all my common components and imports and perhaps a [page].js for pages where i would need a bit more.
Thanks in advance!

I figured out how to handle this.
The Vue instance created in the app.js doesn't have to be your only instance. In MPA's you will most like have multiple vue instances, perhaps on per page. To keep my code clean, i kept the dependencies common to my whole application in app.js.
For my portals, each portal has a commons.js which containts dependencies specific to the management of my application and hence dont need to be loaded when the user is surfing my up. I set to bundle with webpack and include in all portal pages.
Furthermore, each page has a page.js which is also bundled and included only page specific dependencies (components etc) and a vue instance for each page.
By using this architecture i reduce the JS needed to be loaded to only the necessary on both portal pages and the main app for users.
Hope this helps someone! Happy coding.

Related

Can I conditionally render Livewire components on my page (as one can in Vue)?

I'm attempting to design a project in Laravel. I ran the following command to initialize the project: "laravel new demo --jet". When prompted to choose between inertia and livewire I chose livewire as I've heard better things about it.
A little back story, I'm about 2-3 weeks into learning Laravel and I've never used livewire before, although I am very familiar with using Javascript and am very experienced with Vue.js. I've looked elsewhere for a solution to my problem but now I'm not quite sure if Laravel even supports exactly what I'm looking for.
TL/DR:
I'm wondering what the best practice would be for rendering child components on a page. I would like to create a dashboard that has several options to choose from on the left side of the page. When a user selects an option, I'd like for a corresponding component to appear in the center of the page. If a user were to select a different option, the original child component would disappear and a new corresponding child component would become visible.
Ideally, I'd like to avoid using the router for this, although that might just be because I'm not entirely comfortable with using it. I do understand it's pretty heavily integrated into the Laravel workflow. As I mentioned, I'm used to using Vue where you can easily integrate JS functionality into your html and use conditional statements to hide/show child components without changing routes.
If anything I've said above is causing any confusion, let me know. Thanks.
P.S. If anyone has any good resources for learning livewire & laravel together please let me know about them! Laracasts has been great but I think Laravel recently updated their auth scaffolding and it's causing some confusion for me.

Web Dev stacks - GONE WILD --- Best Practice Architecture & Deployment?

I've run into a problem that I'm sure many new/junior web developers are facing. Before I state the problem, it's best if I first list the events that drove me to the "issue".
Step 1 - The Front-End:
I followed tutorials which allowed me to create a Vue project using the vue-cli - I now have a nice front-end ready to go, albeit it is in a way "standalone". It sits in its own directory.
Step 2 - The Back-End:
I move on, I start to look at the back-end. Laravel plays well with Vue so I go with it. Once again I follow tutorials, I create a database and an API. Fantastic.
I now have the barebones core elements for a CRUD application. However, the way the back and front end are connected seems to be convoluted (although this may be due to my inexperience and improper understanding).
Solution 1:
Some tutorials insist that the Vue project is "re-created" within the Laravel directories so Laravel is in charge of rendering the views.
Solution 2:
Others, from what I can tell keep them physically separate and have the front-end interact with Laravels API only.
What are the best practices when it comes to stack architecture? Should we aim to bundle the stack together as proposed in solution 1? Is solution 2 even possible or is that due to my misunderstanding? If it is, how is deployment handled?
From my point of experience, both are correct and the answer depends on what you want to build 😀
First, if you have a simple website and you want to make the front-end of it in vue and it is only this one website, you can put it all together and make the frontend in Vue, which is handled by laravel in the backend and you are done.
Second, the step further, is for this case, that you can have several frontends for your project. Example: You have a website and several (native or universal) apps to display your data. In this case, you can build an API, that handles all the logic, all the business secrets, and this stuff, that no one should know in detail. After that, you are free to build any frontend (Vue, native, plain-HTML), whatever) you like, that's the only purpose is to display the data the API gives back (with some little logic in it, of the cause, but the secret business logic is hidden in the API). You can even outsource the generation of an app, so you build the website frontend in Vue and another one can build an ios-app with swift or an android app with kotlin.
Hope, you get the point, the answer is, as often: it depends 😉

Practical use of VueJS with Laravel

I'm starting a new large-scale application and after hearing a lot about VueJS + Laravel combination i thought of using it. I followed Laracasts' Learn Vue 2: Step By Step series and some tutorials to understand how it works.
But have few questions in mind:
Why do we even need to use Vue with Laravel. I understand that we can create component like <user-profile></user-profile> in Vue, and then use it in Laravel Blade. But it looks like over-complication things? Firstly we pass data from controller to blade, and then further pass it to vue. Why do we need to do that?
Laravel and Vue both have their own routing system. Which one to use?
How to structure an app using Laravel + Vue
PS. I'm making an application that will mostly be used on mobile devices.
moved from comment
Why do we even need to use Vue with Laravel.
Although you probably already knew, Vue is just one of many javascript frontend frameworks (libs?) You can consume the data send from the server any way you want. Vue is just the sister-framework of Laravel. The only thing you can probably say as to why they are mentioned together is that you can "talk" (interface) easily between them using json objects. Javascript is meant to make your page interactive, have behaviour. Use it when you need this.
Laravel and Vue both have their own routing system. Which one to use?
Whatever you want, do you want a "single page" (blade) that is rendered in 3 different pages by Vue, say like some kind of Wizard form. It really depends on where you want to put the load. I think you can think of use-cases where client side page rendering would be better, but most of the time server sided will be a great choice.
Single page applications are more snappy (faster) after initial load, but server side rendered applications are better for SEO in general. There are also ways to let a SPA render on the server to improve SEO however. And this we we can keep the discussion going for some while.
How to structure an app using Laravel + Vue
Laravel has already an example vue file under resources/assets/js/app.js. So it is safe to assume you can put everything there.

Combine Backend and Frontend Development with Laravel, Patternlab, Atomic Design and Vue.js

I'm going to launch a new project with this two frameworks (I like):
Laravel 5
Vue.js
The Frontend developer prepares the HTML's in atomic design, generated with patternlab.io.
Now I'm looking how I can integrate the patternlab.io project that I don't have to rewrite all the elements in a blade template.
I found some implementations combining Patternlab & Laravel using TwigBridge, Laratash Laravel extensions.
But I've some thoughts:
In the blade templates there is: logic, conditions, loops,.... If I combine patternlab and laravel then I need to put all this in the patternlab project.
Because of using vue.js I need to add also these tags to the patternlab templates
So I think it's not the best choice to integrate the patternlab.io templates in the laravel project.
My idea was:
Frontend DEV uses patternlab to create the templates
Laravel automatically generates & imports the CSS Stylesheet generated in patternlab
The Backend Developers copy the patternlab - molecules manually in the blade templates and add their own logic
If the Frontend DEV make changes on CSS, it's fine - we'll run in no issues; after rerunning the laravel gulp process to update the css files we have the new updates.
If the Frontend DEV makes some changes on a html structure we need to manually adjust them.
Is there a better solution combining Atomic Design, Vuejs and Laravel? How do you deploy atomic design in your CMS?
In the last three Vue/Laravel projects we've created we'v stopped using PHP as a rendering engine all together and used Vue exclusively. Laravel is still a really great framework for writing business logic and apis in a clean testable way – but we've decided to never use blade again.
Typically the issue you run into when trying to create a JS rendered application with a PHP backend is the lack of server side rendering. To solve this problem I've turned to a new project out of the Vue community, Nuxt.js (I have no affiliation with them, just a happy developer). Nuxt lets you write vue components and have them be both server side rendered, and rendered in the browser after the initial page load.
This allows us to completely decouple all of the rendering responsibilities away from Laravel and keep it in a single location, so no need to do blade and Vue – it's all Vue.
The only downside is that you'll need 2 servers Node.js and PHP.

SPA using DurandalJS and laravel

im trying to create a Single Page Website with DurandalJS in the frontend and Laravel as the Backend. Do you think this is a good Idea?
If yes how would I do the following:
What would your recommendation for the basic interaction between both frameworks be?
Would you rather have all the computation done in JS instead of Laravel sending calculated and styled returns?
How Do I setup Laravels controller in order to only get dynamic Data for, say a Div, instead of a whole page?
How can I adjust the browser URLs?
I hope I was specific enough, thank You in advance.
Laravel does not actually care about what framework you use to build the Frontend. Laravel is just a framework that helps you build your application with. It gives you great advantage with respect to the time spent and effort.
You can use any frontend framework that you want to build your app with. I have actually not used Durandal, but from the first look of it here is my opinion.
Durandal is built on top of jQuery, knockoutJS and requireJS. It also has a MV* architecture in place with support for eventing as well. So you could basically define routes on Laravel and initiate the communication between both the frameworks through events and ajax. Again this completely depends on the functionality that you are building.
In the overall flow of your app, consider Laravel as a Model that just gives data from a source to your app and Durandal as your views and controllers. This way, it will keep your data flow cleaner and easier to build. Computation of your functionality depends on how important and secretive the app is. If there are functionalities/implementations that you need to be secretive about, you can keep it on Laravel and just send computed data to Durandal. If its a web app that you are building, then keeping all implementation on the JS is just a right click away from knowing what and how you have built it. One can just see how the implementation is done just looking at the Javascript source of the web app. If you are building Mobile Device App, then the case is different.
Take a look at Restful Controllers. Will give you an idea on how to setup controllers to return only data. But if you need to return the div itself, then you can make use of the Basic Controllers of Laravel to perform them.
You can setup cleaner routes for the browser URL's. Take a look at Laravel Routing

Resources