Enable a simple password field in Vuetify. Validating passwords is a repetitive task, but a task nevertheless. But, how do you make sure that the password field is modern and the password complies to pre-defined rules? I don’t quite build super sensitive applications, and tend to use a simple VeeValidate or Vuelidate expression to validate passwords.

Is there really a problem with NPM use? Short answer: no. Long answer: it’s complicated. I am nothing but thankful for the tonnes of NPM packages. I would never have built web applications that could support thousands of users all by myself without all those hundreds of packages. There are thousands of developers (if not millions) who do much better than what I could.

Flatten recursive arrays using Array.flat(). We have seen how to flatten arrays before. Array.flat() is quite useful to flatten arrays in one statement and output a simpler array. But, what about situations where you do not know the depth of array hierarchy - 1 const nums = [[1, 2], [3, 4], [[5], [6]], [[[7]]]]; Fear not.

Remember to filter your arrays before doing array-wise operation. Filtering falsy values must be the first operation even if you do not have specific filtering requirements. Consider this array - 1 const nums = [1, 3, 5, undefined, 7, 9, null]; If you are in control of the data source, you can very well expect to filter only when necessary.

Can you use the Date object without brackets? Yes, apparently - to a friend’s delight and my chagrin. I should know better than to rely on my somewhat shaky Javascript knowledge. This is the format for a sane Date code.. 1 2 3 const today = new Date(); console.log(today); // 2019-08-23T09:31:12.

Why do I use GraphQL? Also, the case for not using GraphQL. You must have seen the previous post where I waxed eloquent about how I mess up my Rest APIs. There was no way I would be satisfied doing that to a single technology stack. Ergo, GraphQL. What is the need for GraphQL?

How not to design Rest services? This is not a theoritical introduction to Rest - there’s something called the ‘Great Internet’ for that. But, what I do want to (cautiously) write about is how I mess up the design principles carefully laid out by smarter people. Practice 1: Use verbs in resource names We typically use the following API names -

Load external scripts asynchronously in Javascript. We have seen about loading functions asynchronously in Javascript. But, what about the scripts that you load from other files, CDNs or other external sources You can do a simple async to load scripts without impacting the loading speed as perceived by the user.

Arguments object throws an error when used with arrow functions. Consider this code - 1 2 3 4 5 6 function getSum() { return arguments[0] + arguments[1]; } console.log(getSum(1, 2)); // 3 The result is as expected. But, you cannot do the same using an arrow function.

Concatenating strings is a fairly simple affair. 1 2 console.log("hello" + " world"); // hello world This works because Javascript figures out the types, thinks that adding strings is not an intelligent thing to do, and therefore, concatenates the two strings. However, it may lead to problems.

Let’s create a simple ‘to do’ application using Svelte and GraphQL. The objective is to demonstrate getting started on a GraphQL query and insert operation in a Svelte component. If you are new to Svelte, you may want to go over what Svelte can do from the official site, or see Svelte quick overview.

The typical Javascript frameworks love playing the middleman. They continue playing that role at development and at run time. Svelte is not your typical middleman - instead the framework lays out the path during build, and completely hands over to standard Javascript at runtime. If that does not pick your interest - I don’t know what will 😜.

Vuetify has been an excellent companion to me. I absolutely suck as a designer. I can hide behind libraries like Vuetify and unleash my web app creativity on this poor planet. So, it was with lot of excitement that I looked forward to Vuetify 2.0, which had been sometime in the making.