DEV Community: ginger

Array methods and when to use them, forEach, map, reduce

ginger — Fri, 17 Nov 2023 20:00:00 +0000

First thing to get out of the way is that each of these methods returns something different.

.forEach only loops through the array it is called on. This means that it returns undefined.

For .map, it returns a new array where each item is the result of the given callback.

The much more complex method, .reduce, can return anything. The return type is determined by the second argument passed and the callback.

Here are some examples:

const iceCreamTypes = [
    'vanilla',
    'chocolate',
    'strawberry',
    'mint'
];

const forEachResult = iceCreamTypes.forEach((type, index) => {
    // Capitalize the icecream names
    iceCreamTypes[index] = type[0].toUpperCase() + type.slice(1);
})

console.log(forEachResult) // undefined

// Add organic types
const newIceCreamTypes = donutPrices.map((type, index) => {
    return type + ' Organic';
});


// Merge the two arrays together in blissful frozen harmony
const finalIceCreamTypes = iceCreamTypes.reduce((allIceCreamTypes, currentIceCreamType, index) => {
    allIceCreamTypes.push(currentIceCreamType);
    allIceCreamTypes.push(newIceCreamTypes[index]);

    return allIceCreamTypes;
}, []);

Why use `.forEach` instead of `for in` or `for of`

Personally, it depends on preference. Call me old fashioned, but I like using for loops. If I need to do some stuff to every item in an array, I'll usually reach for for loops. If I am writing that same for loop everywhere, then it is time to put it in a callback .forEach.

Why use `.map` instead of `for in` or `for of`

Let's say you need to run a callback on each item in an array, but need a new array with the results of each callback. With for of then you would likely end up with something like this:

const itemArr = [...];
const updatedItemArr = [];

for (const item of itemArr) {
    // run some code to alter the item
    updatedItemArr.push(item);
}

But with .map, that example looks more like this:

const itemArr = [...];
const updatedItemArr = itemArr.map((item) => /*run some code to alter the item */);

It is more explicit to me to do it the second way instead of the first.

Why use `.reduce` instead of `.forEach`, `.map`, `for in`, `for of`

The .reduce method is a powerhouse if you know what it can do. For example, I need to make a menu string based on an object that is returned from a database.

const returnedMenuData = [
    {
        name: 'pasta',
        price: 16,
    },
    {
        name: 'burger',
        price: 12,
    },
    {
        name: 'pizza',
        price: 14,
    }
];

const formattedMenuTemplate = returnedMenuData.reduce((templateString, { name, price }) => {
    const newName = name[0].toUpperCase() + name.slice(1);
    const formattedPrice = currencyFormatter.format(price); // Assume this is an Intl.NumberFormat object

    const template = `
        <div class="menu-row">
            <p>${newName}</p>
            <hr />
            <p><small>${formattedPrice}</small></p>
        </div>`

    return templateString + template;
}, '');


MenuElement.insertAdjacentHTML('beforeend', formattedMenuTemplate);

You can see we were able to update each value, convert it into a template, and return the result as a string to be used as a template for our menu.

When you reduce an array, it is easier to perform multiple array methods at once.

const returnedMenuData = [
    {
        name: 'pasta',
        price: 16,
        onSale: false,
    },
    {
        name: 'burger',
        price: 12,
        onSale: true,
    },
    {
        name: 'pizza',
        price: 14,
        onSale: true,
    }
];

const onlyItemsOnSale = returnedMenuData.reduce((templateString, { name, price, onSale }) => {
    if (!onSale) return templateString;

    const newName = name[0].toUpperCase() + name.slice(1);
    const formattedPrice = currencyFormatter.format(price); // Assume this is an Intl.NumberFormat object

    const template = `<div class="menu-row">
        <p>${newName} <b>ON SALE NOW!!</b></p>
        <hr />
        <p>${formattedPrice}</p>
    </div>`
}, '');

OnlyTheSpecialsMenu.insertAdjacentHTML('beforeend', onlyItemsOnSale);

In this example, we've done .filter and .map in a single callback.

That in mind, .reduce should not be the first tool in your tool belt.

In summary

Each method has their own purpose, but knowing when is tough.

Do you have a simple array that you need to loop through? You can use .forEach.

Do you need to get a new array from the results of your callback? You should use .map.

Do you have a complex series of tasks, such as filtering, flattening, and mapping, and doing it all in one function would make life easier? Then it's time you learn .reduce.

