
Yep, it may sound a bit crazy, but I genuinely have no idea how many of you read my stuff (not that there is much of it).

---

## Have what?

So you may have no idea what I mean when I say 'analytics for my site'; that's cool!

I'd say that the vast majority of websites out there utilise a third-party platform that gives visibility on traffic. To a lot of people, traffic visibility is vital. It can allow decisions to be made based upon real data, rather than guessing.

A lot of platforms offer things like:

- Referrer (Who sent the visitor to your site?)
- What pages were visited?
- How long was spent on each page?
- Did the user click around?
- What device was used?
- Where the user is located?
- Are they a new or returning visitor?

Of course, this list is just an extract of the available metrics.

## So you can see all that information, so why don't you want it?

I understand why many sites out there want to utilise this. However, this is an easy one for me; privacy.

These platforms use a number of ways to identify users and extract data about them. I find the amount of data that is harvested about users is really scary. Sure, just seeing a users location is intimidating enough, they can also pretty accurately report age, gender and even the users' interests.

To gain this kind of information means the user has to have been tracked for a long time, across multiple sites. This enables them to gather data on them as time goes by and build up a dataset.

When a site starts using an analytics platform, they then contribute their visitors' information to the overall data set.

> A little example would be visitors to this site. If I did implement an analytics platform, then every visitor would be marked as visiting a site probably about `Software` - if they had also been to similar blogs. The analytic platforms would begin to know that they indeed had an interest in Software.

Once the data set has built up, it can be used for other purposes such as targeting adverts across different sites.

## But there are privacy-friendly alternatives?

Yep, true! The privacy-friendly platforms don't track users in the same way as traditional platforms but still provide insightful metrics. Of course, the standard analytics platforms expose much more detail in comparison to privacy-friendly platforms.

Personally, the metrics that are on offer, linked with the privacy friendliness is perfect!

But I still do not use them!

## Surely, you're just making excuses now?

By this point, based on what I said above, you're probably thinking that I'm just scared of seeing that I have no traffic!

Nope - not at all; I promise!

After much research about the available platforms, I picked one out. I then, after much thought, decided not to use any. Not down to my lack of traffic, or effort in implementing; it was because I didn't need to.

I don't want to be motivated by traffic! Even if I have zero visitors, I still want to carry on writing relevant content. I want to publish content that helps people. Not that has high visitor counts.

Yep, I could add analytics as it wouldn't hurt, but I don't need to. I'm happy with knowing that my content is out there for people to see, and if they want to read it, they can. Whether I have ten hits per year or ten million, at this stage doesn't matter.

## TL;DR

So long story short is that I don't use analytics for a couple of reasons. When I first started on my website, I picked a privacy friendly provider, but then consciously decided not to implement any analytics. I did this because my traffic metrics don't matter to me. I want to write good content that can help people. I don't want to motivated by numbers.


I don't have analytics on my site


A couple of weeks ago, I ran a quick poll on LinkedIn to see how many engineers were using/had used the built-in Proxy object in JavaScript.

44% of respondents had never heard of it, a further 34% had heard of but never used; leaving only 22% who have ever used it.

---

## What is this <code>Proxy</code> thing?

To save me trying to "reinvent the wheel", it's easier for me to abstract a piece from MDN.

<blockquote cite="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Proxy">
  <p>
    The <code>Proxy</code> object enables you to create a proxy for another object, which can intercept and redefine fundamental operations for that object.
  </p>
</blockquote>

Essentially meaning you can wrap an object and extend an object's functionality easily.

## Okay, what could I do with it?

There's loads of stuff that you can do very quickly. Here's a super quick example that I think demonstrates the functionality well.

Let's say we have an object that holds our feature flag values:

```js
export const featureFlags = {
  ENABLE_FEATURE_A: false,
  ENABLE_FEATURE_B: true,
  ENABLE_FEATURE_C: true,
};
```

and we can use these values across our codebase:

```jsx
import { featureFlags } from ".";

const TestComponent = () => (
  <div>
    {featureFlags.ENABLE_FEATURE_A && <>Feature A is Enabled</>}

    {featureFlags.ENABLE_FEATURE_B && <>Feature B is Enabled</>}
  </div>
);
```

Awesome! We have a simple implementation that shows some stuff based on feature flag values. With this correct component setup, you expect to see something like this:

