DEV Community: Roman Verner

Web Developers, do you recommend building your own portfolio, or paying for an existing service?

Roman Verner — Wed, 21 Apr 2021 13:23:20 +0000

I know that building your own custom-coded website is a great opportunity to showcase your skills, but it's also something you need to maintain moving forward. Is it worth the hassle of maintaining a custom-coded website as opposed to going with a 3rd party provider (such as SquareSpace or Wordpress)?

I'm considering moving to a 3rd party provider as I find maintaining my own website to be more of a distraction from other, more important, work. Before I make the switch I thought I'd see what you wise folks had to say. Thanks!

User Behavior Tracking w/ JavaScript (P2)

Roman Verner — Fri, 05 Mar 2021 18:13:56 +0000

Hello DEV community! It's been a while since my first post on this project. Here is a link in case you missed part one, but if you haven't read the original post, no worries. We're going to rewrite and refactor the original code to better suit our needs moving forward. I took a hiatus from my personal projects after starting a new job, but this project in particular has me excited to start back up again.

Quick Recap:

We're trying to create a front-end JS module that will allow us to track user behavior as it relates to interacting with our online forms. The intent being that we can proactively discover and correct confusing areas in said forms, and improve the overall experience for the end user; however, this isn't the only application of our app. Once we setup a robust tracking system, we can even detect more abstract behaviors, such as an online shopper hovering over the "Purchase" button and hesitating before officially submitting their order.

Refactoring:
It's been a while since the last post so I decided to restart the project and introduce some slightly different and refactored logic. All of this is covered in the embedded video as well as the code snippets below.

Tracking By Element:
The first thing we need to acknowledge is that each HTML element that we want to track has different types of interactivity. For example, users typically can't focus on span elements, since span elements don't contain a way for users to input values. The five main events we'll record are:

To track interactions with button elements we might use mouseover, mouseleave, and click. To track input elements, we might use focus, blur, mouseover, and mouseleave.

Since different elements will use different events to record behavior, we need to create tracking functions specifically tailored to each element. If we discover that we're coding too repetitively, we can refactor down the line. So, let's start with our tracking functions.

Just as we did in the previous post, these functions are going to be contained within an IIFE. Let's outline some of our most important functions.

Code Overview

For the full context behind the functions listed below, please visit the GitHub repository.

HAWK.track(elementId)
This function will take in an element's ID and automatically setup the necessary event listeners for that element type. We can get the element type using the nodeName property, which returns string values such as 'SPAN', 'DIV', etc.. This is one of the first changes as compared to the first post in this series. We are now using the nodeName property. This will allow us to create a controller function called _addListeners that's effectively one big switch statement referencing the specific element type listener functions.



const _track = (id) => {
    let elementRef = _d.getElementById(id);
    let elementType = elementRef.nodeName;
    if (_checkConditions(id, elementType)) {
        _data.trackers[id] = _createTrackObj(id, elementType, elementRef);
        _addListeners(id, elementType, elementRef);
    };
};

_addListeners(elementId, elementReference, nodeName)
This function takes in the element ID, the element's HTML reference (aka the product of document.getElementById()), and the nodeName. Technically we don't need the second and third parameters as we could just reacquire them within the scope of the function, but we already gather that info from the track() function, so it's easier to just pass it down.



const _addListeners = (id, type, reference) => {
    switch (type) {
        case _elTypes.button:
            reference.addEventListener(_eventTypes.c, () => {
                _clickListen(id);
            });
            Object.keys(_eventTypes.m).forEach((key, i) => {
                reference.addEventListener(_eventTypes.m[key], () => {
                    _mouseListen(id, i);
                });
            });
            break;

        case _elTypes.span:
            Object.keys(_eventTypes.m).forEach((key, i) => {
                reference.addEventListener(_eventTypes.m[key], () => {
                    _mouseListen(id, i);
                });
            });
            break;

        case _elTypes.input:
            Object.keys(_eventTypes.m).forEach((key, i) => {
                reference.addEventListener(_eventTypes.m[key], () => {
                    _mouseListen(id, i);
                });
            });
            Object.keys(_eventTypes.fb).forEach((key, i) => {
                reference.addEventListener(_eventTypes.fb[key], () => {
                    _focusListen(id, i);
               });
            });
            break;

        default:
            break;
    };
};