Which should you use? Array.from vs. Spread Operator

ginger — Wed, 15 Nov 2023 20:00:00 +0000

I had a conversation with a coworker about the merits of using spread ... vs Array.from. While they look the same on the outside, they work differently.

Iterable vs. Length

If you want to spread something into an array, it needs to have a Symbol.iterator property.

This means that the following Javascript will fail:

const spreadObject = [...{ user: 'jane' }];

Even though this would work:

const user1 = {
    user: 'eloise'
};

const updatedUserInfo = {
    lastLogin: 'today'
};

const user1New = {
    ...user1,
    ...updatedUserInfo
};

The solution would be to add a [Symbol.iterator] generator function to the object, which is honestly not worth it.

Array.from creates an array if the object has either an iterator or .length property.

Built in mapping function

Have you ever seen a snippet like this:

const mappedArray = [...arr].map(item => {
    // do stuff to item
})

Did you know that that creates 2 arrays? Array.from has a built in mapping function though.

const mappedArray = Array.from(arrLike, item => {
    // do stuff to item
})

I find this helps keep things more explicit, especially when you are not using an inline function.

const approveUser = (user) => ({
    ...user,
    approved: user.age > 21
});

const allApprovedSpreadUsers = [...users].map(approveUser).every(user => user.approved);

const allApprovedMappedUsers = Array.from(users, approveUser).every(user => user.approved);

Do you need to care about making that extra array? Probably not, but it is a neat thing to remember.

Which do you use?

I usually reach for Array.from. The spread operator is very useful when getting n arguments from a funciton, and spreading objects into another is priceless.

const mergeUserInfo {
    ...userFromSource1,
    ...userFromSource2
};

function approveMergedUsers(user1, ...otherUsers) {
    // do user stuff
}

Either way, I think Array.from is worth keeping in your tool belt.

Fixing rendering issues with Feedbin using 11ty

ginger — Fri, 10 Nov 2023 05:00:00 +0000

I was notified by a friend that apparently Feedbin's feed was rendering my posts incorrectly.

In my code blocks, nothing was wrapping. All of my heading links were showing (the hashtags at the end of each heading for easy sharing).

What gives?

No idea, here's how I fixed it though.

First thing I had to do was make a filter, aptly named fixForFeedbin. It needs to do 2 things.

1. Remove the heading links
2. Make my code blocks wrap again

So I popped open my .eleventy.js file, and got to work.

Filters in 11ty

I recommend you read up on the 11ty documentation for filters, it is going to be more in depth and valuable in the long run.

If you already know the gist with filters, lets go!

My RSS feed template looks something like this, notice the nunjucks templating:

<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
    <title>{{ meta.title }}</title>
    <subtitle>{{ meta.description }}</subtitle>
    <link href="{{ meta.url }}/feed.xml" rel="self" type="application/atom+xml" />
    <link href="{{ meta.url }}" rel="alternate" type="text/html"/>
    <author>
        <name>{{ meta.title }}</name>
    </author>
    {% if collections.posts %}
    <updated>{{ collections.posts | rssLastUpdatedDate }}</updated>
    {% endif %}
    <id>{{ meta.url }}/</id>
    {%- for post in collections.posts | reverse -%}
    {% set absolutePostUrl %}{{ post.url | url | absoluteUrl(meta.url) }}{% endset %}
        <entry>
            <title>{{ post.data.title }}</title>
            <link href="{{ absolutePostUrl }}"/>
            <updated>{{ post.date | rssDate }}</updated>
            <id>{{ absolutePostUrl }}</id>
            <content type="html"><![CDATA[
                {{ post.templateContent | htmlToAbsoluteUrls(absolutePostUrl) | safe }}
            ]]></content>
        </entry>
    {%- endfor -%}
</feed>

It's got all the SEO goodies in there and an <entry> element for each of my blog posts. Neat!

The problem is in the <content> tag, it is outputing the HTML properly, but Feedbin is stripping out parts of it.

To make things easier, I'm using JSDOM to parse the incoming content and manipulate it. Here's my solution:

