Onze eerste SaaS-applicatie met Vue.js - Hacker Noon
Our first SaaS application using Vue.js
This article was initially published on alka-web.com
In this article, I am going to share with you guys some development practices we adopted while building our first complete Entreprise Software Web Application using Vue.js. We have been through a long nerdy journey crafting Feedier.
In a nutshell, Feedier lets you collect valuable Feedback from your customers. We challenge you to understand your customers and engage with them through our reward and engagement programs. Brand unique & enjoyable surveys. Value, engage, respect & reward your customers! 🚀
Feedier is a marketing tool that lets you gather feedback through intelligent and segmented surveys. Reward, engage…feedier.com
Enough sales talk, let’s dive right in.
Consistency matters
One of Vue.js core features are the object’s lifecycle. These give you utter control over what you want to do or set off, and when you want to.
While building our application, although we had our internal best practices, .vue files making up our app started to get longer, and we could have rapidly lost track. Developers tend to use these hooks differently, for different purposes and would lay them out differently.
For instance, some developers are keen on using the mounted hook for most of their data/API related code, while others would do that in the created hook. So you end up with inconsistency between your files.
That’s when it started to be dreadful for us.
Bottom line? Discuss and agree on how you want to structure your files and use your framework’s features beforehand.
Plan your features ahead
Is your application going to be translated? How are you going to handle the login and safety in your app? How would you design your database? These are question examples you should ask yourself before typing in any code. They are typically the kind of things we tend to implement later down the line, or tend to simply knock out, and by doing that, you increase your likeliness of breaking things. As a rule of thumb, don’t put these guys off and face them right from the inception!
And don’t trick yourself
If you get started on your first project, your team is most likely made of developers, or in other words, people eager to “build things”, and that would easily tend to forget about the main objectives: getting that application up on the market. It’s easy and attracting to implement stuff as soon as the idea comes in.
But, would your target be interested in such feature? Is it expecting it in the beta version? And are your customers willing to pay for this supposedly ‘awesome’ feature? In other word, would that be a USP?
The further you’re going away from your initial offer, the more you’re delaying your launch date.
One recommendation? Sure, get feedback, add features when everyone is convinced about their usefulness and requirement, but hold back from sinking your team in.
We’ve dragged our development phased on — and it could have been cut way off.
Get yourself up to speed with your tools
When working on a team project, because you’re using one tool doesn’t necessarily mean that you get a grasp over it. Maybe it comes from a teammates, maybe you used to be comfortable with it but haven’t used it in a while, whatever is your the reason, you need to get yourself up to speed!
Most of today’s modern tools are getting updated so often that we tend to miss important and stunning new features.
The point is, read the doc again, be comfortable, it will save you time on the long run. Instead of rustling up a workaround, or looking for a solution in the doc, you will be confident from the beginning on.
Just to give you an example, at the beginning of our Feedier journey, we almost missed the Events Bus at the outset, so we were kinda coming up with our solution. And then we found out about that, so we changed everything. Worth doing it, but still, it could have saved us some hassles to do it from scratch.
Forget about console.log
Just shedding some lights into the available alternatives and why you would ditch your favorite console.log trick.
Again, Vue offers its stunning development tool — Vue.js devtools — available on Chrome and Firefox. This plugin gives you extreme flexibility and definitely cut the development time back! Among other, it gives you the ability to tweak data value, navigate straight to the Vue.js component from the DOM inspector, flick through the different Events, and, first and foremost, gives you the data and computed properties values.
For instance, while building our onboarding widgets, instead of fiddling with our API to mock some data and make sure the onboarded attribute was always false, we simply had to change its value in the browser. Easy peasy!
Toggling a boolean or change a data relying on a bunch of conditions, events and some API calls becomes a no-brainer.
Besides this, Webpack is also great when it comes to debugging. By simply using the eval-source-map property in your dev config, you get all of your .vue components available in the Browser and the right line mentioned when there is an error cropping up. One click, and you jump to the line, even though everything is bundled and compiled under the hood. Gorgeous, isn’t it?
Suffice it to say, you have everything you need for a decent working environment. You “just” have to build.
Plan and lay out your code architecture
As most modern JS frameworks, Vue.js gives you have the ability to split your code into reusable components. This is brilliant, and that’s why before writing any code, you have to ask yourself:
Source: hackernoon.com