_focusListen, _mouseListen, _clickListen
These functions store the action to be performed on each event. Since every element may require different types of event listeners, we code most of our repetitive code here. This is one of the few areas that I want to re-factor down the line, but I'd rather focus on getting to a minimum viable product first.

Code

romverner / HAWK

HAWK

This repository is setup to run/test right out of the gate. Simply pull the repo, open up the index.html file in your preferred browser, and open up your developer console to interact with the HAWK module. HAWK.results() will console log all tracked events.

Tracking Elements

The HAWK.track function takes in an element ID as its parameter. It will automatically attach any listeners based on what type of element it is. As of the time of this writing, the only tracked elements are SPAN's, INPUT's, and BUTTON's.

View on GitHub

Thank you for taking the time to read my post!

JavaScript Module Pattern (Part 2): Default Module Functionality & Object De-structuring

Roman Verner — Tue, 04 Aug 2020 22:30:18 +0000

I mentioned in a previous post that I've been trying to implement the module pattern to our front-end javascript code at work. And I'm happy to report that so far it's going well. I've made a few discoveries that I thought I'd share!

Default Module Functionality

When I first started learning about the module pattern -- and IIFE's in general -- I never considered the idea of adding default functionality to the newly created modules. In hindsight, now I realize that actually would have been quite useful! If you have a web app that contains many smaller apps within it, it can be tough to bring on new developers if you're not using a framework. Why? Because each app may be coded in an entirely different style -- one issue among many. Remember, one of the main reasons for introducing the module pattern is to begin to standardize.

Anyway, let's get to the code. Let's imagine we have a standard MAIN module from which all other modules will be created. Here, it's written in two different ways to show what's possible:

As you can see, in the first IIFE -- MAIN -- we store our modules in an object and then just point to it in the return object of the MAIN IIFE. In the second IIFE -- MAIN2 --, we actually create a reference to another IIFE in our return object. I prefer the object references of the first method for the sake of simplicity, but the second method allows anonymously scoped functionality to be added to all of our new modules!

Let's now take a look:

As you can see, both methods offer ways to provide default functionality; however, the second method allows us to take that default functionality to a whole new level. By modifying our _createModule function in MAIN2 and adding a second parameter for a file path, we are now opening up the possibility to load module settings as soon as the createModule function is run! No interaction outside of supplying the two parameters to _createModule required! While I still prefer the simplicity of the first method, the second method now allows us to further begin introducing a whole new set of coding standards that will unify our apps from a developers prospective. On top of this, the anonymous scoping and immediately invoked nature of IIFE's has also allowed us to start developing our very own little framework!

Now, bear with me, I only made these discoveries today, so I won't go into any further details until I've had some time to mess around with these concepts. In the meantime, here is one final applied example using a pretend app for Wahoo to help visualize how this organizes your code:

What are your thoughts? I may be biased, but I think that looks neat and tidy!

Object Destructuring Saves Time

Having the ability to add default settings to your modules aside, here's another small tidbit I'd like to share. Remember to de-structure your nested objects for easier access! Given that everything in your modules is in an object, you can just pick and pull what you need.

Anyway, that's all I have to share for now. Hope you found this useful!

Making a User Behavior Tracking App w/ Javascript (P1)

Roman Verner — Thu, 25 Jun 2020 15:44:44 +0000

Welcome! This post has an associated video if you're more inclined to follow along with the actual coding process. Let's outline some general information about the project so you can see if it's something your interested in.

Goal:
To create an application/script that tracks a user's behavior while interacting with an online form.

