At this point we have supercharged our IDE environment and setup a default project boilerplate/structure for our future applications. Now it’s time to leverage these optimizations in a new project.
One of the things I see mostly when I work with developers are overly complex components and monolithic features that only become more difficult to work in over time. In this article we will discuss ways to alleviate spaghetti components and make our code more maintainable, extensible and testable.
Proper planning of your application structure removes early bottlenecks. When building out a project, I highly recommend having a mock-up to reference. Even something simple helps with visualization as you start to setup the underlying functionality of your app. …
If you haven’t read Part 1, you can check it out here.
The new vue-cli-3 library has removed the need to maintain complex build patterns and configs. Instead, it allows the developer to focus on creating. It also has less known functionality that can drastically increase your effectiveness. If you do not have vue-cli-3 installed and want to follow-along, you can install it by running:
One of the unsung heroes of the cli is remote presets. These allow you to define an explicit set of plugins and their options when generating a new Vue project. You can even explicitly set versions of these plugins to further define functionality. …
Welcome to our first issue! Below is a curated list of Vuetify resources for the month of January 2019.
Productivity in Vue — Part 1 — Vuetify — Medium — medium.com
How often do you perform the same task every day? I’m willing to bet it’s more than you think. Performing simple actions such as creating properties, watchers or new methods are done over and over…
The next iteration of Vuetify is on the way starting with Buttons and Alerts.
The next minor release in the 1 series includes updates to Sparklines and includes the new Calendar component. …
How often do you perform the same task every day? I’m willing to bet it’s more than you think. Performing simple actions such as creating properties, watchers or new methods are done over and over again as you build your application.
These small actions can add up and create a segment of time that is simply wasted. It should be our goal to do as much as we can with as little as we can.
Efficiency starts with your tool-set. If you have shitty tools, it’s going to be harder to do simple things. Sometimes the tools we do have just need to be dusted off and sometimes we need to try new things. …
In Part 1, I gave a brief overview of the goals and methodologies for v1.1. Since, we have almost completed feature parity with v1.0 and have a great deal of new and exciting things to share.
One of the challenges with input-controls are the sheer number of use-cases developers come up with. Everyone approaches situations differently and the expectation is always a unified interface that simply works. The current implementation was greatly outgrown by the functionality needed in these advanced inputs. We needed to break the components down and build them back up.
We determined that the current structure was causing massive bloat and complexity the more we added. A great example of this is the current
v-select. It was responsible for maintaining the functionality of a single/multi-select as well as autocomplete, combobox and tags. This made writing useful unit tests and making iterative improvements very difficult. …
The team has been quite busy since the release of v1.0 on February 13th. One of those efforts is to rebuild all form components, but in a backwards compatible manner. We also wanted to pave the way for some new components on the horizon, such as the long awaited
v-file-upload , while also giving developers the tools to create their own unique implementations.
Currently, the core functionality for all input-controls derives from a shared mixin called
input.js . When it was initially created, all controls were very basic and were simply duplicating prop definitions.
The first step in abstraction was to create a wrapper component that only contained the required functionality that every input-control has. …
Letter from the Author
When I first started work on Vuetify, it was intended to be a prototyping tool that would allow me to quickly mock-up sites for side projects. I had recently finished work on https://github.com/johnleider/vue-material , a Vue wrapper for the popular MaterializeCSS framework, and I was faced with a decision. In order to take the framework further, I would have to start creating more components. With Vue 2.0 on the horizon, I felt that starting something from scratch would help me better learn and understand the new features and functionality that was coming soon.
With that decision, Vuetify was born, well, Vuetiful at the time. I slowly started creating components and adding functionality week after week until I had built up a pretty solid core. Around this time, another Material Design framework had launched and I was considering using that instead. I loved the progress that I had made, but finding time to work on it was becoming more and more scarce. …