```html
<div>Feature B is Enabled</div>
```

So, you're probably thinking "how does this relate to <code>Proxy</code>?

Let's say we want to deprecate Feature A, sure we could get rid of the flag all together or leave it to be <code>false</code>. However, in this highly exaggerated example, the developers of the codebase have forgotten about Find and Replace and can't be bothered to go searching if there's anything else still using this old flag.

A <code>Proxy</code> can come to the rescue! We can build a simplistic proxy to send a message somewhere to say that a deprecated feature flag is in use elsewhere.

```js
const flagValues = {
  ENABLE_FEATURE_B: true,
  ENABLE_FEATURE_C: true,
};

export const featureFlags = new Proxy(flagValues, {
  get: (target, prop) => {
    if (!Object.keys(flagValues).includes(prop)) {
      // Send a message here to somewhere to inform engineers
      // that deprecated feature flag is still being used!
    }
    return target[prop] || false;
  },
});
```

Meaning that now any call to <code>featureFlags.ENABLE_FEATURE_A</code> will not only return <code>false</code> instead of undefined, but it will result in a message, to alert people of an old feature flag that is still in use.

Yep, I know! This example is a little exaggerated and is achievable in different ways, but it highlights the power of the <code>Proxy</code> object. There is indeed a lot more on offer rather than just what I have shown here, so it's definitely worth an exploration!

## Can I use it now?

Of course, yes!

Well, kind of yes! If we're talking about Node.js go for it! It's had full support in Node since version 6!

In regards to the browser, there's pretty decent support except for Internet Explorer, unfortunately!

If you do want to use <code>Proxy</code> in production within a browser, I'd certainly recommend checking out the current browser support.

## Wait, but I don't need it!

That's cool! I didn't write this article to say "You should use this!".

Day-to-day, you're unlikely to require <code>Proxy</code>, however now that you know about it, you have an extra tool in your toolbox, just in case!

## I want to learn more!

So, as you've read, this article is a super quick stop introduction. However, there's fantastic documentation and tutorials on advanced usages. I'd recommend starting at the MDN documentation though.

## TL;DR

There's a built-in object in JavaScript that's pretty cool called the <code>Proxy</code> Object.

<blockquote cite="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Proxy">
  <p>
    The <code>Proxy</code> object enables you to create a proxy for another object, which can intercept and redefine fundamental operations for that object.
  </p>
</blockquote>

Day-to-day, you're unlikely to require such functionality, but there may come a time where you do. I've only used it a couple of times, but it's been super useful when I have.


Quick Intro: Proxy object in JavaScript


Hopefully, this small post will benefit just a single person and help make their learning journey just that little bit easier.

I know this is a super apparent topic however over the years, I've seen many developers acquiring new skills by doing fantastic courses and then doing nothing more with their new knowledge.

Now because I'm drinking some right now, I'm going to attempt to make it relate to making a good cup of tea.

## Let's talk about the Tea making for a second

Let's imagine you've never made a cup of tea - if you haven't though, don't worry. Hopefully, you will still see my point.

So, before starting anything, you jump onto an online course. Sorted! Here comes awesome 5-star tea... you'll never drink anything different again!

You start watching an expert tea brewer make that perfect cup of tea with such precision, passion and love. The instructor walks through each step in intricate detail, allowing taking notes and understanding each stage. At the end of the 4 hour course, you have a comprehensive understanding of how to make that perfect cup of tea; feeling certain to do it for the first time.

Heading to the kettle, you're enthusiastic about getting the perfect result... 10 minutes later, PERFECTION! You have that perfect 'cuppa'.

_"Kyran, what are you on about? Show me the code!"_ - Hang in there, we're getting to the good part!

2 weeks pass and you fancy a hot caffeinated drink, hmmm, what could you have? TEA! You know how to make a tea, perfectly now. You'd overlooked a good 'cuppa' until now.

You go ahead and start sipping, wait, there's something not quite right. You've messed it up. You didn't leave the teabag in long enough, you added extra milk and for some crazy reason, you added some coffee granules.

Why? You did this because for the last 2 weeks your mind has been elsewhere, you've overlooked some minor details, and crossed wires with the course you did earlier in the week on making a coffee.

## Forget Tea! How does this associate with code?

You can probably see from the highly exaggerated example above where I'm going with this.