Purpose:
To detect if any parts of a form take longer to fill out or multiple tries in an effort to determine if there are areas in our forms that could be made clearer.

Applications:
My company works tangentially alongside the healthcare field. Many of our applications have multi-page intake forms that request data/information about clients. With healthcare being as complex as it is, often times there can be miscommunications or unclear directions about which forms need which information. If we could detect where our users are having trouble filling out our forms, we would then be empowered to go in and update the form to make it easier on our users!

Code:
In this first post (and video), we start off with some very simple event listeners. The four events we listen for are

When these events fire, we simply record the relative time at which the event occurred so we can later cross compare between related events. In our case, we are using the performance interface, which stores functionality typically used to acquire performance related information about a user's session. Contained within this interface is the now() function that returns the milliseconds that have gone by since the start of the session. Given that we only care about the length of time a user spends interacting with input elements, this works well for our purposes. It is important to note, the performance.now() function rounds the value to the nearest millisecond, but that is more than accurate enough for our use case.

Here is what our starter code looks like:

const HAWK = (() => {
    let _data = {};

    const _trackTextInput = (elementId) => {
        const _d = document;

        _data[elementId] = {};
        _data[elementId].focusBlur = [[],[]]; // index0 arr = focus
        _data[elementId].mouseOver = [[],[]];

        _d.getElementById(elementId).addEventListener('focus', 
        () => {
                _data[elementId].focusBlur[0].push(performance.now());
        });

        _d.getElementById(elementId).addEventListener('blur', 
        () => {
            _data[elementId].focusBlur[1].push(performance.now());
        });

        _d.getElementById(elementId).addEventListener('mouseover', 
        () => {
            _data[elementId].mouseOver[0].push(performance.now());
        });

        _d.getElementById(elementId).addEventListener('mouseleave', 
        () => {
            _data[elementId].mouseOver[1].push(performance.now());
        });
    };

    const _results = () => {
        console.log(_data);
    };

    // =================================================================
    return {
        trackTextInput(elementId) {
            _trackTextInput(elementId);
        },
        results() {
            _results()
        }
    };
})();

The name 'HAWK' doesn't stand for anything. I just thought it sounded like a fun name to go with for this project. I realize now that it probably sounds a little menacing, but that's not the intent! Haha.

Helpful Resources:

If you're unfamiliar with immediately invoked function expressions (IIFE's), I found this post to be incredibly helpful.
If you'd like to read up on the performance interface and all that it has to offer, MDN is always a great go to.

The JavaScript Module Pattern: What is it? Why is it useful?

Roman Verner — Thu, 28 May 2020 02:53:24 +0000

From my experience, learning JavaScript has been like opening Pandora's box. There are so many topics to study, so many niche functions, that I often lose myself out of curiosity. Sometimes it feels like my time is well spent, and other times it feels like I'm giving in to an inner desire to procrastinate with distractions. Harder still, is finding ways to implement any new knowledge into everyday practice. So I gave it a shot with the module pattern!

I work in several different code bases at my job. One of our largest code bases is a behemoth of a project file, and parsing through some of the front-end can be a little tough at times. Not because any singular person wrote bad code, but because the project was started at a time of change for the department, and certain standards weren't put in place. Standards involving more subtle things like the use of global variables. In an effort to provide a solution for these issues, I decided to research how other companies structure their front ends to keep the code base easier to maintain. First, let's start by listing out the issues we're trying to solve:

Over-reliance on global variables.
Redundant and cumbersome naming conventions for declared functions/variables.
No consistency in styling across the project's javascript files.

While I came across several unique and interesting solutions, the one that stuck the most with me, was the module pattern. I loved it's simplicity in design, and it seemed like the perfect solution for the code-base I was working with at the time.

The Basics

The module pattern is just an organizational structure for your code. The basic premise is that you have one or more global objects that house your application's modules. What does that actually look like? Let's put down some code.

