Doing the Same Thing, Differently

Doing the Same Thing, Differently

So I got a question today on my first post that was basically: why are you doing this? It was phrased in a much nicer way than that. Essentially, I want to blog, and I've heard such great things about "learning in public" so I figured I'd do just that. I figure this blogging will help me, and it just might help somebody else. If nothing else, it allows me an outlet to outline my thoughts and approaches to problem-solving which I find helpful. At any rate, here comes post #2. Watch out!

Different Approaches to the Same Problem

So I was working on the demo form I mentioned in my last post. Often programming is good to break down into a problem-solution format. So what's the problem? I want to get form data and display it in an organized fashion underneath the form. The solution? Well, javascript. But so many ways to attack it!

My first solution involved using an onClick function on the submit button: this works, but it seemed sloppy.

Pros:

  • Easy: can send the onClick function a full set of the form data using HTML

  • Easy: I knew how to do it

  • Easy: Peasy

Cons:

  • Enter presses on the form are uncaught, as are 'other' methods of submitting the form

  • Felt dirty

  • Couldn't use HTML/CSS Validation without extra JS

In all, the cons outweighed the pros, so I switched approaches. I still have the onClick version, but I refactored the code to use submissions and added an eventhandler to handle the submit event. Also easy peasy, but now I could use HTML's 'required' attribute to require fields to be filled out, and the CSS Pseudo-class :out-of-range to highlight if the "Week" field is, well, out of range. A simple red border will suffice.

This brings up my favorite thing about programming:

There's like, eight kajillion ways to do the things

Literally eight kajillion.

But that brings us up to my next point: I got too clever for my own good. I was trying to read the value from my Team Unit radio buttons. How did I do this?

Well, it gives me a NodeList. So, I iterated through the NodeList. I flexed my brain, refactored, and ended up with a SLICK AF little function. I got every element named "teamtypeinput" as a NodeList, used a forEach() on the object, and wrote a callback function that used a ternary operator to alter the value of a variable, 'type' based on whether or not that node happened to be checked.

const getTeamType = () =>
{
    let tt = "";
    let types = document.getElementsByName("teamtypeinput");
    types.forEach(function(node) {tt = (node.checked ? node.value : tt)});
    return tt;
}

Well. That's clever. Or I could've just used...

document.querySelector('input[name="teamtypeinput"]:checked').value;

I outthought myself and wrote a pointless function. querySelector() gave me the way out, but I was 'SO PROUD' of my little ternary callback nonsense that I didn't want to delete it! Of course, I did so, and ideologically it's hard to say that too much is 'wrong' with the first way... except it sucks.

So...

In the end, once you identify your problem, don't be afraid to try different ways to solve it. Switching to onSubmit saved me many lines of code, logical headaches, and made the whole thing just make more sense. Switching to querySelector() saved me an entire function's worth of LoC, optimized things, and made it much easier to read.

That's the beauty of coding: there are so many ways to solve the same problem. Many times we're eager to re-write, but not necessarily re-THINK. Don't fall into that trap.