function fixForFeedbin(theContent) {
    const theDocument = new JSDOM(theContent);

    // all of my heading links have this class, so if you're copy and pasting, double check your feed.
    const directLinks = theDocument.window.document.querySelectorAll('a.direct-link')

    directLinks.forEach(el => el.remove());

    // The code blocks all have a language class, this excludes ones that don't.
    const preCodeBlocks = theDocument.window.document.querySelectorAll('pre[class] > code[class]');

    // Using CSS we tell the code to wrap when possible
    preCodeBlocks.forEach(el => el.style.whiteSpace = 'pre-wrap');

    const theNewContent = theDocument.window.document.body.innerHTML;

    return theNewContent;
}

JSDOM offers a serialize function on the JSDOM object, but since it serializes the whole document it would mess with our RSS feed. Inserting only the content, it is smooth sailing ahead.

Any edgecases?

I'm sure there will be, I'm already wrenching one together in this post. For now though, this works fine.

A thought about heading links

I do wonder if it is a good idea to remove them entirely and not rework them somehow. I don't imagine they are meaningful inside of an RSS Reader, but if you use them, let me know!

Typescript's enums may not be what you think

ginger — Wed, 08 Nov 2023 20:00:00 +0000

If you're not familiar with what an enum looks like, here you go:

enum Direction {
  Up = 1,
  Down, // 2
  Left, // 3
  Right, // 4
}

References
<p>
    <a href="https://www.typescriptlang.org/docs/handbook/enums.html#reverse-mappings">Enums - TypeScript Handbook</a>
</p>

They act as a collection of constants. This can be useful, especially if you are trying to have incredibly unique keys:

enum DirectiveKeys {
    Skip = '__c_skip_me_',
    Remove = '__c_remove_me_',
    Add = '__c_add_me_'
}

const objectThatShouldBeSkipped = {
    action: DirectiveKeys.Skip
}

Reasons to use them

When using an enum, it locks down the constants while keeping them in a manageable object format:

const DirectiveKeys = {
    Skip: '__c_skip_me_',
    Remove: '__c_remove_me_',
    Add: '__c_add_me_'
}

DirectiveKeys.Skip = 'Whoops, this is still mutable';

const objectThatShouldBeSkipped = {
    action: DirectiveKeys.Skip // will never be skipped
}

When using enum, you are also able to have implied values:

enum ExplicitValues {
    Up = 0,
    Down = 1,
    Right = 2,
    Left = 3
}

Is the same as:

enum ImplicitValues {
    Up,
    Down,
    Right,
    Left
}

Reasons to not use them

They aren't abstracted away. That's right, TypeScript enums are compiled into your code. You can easily say "Well, whatever. It's TypeScript, they know what they're doing." But what they are doing is converting this:

enum Const {
    Up,
    Down,
    Right,
    Left
}

Into this:

var Const;
(function (Const) {
    Const[Const["Up"] = 0] = "Up";
    Const[Const["Down"] = 1] = "Down";
    Const[Const["Right"] = 2] = "Right";
    Const[Const["Left"] = 3] = "Left";
})(Const || (Const = {}));

As someone who is a fan of smaller packages, this was a very frustrating bit of code to find. Converting the enum into an object/const saved hundreds of bytes. Why?

For each enum, there was a snippet of JavaScript like the one above to match.

The generated JavaScript only prevents mutation if TypeScript is present. Otherwise it can be easily overwritten, a main selling point of the enum type.

Here is a vanilla way to generate an enum using a Proxy:

const Enum = (enums) => {
    Object.entries(enums).forEach((enums, [ key, value ]) => {
        enums[value] = key;
        return enums;
    })
    return new Proxy(enums, {
        get(target, key) {
            return target[key];
        },
        removeProperty: () => false,
        set: () => false,
    })
}

This disables the ability to add or remove properties, as well as generating the alternating key value that the TypeScript enum generates.

Another benefit? It's reusable, and doesn't create multiple copies of the same code!

const Directions = Enum({
    Up: 1,
    Down: 2,
    Right: 3,
    Left: 4
});

const Compass = Enum([
    "North",
    "East",
    "South",
    "West"
]);

Wow, production ready code for anyone to use, sweet!

Now hang on.

The difference between my snippet and the code generated by TypeScript is that mine takes advantage of ES6+ features like Proxy. If your target audience doesn't include that, my condolences.

My snippet also doesn't come with the backing of Microsoft and the TypeScript team, meaning that it isn't as battle tested.

The final and most important reason to use the TypeScript enum? They have all the Intellisense benefits. Maybe one day I will work on a type that gives my little function all the same Intellisense goodies.

Until then, do what you want.

Post Script