When learning it's so important to build upon the skills that you have learned and keep them fresh until they're embedded and you know the material like the back of your hand.

Just doing a course and then assuming that is it, is going to be a wasted investment, even if you're taking detailed notes.

There are fine details that can be easily missed, not only the how's but the why's and the when's. These are just as necessary. As time goes by, details will fade and eventually, all the time that you spent, has been a waste.

## TL;DR

When learning something new, don't just do an online course and think that there's nothing more to do.

After finishing the course, build on your skills and try them out.

Make sure you have good knowledge of the topic and revisit until you're comfortable and feel confident.


Tip: Build on your skills after completing a course


I didn't think I'd be writing about a simple debugging experience. However, with my recent problems I thought I should share! Today I have spent near enough two hours banging my head against the wall, searching around the web and doubting my existence...

You're probably going to have a little giggle, but if this helps just one person, then it was definitely worth it!

So there I was just working on my little Node project, then I had an idea! It was that idea that cost me two hours and a headache. That little project was a Lambda function that called an endpoint to send an email; super simple! The current implementation was working spot on and had great test coverage. After working through the codebase and adding my feature, I noticed a relatively quick win that would improve the performance of the code (quick wins are always good).

Now, before I started to refactor my code, I just wanted to validate my idea. What's the point of this? Sure, because it's only a simple function, it would be easy to just replace what's currently there, but I wanted something a bit more. I wanted to validate not only the implementation but my understanding of how the receiving API was working.

Ten minutes later, I had a local JS file that I could run and then receive an email! Yay!

But wait, I received another email‽

Undoubtedly just a one-time thing, so just to double-check, I added a simple log and ran it. 2 emails again...

How was this even possible?

I won't bore you with the steps I went through but here's just a couple of things I tried.

- Making a cup of tea, and trying again - Still Broken
- Checking logs to establish if 2 API calls were being received - Yep they sure were
- Reverting my changes and running the old project - STILL BROKEN
- Surely it's a provider issue? Let's check production - Production Works (Phew!)
- Check with other Devs - Well Theirs Works
- Thinking Time...

Then it hit me!

I LEFT JEST WATCH RUNNING!!!

Yep, it was really that simple!

Hold up, Hold up - So what? How does this affect anything at all? Why would Jest running in `watch` mode cause those symptoms?

Because Kyran, you called that 'local JS file' `test.js`. 😱

Yep, yep you did!

The moral of the story... don't create a quick scrap file called `test` and leave Jest running in the background!


Today I Got Confused: By creating a simple JS file!


For many years I've wanted to share my thoughts around many things related to dev and code. Until now, I've always made excuses for myself and never gone for it. Well, here I am!

---

You've probably figured by the title, but I just wanted to collect and sound out my thoughts on building reusable components that, unfortunately, don't tend to be reused effectively.

## Scenario

Here's a scenario that I've fabricated to highlight my point on component reusability. For simplicity, let's assume that no component libraries are being used.

You've been asked to deliver a new feature on a React project. The requirements are:

- On a screen that already exists, a new modal is required
- The modal should appear when the user has visited the site page 3 times
- No need for backend integration, this can be handled locally
- The modal should have a close cross in the top right
- The modal should contain some text and a button in the footer that will also close the modal

### Easiest Approach

Great, a nice easy feature that you could get over the line fairly quickly, with few implications elsewhere.

An uncomplicated implementation of this feature would be to utilise a `useEffect` hook to check a local storage value on page load to see if it's the users third time visiting, if it is, you can set a `useState` hook to a truthy value.

Within the render, you can then conditionally render a simple `div` with the necessary content and button.

A simple `onClick` event of the button that sets the `useState` value to false and then that's functionality complete.

Assuming the tests are adequately written and accessibility has been considered, that's about everything finished for the request.

So you're presumably asking yourself - "Yep, what's wrong with this?"

At the moment, there's nothing wrong with this implementation, however, in the future, this could easily become a pain point.

### Fast forwards

So some time has passed and since our last implementation the code for the modal has been abstracted to an external component and it's now been used in four different places. Great, we have a reusable component that's been reused! Kind of.

There's been a few other features that have now been implemented too. A couple of these being a popup image lightbox and a contact form in a modal that can be opened from any page. You can probably see where I'm going with this...

**Lightbox Modal**

