Tips, Expertise, Articles and Advice from the Pro's for Your Website or Blog to Succeed
CRUD (Create, Read, Update, and Delete) are the basic operations of data storage, and one of the first things you learn as a Laravel developer.
But what happens when you add a Vue.js single-page app as the front-end to this the stack? Suddenly you have to deal with asynchronous CRUD since operations now occur without a page refresh. This will require special attention to ensuring the state of the data is consistent in both the front-end and backends.
ES2015 (aka ES6) is the current specification of the JavaScript language. If you're new to JavaScript or haven't updated your JavaScript knowledge recently, there are a number of new features in ES2015 that make development much better and more enjoyable.
If you're a Vue developer, you'd benefit from learning all these new features. But as a means of triage, you might start with those features that apply to Vue specifically.
A few weeks ago I wrote a tutorial on the new Vue server-side rendering capabilities for Laravel. That tutorial mostly focused on the set up of SSR in a Laravel environment and so I only had time to demonstrate a simple "Hello World" app with no significant features.
Now I want to build on that previous tutorial and demonstrate how to server render a Vue app that includes multiple pages with Vue Router since most of your Laravel projects will have more than one page.
If your Vue single-file components have dependencies, you'll need to handle the dependencies somehow when you unit test the component.
One approach is to install the dependencies in the test environment, but this may overcomplicate your tests.
You may also like: How and Why We Moved to Vue.js
The most common question about unit testing Vue components I see out there is "what exactly should I test?"
While it's possible to test either too much or too little, my observation is that developers will usually err on the side of testing too much. After all, no one wants to be the guy or girl whose under-tested component crashed the app in production.
The challenge of designing a good CLI tool is to balance sensible defaults with the freedom to customize.
One of the best CLI tools I know of is Vue CLI 3. One of its "sensible defaults" is that the source files, e.g. uncompiled components and JavaScript files, will be in a directory called src.
If you're creating an app with Vue.js, you'll most likely want to utilize the best-practice scaffolding provided by Vue CLI 3.
But if the Vue app is the client layer of a full-stack JavaScript app, for example, in a "MEVN" configuration (Mongo, Express, Vue, Node), it's not entirely clear how Vue CLI 3 should be integrated into such a structure.
Processing CSVs, resizing images, converting video...these are all intensive, time-consuming tasks that may take a computer seconds, minutes, or hours to complete.
When the client requests something in a typical web app, the web server is able to handle the request in a few seconds or less. A response is then sent to the client to inform it of the outcome.
If you've fallen in love with Vue.js, you'll be dreaming that your company will add it to their technology stack so you get to work with it every day.
For that to happen, though, you may need to convince certain decision makers in your company to give it a try, be it the CTO or some other stakeholder.