I think that the code that is generated could probably be updated a little. Like, using an arrow function should be fine.

var Const;
((Const) => {
    Const[Const["Up"] = 0] = "Up";
    Const[Const["Down"] = 1] = "Down";
    Const[Const["Right"] = 2] = "Right";
    Const[Const["Left"] = 3] = "Left";
})(Const || (Const = {}));

The super power that lets you tell TypeScript what is actually happening

ginger — Tue, 31 Oct 2023 18:52:01 +0000

I wrote something like this the other day:

const element = document.querySelector('#aVerySpecifcElement');

element.addEventListener('click', doStuff);

But this wasn't enough for TypeScript. Why? Because when querySelector doesn't find anything, it returns null. That's not Element.

My brain immediately went to fixing it like this:

const element = document.querySelector('#aVerySpecificElement');

if (!!element) {
    element.addEventListener('click', doStuff);
}

You can also use the optional chaining operator ?. to do something similar.

const element = document.querySelector('#aVerySpecificElement');

// if nullish, don't do the next thing
element?.addEventListener('click', doStuff);

But this is caving. This is admitting defeat.

So what gives?

In comes the ! operator. Fun fact, did you know in a time gone by, the ! exclamation mark was called a "bang".

The bang ! operator is like the optional chain, but it tells TypeScript "Actually, I know for A FACT that this is not going to be null or undefined."

const element = document.querySelector('#aVerySpecificElement');

element!.addEventListener('click', doStuff);

No longer do we need to add unnecessary if statements just to appease a compiler.

What if it actually can be undefined?

Then don't use it silly!

If you are asking that question, then don't worry about using it. Let TypeScript whisk your worries away. Then when you're pulling your hair out trying to write a type guard to account for the possibility of null, give it a shot.

References:

The release notes for TypeScript 2.0

How to handle dead code and debugging

ginger — Wed, 21 Oct 2020 12:29:42 +0000

Here’s the situation I found myself in:

Co-worker finds a bug in a plug-in I made for work.
In the process of debugging, I found dead and flimsy code.
I found what was causing the bug
There is a small overlap between the bug and the dead code.

I would have to refactor at least part of the dead code to fix the bug.

But, assuming the bug is not super-critical, what order would you do this in?

Would you remove/refactor code to get a clean canvas, make sure everything still works, and then fix the bug?

Or fix the bug, then clean out the “bad” code?

Or a third option I didn’t think of, I’m interested to hear 😊

Set up Coil with Gridsome

ginger — Thu, 28 May 2020 01:19:41 +0000

Everybody hates ads

and creators hate adblockers...

There must be a middle ground to find. If you're like me, you're likely to lean towards a service like YouTube Red or whatever they're calling it now. You pay a monthly fee, no longer see advertisements, and that monthly fee is spread out evenly among the creators you watch based on view time.

I would argue that this is the most favorable solution out there for bloggers, for these reasons:

Seamless
Sleek
Simple

Seamless:

Why is it seamless? Well, I've already implemented it on my blog here, and you probably didn't know! Nothing has changed. With the Coil extension installed, you'll see it "saturate" and it will notify you that this content is "Web-Monetized". CSS-Tricks is the website featured in the example

This little green speech bubble let's you know your money is being put towards content you like.

Sleek:

I think sleek speaks for itself! I don't have to do anything! I don't have to give them an email, a password, a login, a social, nothing. It's already taken care of.

Simple:

I list simple because of how simple it is for bloggers and developers to implement. So let's go through that real quick here.

When you sign up as a creator with Coil, you have to choose a "Digital Wallet". I'm not a huge fan of online-crypto-whoozy-whatsits, so I signed up with Stronghold.

When you signup through the Coil creator portal, you are asked for the "payment pointer". Follow the instructions on Stronghold, or the digital wallet you signed up with, to get this before moving forward. Got it? Good!

Now its as simple as adding it to the head as a meta tag!

Bish! Bash! Bosh!

Here's mine if you want to confirm it's there: https://frankie.tech/

<meta
  name="monetization"
  content="$pay.stronghold.co/1a19885d42feebf4dc0b9efac6fa2fb3318"
/>

It's just that simple.

Gridsome

But we're developers. Sure we can just manually put things in the head of the index.html, but whats fun about that?! I agree, so here's how I did it with Gridsome. I've followed the guide on the Gridsome website, so do that first then come back.

