DEV Community: Amy Williams

Cleave.js - formatting your input fields on the fly.

Amy Williams — Thu, 12 Sep 2019 18:04:40 +0000

Cleave.js

I’ve recently come across a nifty JavaScript library called Cleave.js and it formats the user’s input in real-time. It’s great in pure JavaScript but can also be used in React and Angular.

In my day-to-day job I often have customer requirements to validate the user input, have a max length on the input, format currency, things like that. I couldn’t believe how quick it is to implement and want to share it.

First, you include the library in your project, given you have an input that you want formatting, you create a new Cleave instance. The first argument is a String containing the selector you want to target, it can handle the following:

ID selector
Class selector
Data attributes
Name attributes
And more …

The second argument passed in is a configurable object which specifies how you want to format the text. You can specify whether its a credit card number, date, telephone, time or plain numeric.

A usage I have recently implemented is formatting a Portuguese number. There currency format uses periods ‘.’ in place where we would have commas ‘,’ for thousands. E.g. 124.545,00
One traditional way of implementing this would be to use string templates and event listeners on the input but with Cleave.js it’s simply this:

Best thing about Cleave.js is that it’s readable, well-written documentation and very flexible. Another use case would be to format an input and once completed, a continue button appears. Luckily for us, there is a ‘onValueChanged’ callback, this is triggered on input change and can obtain the target value. In here, you could validate the length of the value and show/hide the button for example.

If you ever have to format an input in JavaScript, I would highly recommend investigating this library if it’s suitable for your use. Thank you for reading this post, hope this was helpful.

How a learning plan has helped me grow.

Amy Williams — Mon, 01 Apr 2019 18:43:49 +0000

I find it incredibly hard to stay up-to-date with technology rapidly changing, I always feel like I'm swimming upstream against a strong current just to try and stay afloat. Sometimes I feel like giving up and want a career change but I've decided to change my attitude, not focus at what I'm not good at and put a plan in place to become better.

I decided to put a learning plan together, I use Google docs and list all the things I currently don't know about web development. Some are very high level but it's a start. Here is a small preview of it, as currently it's 3 pages long.

Every week, I think about what I have planned and make an hour to do something on my list. So far, I've tried to be consistent and use Tuesdays after work. I call it #TechyTuesday.

To make it easier to learn, I set up a Codepen account where I can access at anytime and just write blogs and do little pens just to learn the things on my list. In the space of a couple of weeks I've learnt/created the following:

ES6 features such as default parameters, template literals, scoped variables
JSON objects and it's functions such as freeze, assign, create, keys
an animated bee all in CSS

By doing this I'm not only enhancing my skills technically but soft skills as well such as:

reading & documentation
understanding and finding quality documentation from MDN
debugging
using developer tools
using markdown

Best part of all, it feels really good obtaining more knowledge, sharing it and crossing it off the list.

So if you're inexperienced or experienced in web development, I recommend creating a plan in small manageable tasks and completing them on a weekly basis.

Does anyone else have a similar way of learning?

Why you should keep a code diary.

Amy Williams — Tue, 26 Mar 2019 17:54:18 +0000

Last year, I was listening to a podcast on JavaScript Jabber and the topic of a code diary was mentioned. A code diary, is simply keeping a record of you’re daily coding habits, exactly like a regular diary but specific to development. It doesn’t matter where you write it paper, text editor, Google docs, etc. Somewhere preferably you can access it at anytime, when you want to jot something down.

You may be wondering why this is useful and what to write in it, so let me explain.

Everyday you write, review, edit or interact with code in any way. Open up your diary and aim to write a sentence or two on the following:

What you learnt during that day
What you liked
What you didn't like

It can be as brief or detailed as you like, I prefer detailed but after all it’s your diary. Now let me expand on each of these points:

What you learnt

Continuous learning is a must in the development industry, everything technical is changing on a rapid basis. It is important to want to learn, not only for yourself but companies want employees who are actively trying to improve themselves.

In my opinion knowledge is power. The more knowledge, the greater responsibility you have to share it with the World. By writing down what you have learnt that day means in future you can come back to reflect, track your progress and also share it with others in the community.

What you liked

You may think this is similar to what you learnt, and in ways they are but I think of it as a way of taking what you have learnt and applying it to your work. When writing or reviewing others code, you may see it written in a slightly different manner and think I want to use that next time. This is what you like, and what you actively try to incorporate in your next piece of work. For example: ES6 Arrow functions, I learnt about it in a Lunch & Learn session in work from a colleague. So I wrote it down and in my next project I worked on, I refactored my work to include these arrow functions.

What you didn't like

You may think this is the easy one to do, as the technical industry can be quite opinionated. What I recommend is not only write down what you didn’t like, write down why you didn’t like and how it could be improved. If this is your own code, you can see the areas of improvement that you can work on.

If it is another’s work, by all means communicate and discuss its implementation but remember there is always a reason as to why it was coded that way. Find that reason out, it will spark a discussion and then by interacting you both have learnt something new.

Have I convinced you yet?

a code diary can be, but it starts with you. You need to make the time and effort to sit down and truly reflect on your activities. It doesn’t have to be daily but when you get into a routine, it is good to reflect and see the areas you can improve on. If in doubt, ask someone who you respect and look up to, to take a look and they can guide you also.

From my own personal experience: I found writing down the different points on a regular basis, kept me focused on my technical skills and what I wanted to achieve. I could start a fresh slate, every day and take what I learnt and apply it the next time. I started researching solutions more to find a practical example and talked to others on different implementations to knowledge share. I even started reflecting on not only technical skills but expanded it to personal skills too. I realised I could improve in my technical skills on a continuous basis but if I don’t work on my personal skills such as communicating with others, I could not achieve my goals that I am aiming for in my career.

This was my first post, I hope you enjoyed and thank you for taking the time to read it.