Implemented with just a simple `div` that's conditionally rendered based on a `useState` hook value. This has all the functionality of the lightbox, with just a Close button to the top right of the modal.

**Contact Form Modal**

Implemented with just a simple `div`, again, that's conditionally rendered based on a `useState` hook value. This modal renders a form and a simple Close button to the top left.

### What went wrong?

From the distance at a unit level, everything can appear okay, however, this is far from reality.

What's happened here, albeit exaggerated, is we now have three different implementations, that have been built by three different developers.

This, of course, isn't just the opening and closing of a modal. We also have to consider:

- Unit tests
- Accessibility
- Styling
- User experience
- Development time
- QA time
- Risk

Surely just a modal can't have such an impact? Let's take a quick walk through each point.

**Unit Tests**

We have three different sets of tests that are testing things slightly differently, which naturally decreases confidence as there isn't a single spec for a single piece of functionality.

**Accessibility**

Accessibility is important and if not implemented correctly can impact users. Having three bespoke implementations of a single piece of functionality means there's a higher risk of something being missed.

For example, a bug is raised where an `aria-label` is required, it gets fixed in two places, but one gets missed. A, potentially important, part of the user journey is now impacted.

**Styling**

Because each implementation is slightly different, styles vary slightly. One of the implementations features a `fixed` positioning, whilst the others were accidentally broken on scroll because they used `absolute`.

**User Experience**

Because there are styling, accessibility and implementation variances, this means that the user experience is going to be impacted.

One moment, to exit the modal you use the cross in the top right, the next it's now in the top left. For a user, this can be confusing and frustrating.

**Development & QA Time**

I'm going to combine both of these into one. The building, maintaining, testing and optimising three different implementations is inevitably more pricey than doing it correctly just once.

**Risk**

With all of the above in mind, exposing the codebase to varied implementations can only increase the risk of things going wrong and being more expensive to fix in the future.

### How it could have gone?

The above problems could have been solved easily, just with little upfront planning and preparation. I would have suggested that when the second requirement came for a modal implementation, that it would be an ideal time to split out and abstract consistencies.

Notice how I said the second requirement. I have observed so many times, DRY (Don't repeat yourself) being used prematurely and it can be very painful for a team to develop everything in such an abstract way that never gets used.

Looking across the four implementations we have a clear consistency (of course), the modal functionality. The opening, rendering, closing of a modal box that has some sort of content/feature within it.

This is a perfect example of where the code could have been extracted out of the initial implementation into a generic component that could be reused multiple times. We could have not only taken the implementation of the opening, rendering and closing; but more.

We could have abstracted out the styles, tests, that little cross button in the top right corner, the accessibility features. You get the idea, all of the duplicated code and implementation could be in one single place. Doing this would then have alleviated all the pain points that I outlined above.

Now you can see why I mentioned that the original modal implementation was only semi-reusable. It was heavily tied to a certain bit of functionality that had a very specific case. But the base modal component, couldn't be reused so ended up being duplicated.

## My point

As I mentioned beforehand, the example that I provided above is pretty improbable. However, it does highlight what can happen - hopefully not this exact case.

I have seen so many cases, where components have been copied and pasted and then manipulated to integrate somewhere to offer something else that’s similar, but not the same, leading to headaches further down the line and confusing code.

I’d unquestionably never advocate doing the opposite either, which is prematurely doing these kinds of abstractions. This can and will have its pain points which are equally as challenging.

A lot of this can sound really silly and quite obvious, but it is crazy easy for people to fall into the trap of just rebuilding something rather than abstracting and reutilising.

## TL;DR

There's not only a development gain to making your components reusable, but there's also advantages for your users and the business too; as long as it's not done too early, or too late.

**DRY**

Abstract duplicate implementations into separate, standalone, generic, components.

**But not too early**

Don’t prematurely abstract though; only do it when there’s a necessity for further implementations.

**Plan your implementation**

Splitting out your implementations at different levels has benefits that aren’t just development related.

**Single Responsibility**

Adhering to the single responsibility principle helps isolate units of code and means that the possibility of accidental code duplication is more limited.


I don't have analytics on my site

Quick Intro: Proxy object in JavaScript

Tip: Build on your skills after completing a course

Today I Got Confused: By creating a simple JS file!

Reusable Components... That aren't so reusable!