First, I went into my gridsome.server.js, and add to my site variable:

const site = {
    ...
    monetization: '$pay.stronghold.co/1a19885d42feebf4dc0b9efac6fa2fb3318',
};

Then I load all of that along with all of the other "metadata" site variables using this exported function:

module.exports = function(api) {
    api.loadSource(async (store) => {
        for (let [key, value] of Object.entries(site)) {
            store.addMetadata(key, value);
        }
    });
};

Next, I opened up App.vue and added a static-query:

<static-query>
query {
    metadata {
        ...
        monetization
    }
}
</static-query>

<script>
export default {
    metaInfo() {
        return {
            meta: [
                ...
                {
                    key: 'monetization',
                    name: 'monetization',
                    content: this.$static.metadata.monetization,
                },
            ],
        };
    },
};
</script>

Now whenever Gridsome generates your site/blog/whatever, this monetization link will be automatically put in the head of your site.

Thats it! Seamless! Sleek! Simple! I hope more people will adopt technologies like Coil and that the Web-Monetization API is adopted into the Web Standards.

Some other relevant links:
CSS Tricks Article
Web Monetization in Vue App by Jasmin Virdi

Ways to control flow...

ginger — Thu, 05 Sep 2019 23:28:18 +0000

Today, I'm gonna talk about how to control the flow of your code. Since I'm more of a JavaScript developer, all of the examples are going to be in JavaScript.

When I started up as a self taught developer, the first thing I was taught about was if and else. This is the simplest of control options. It usually shakes out to something like...

let a = 10;

if (a >= 10) {
  alert('yippee');
} else {
  alert("guess it's not quite 10");
}
/* will alert 'yippee' */

I'm sure this is something several beginner/junior developers have seen before.

My step 2 was the Conditional Operator, or Ternary Operator. This is a short hand for the above example.

let a = 11;

a === 10 ? alert('heck yeah!') : alert('whomp whomp');
/* will alert 'whomp whomp' */

I like this because of how clear and succinct it is. It is useful in situations where all you need to check is if a statement is or isn't.

But it's important to know when you should use one. A switch statement is always going to be better at being a switch statement than other control flow methods. For example, you can nest an if else if you need to, but if you start nesting Ternary Operators without care, things are going to get hairy really quickly .

The final one I learned about is called a Short Circuit Evaluation. This is probably the most succinct of flow control. I think I once heard it described as more of a glitch than an intended feature.

let a = 10;

/* If true, evaluate next statement */
a === 10 && alert('* air horn noise *');
/* If false, evaluate next statement */
a === 10 || alert('* slowly dying air horn noise *');
/* will alert '* air horn noise *' */

This works because a conditional statement, anything that tests for a logic outcome, returns true or false (or undefined or any other number of options, but lets ignore that for now). By placing && after one of these conditions, the "computer" sees that as 'if the last thing evaluated to true, you need to evaluate the next statement.'

The inverse of this, ||, will basically try the opposite. If the statement you just evaluated was false, you need to evaluate the next statement.

This is really nice for some of the functional programming I've done recently.

function runIfMoreThanTen(num) {
    return num > 10 && alert('woohoo');
}

What I'm basically saying is, 'As long as num is more than 10, run the alert, otherwise return false.'

So essentially I wrote this:

function runIfMoreThanTen(num) {
    if (num > 10) {
        return alert('woohoo');
    }
    return false;
}

Which one is better? It doesn't matter. I have had coworkers who love code golfing, which I have dabbled in myself, and will use Short Circuit all the time. When I'm on the job, I don't think it is helpful to use things like Short Circuit. It requires a little more brain power and raises the barrier to entry for you codeb-ase. There are use cases, it's useful in React (or at least that was the first example I saw of it).

I hope that this gave a little bit better of an understanding of how to control flow in simple and succinct ways!

How do you work as much as you’re paid for?

ginger — Wed, 19 Dec 2018 00:10:56 +0000

I have a habit of being a workaholic and taking on too much work. Trying to be smarter than I should be. I spent a lot of time recently simplifying my answers to questions, accepting that a fix is a fix, even if I don’t know why it was broken in the first place. But recently I’ve become a resource to other members on the team. It’s getting in the way of my work though, and I’m not being paid enough, I’m a junior developer not a senior developer.

How do I tell my coworkers to politely not bother me and look at the documentation instead of asking me simple questions?

sometimes you have to build the product the client needs, not the one you want...