In the spirit of remaining on brand, let's pretend we're making an Animal Crossing themed application called 'Nookbook'. First, we create a new global variable/reference called Nookbook and set it to an Immediately-invoked Function Expression (IIFE). This post won't necessarily focus on how IIFEs work, but if you'd like to read up on them, you can do so on MDN.

const Nookbook = (() => {
    const _modules = {};
    const _createModule = (_moduleName) => {
        ((N) => {
            _modules.moduleName = {};
            N[moduleName] = { get N() {return _modules.moduleName; } };
        })(Nookbook);
    };

    return {
        createModule(moduleName) {
            _createModule(moduleName);
        }
    };
})();

The module pattern works by storing everything in a series of contextual hierarchies that take form through the use of objects. Our Nookbook app could have several modules that one might imagine an Animal Crossing app to have. Such as a 'Marketplace' module, or perhaps a 'Profile' module that contains functionality surrounding user profiles. In those cases, we could create what we refer to as a namespace for those modules by using our createModule function. Notice that it simply calls the _createModule function declared within our IIFE's scope. The typical naming convention for variables declared within an IIFE is to prefix them with underscores in order to differentiate what's scoped to the IIFE and what's not. This is important, since IIFE's are anonymously scoped, their inner properties cannot be accessed unless we interact with them through the return object's methods. To create a module:

Nookbook.createModule('Marketplace');

// This is what our IIFE looks like after running the above fn.
const Nookbook = (() => {
    const _modules = { 
        Marketplace: {} 
    };
    const _createModule = (_moduleName) => {
        ...
    };

    return {
        createModule(moduleName) {
            _createModule(moduleName);
        },
        get Marketplace() {
            return _modules.Marketplace;
        }
    };
})();

Notice we created an object called Marketplace that we're storing in our _modules object. It also adds a method to the return object of Nookbook. The method uses the get syntax to allow us to access the newly created object directly. This line is what creates that getter:

N[moduleName] = { get N() { return _modules.moduleName; }

Here, N is just the alias we gave our Nookbook IIFE. All we are doing is creating a getter for our marketplace object -- the function simply returns the module's object. Now if we want to add functionality to our marketplace, we can simply declare functions in the standard way:

Nookbook.Marketplace.addItem = (itemName, askingPrice) => {
    // ... code here
};

// To call the function:
Nookbook.Marketplace.addItem('Ironwood Kitchenette', 150000);

It's as simple as that!

Benefits

So what exactly are the benefits of structuring your applications around this design pattern? Introducing any design structure, by default introduces standards that will make your code more uniform. In this case, the paths of your functions now contain contextual information. Not only is our code more uniform, it also categorizes and houses information in a more meaningful way:

// Standard function declaration.
function addUserProfile() { ... };
function updateProfileInformation() { ... };

// Object notation is easier to read and provides context.
Nookbook.Profile.add = () => { ... };
Nookbook.Profile.update = () => { ... };

Often times, knowing a function is contained within the Profile module is enough context to understand the functions intent. This means we can start to simplify naming conventions and actually make code more intuitive to read.

Let's keep diving further. Say we want to separate out module-specific constants for things that don't change often -- like file paths. Instead of relying on global variables, we can simply create an object to hold our constants for each module.

// We begin by creating an empty object to hold our constants.
Nookbook.Profile.CONST = {};

// Then we can organize our constants however we like.
Nookbook.Profile.CONST.PATHS = {
    MAIN: '../Profile/main.html',
    FRIENDS: '../Profile/friends.html'
};

// Here's an alternative way of declaring what we wrote above in a more concise way.
Nookbook.Profile.CONST = {
    PATHS: {
        MAIN: '../Profile/main.html',
        FRIENDS: '../Profile/friends.html'
    }
};

This creates an easy to remember location for all of our constant variables. If you design your own naming standards, then you begin to develop more consistency in the long term! In my case, I set the standard that every module has a CONST object holding all of it's constants. Now, no matter which module I'm working in, I always know where all of my constants are declared. Next, let's create some functions that behave in a 'global' manner.

const Nookbook = (() => {
    const _modules = {};
    const _createModule = (_moduleName) => {
        ...
    };

    const _loadPage = (_pageName) => {
        // code that makes a server call for desired file
    };

    return {
        createModule(moduleName) {
            _createModule(moduleName);
        },
        loadPage(pageName) {
            _loadPage(pageName);
        }
    };
})();

In the above example we added a function called loadPage that we're pretending has code that makes a server call for an HTML file. By creating this function in the main Nookbook IIFE, we can think of it as a global function, because it's not contained within any one specific module, and every module has access to it:

Nookbook.Profile.loadFriends = () => {
    Nookbook.loadPage(Nookbook.Profile.CONST.PATHS.FRIENDS);
};

We now begin to see how nicely all of this begins to fit together. We call on our new loadPage() function in our module, and we call on our object holding our constants for the page's file path. Everything is incredibly easy to read through, if perhaps verging on being a little verbose.

Drawbacks

Personally, I haven't encountered all too many drawbacks to the module pattern except that it can be complicated to integrate into an existing code-bases. It can also get a little verbose for applications that are incredibly large. If you have modules with several sub-modules, the contextual paths may get a little tedious to work with:

Nookbook.Profile.Wishlist.add = (itemName) => { ... };

Having to type Nookbook.Profile.Wishlist for each function I want to declare for the wishlist sub-module is a little annoying. Fortunately, you could just create local references, such as:

const NPW = Nookbook.Profile.Wishlist;
NPW.add = () => { ... };

The only problem with a reference like this, is that they become global, and thus began to slowly defeat the original purpose of using the module pattern -- at least in my case. I have found that you can often just design the code in a way that relies on more modules and less sub-modules, but it's still a limiting factor. However, since the original goal was to simply lower global variable usage, having these references isn't a big deal. The problem lies with the fact that if your app is being worked on by multiple developers, you need to develop standards for where these global references are declared as early as possible. You wouldn't want developers accidentally declaring references with the same name, but to different modules. Here are two imaginary modules with sub-modules where this could be an issue:

const NPS = Nookbook.Profile.Settings;
const NPS = Nookbook.Pattern.Storage;

If you don't have standards in place to account for this, you could potentially start to run into issues!

Conclusions

I'm still seeing how far I can take this design structure, so I'll keep posting more as I find cool/unique ways to implement and use the module pattern. For now, all I can say, is that it's already beginning to help organize our code and cut down on headaches with overlapping functionality and redundant function names.

If you have any questions, please feel free to ask. If you spotted anything wrong in this post, please let me know so that I may correct it! Also, as I am still learning, I would greatly appreciate hearing your experience and discoveries working with the module pattern!

Update: If you'd like to read more, here is the second post in this series!

Piecing Together Bootcamp Knowledge

Roman Verner — Thu, 14 May 2020 19:12:24 +0000

Perhaps this isn't a unique experience, and everyone faces the same conundrum during their coding careers, but I found the process of graduating a coding bootcamp very jarring. You're thrown into the world having learned, at some foundational level, several new technologies. It's up to you to figure out how to leverage those technologies to create applications that you can grow your portfolio with. How are you supposed to take that newfound knowledge and piece it all together?

Thinking about this would often times make my head spin. I had several ideas for projects, but wasn't sure how feasible they were with my skill-set. After many failed projects, I realized I had to start small and simply re-learn -- this time in greater detail -- the same concepts we learned in bootcamp. In this series of posts, I document that process, and some things I've discovered along the way.

To keep myself motivated, I have chosen a themed app to match my current obsession: Animal Crossing. The goal is simple, create a 'dashboard' that will allow me to view my friend's turnip prices and item wish-lists. The application should use MySQL, Node/Express, and React. If you're interested, follow along! In the next post I'll go over creating a basic boilerplate for the application.

How has your experience been graduating bootcamp?