ginger — Sat, 01 Dec 2018 01:57:05 +0000

So we had a client with a unique situation. They had a website but their advertising people, who somehow own rights to the website and all that Jazz, basically gave them an ultimatum. Pay us for our services, or else we shut you off at the end of the month.

Seems pretty straight-forward, but the catch was that the advertising firm did fulfill their end of the contract. Long story short, they needed a website.

We mock something up, based on a template we found, gave it to design to make it unique. We were using this as a way to get other clients the same way. Build a couple templates that we can churn and burn relatively quickly, and then each time we do it it will get easier and easier.

I loved this idea! I wanted to go full hog, I wanted to give them every option they could ever imagine. You want a hero element? What size? What color? What header? What content? I gave them everything. Flash forward two weeks, deadline is in two days, it’s time to put in content. I’m fixing up a few things here or there, and I haven’t made the website client ready yet (modx has template variables, which you need to order properly for the front end of the McD to be more legible), but content was getting put in. Oh, and also sometimes the browser just wouldn’t connect to the server.

So this is borderline catastrophe, we check the logs and it’s a couple megabytes, so I’m given the task of parsing that and figuring out what the issue is.

Now I’m not a PHP developer, I would never claim to be. I love JavaScript, I love being able to do synchronous code and a sync code all together. It’s very fun and interesting. Turns out, synchronous code has some weird quirks.

They way our cms parsed the templates, it would render the chunks and snippets first, then the template fields, then logic.

Now I had just built an entire website made of really complex components that worked really well, and they relied on...a lot of logic. Basically, MODx had already built both the snippets and the chunks and now the template field was asking the cms to go back and delete one of those based on the logic.

This caused a bunch of errors, which sadly are not all figured out, and I had to spend all of yesterday and today parsing back through my own code (you best believe I’m gonna be documenting before I start coding on the next template we build) and extracting my beautiful components into less logic based components that MODx could parse in a reasonable fashion.

Did the website go up in time? Well, as of writing this (8:55pm), and considering they’re on west coast time, we’ve still got a couple of hours.

What kills me is that if I had just built the website the clients needed, I would’ve been done weeks ago. Instead I tried to be smart and out think the clients. Check this field, if empty check this field, if that’s empty check this field, so on and so forth. KISS really goes a long way.

Well my dog is whining at me to pay attention to her, but hopefully I learned my lesson.

the time I had to bodge

ginger — Sun, 18 Nov 2018 23:37:26 +0000

At my job we use a cms called modx, which I love; it’s open source, it’s php, and you’re able to make it do a lot of things with very little effort. But the one issue I have with this system is that plugins that exist for it exist in a dichotomy, ‘has documentation’ vs. ‘no documentation’.

A client had a book on teaching, they wanted to include a glossary of all their terms in their website.

Sure, why not?

So we added a plugin called... Glossary. It worked great, not a lot of documentation, but we figured it out still. And then we noticed something weird.

Why was Developmental Difficulties lower than Distance Theory (these aren’t actually related to the client they’re just an example).

For whatever reason, they weren’t sorting in an ascending order. For this client that was gonna be an issue.

I’m not great at php, my few forays into it have been less than successful, but I gave it a shot. I read through some of the code, since like I said, documentation was lacking. But I couldn’t really make heads or tails of it.

Deadline is maybe a week out, and with thanks giving coming up, that means we have like four more days of development left before the site needs to be ready to go live. Another developer found a plugin that would sort them into alphabetical order, but had way less documentation than the first plugin. And we would have to throw out work we had already done on and do it all over again.

So I sat down and spent maybe 15 minutes studying the layout of the page, changed a couple lines of the chunks that the glossary app used, and built a small javascript function to grab all the categories, sort each item in the category, and the. Put them back together as html elements and put it back in place.

All in all, 45 minutes of coding, maybe an hour of total development time.

Is it a perfect solution? No, if someone doesn’t have javascript turned on, it will just say loading indefinitely. Whatever, I’ll fix it on Monday. It’s good enough to go live, and we don’t have to spend anymore man hours on it than we already have. It’s a bodge, it’s a temporary fix. It’s not elegant, its certainly not impervious, but it’s maybe 16 lines of code, and it works and doesn’t break responsiveness, and it saved us maybe 8 hours of rebuilding what we already have. So I’m proud of that!

I’m interested to hear what other bodges people have come up with?