Forem: Harley Ferguson

The Paradox of a Software Developer

Harley Ferguson — Tue, 19 Jul 2022 11:46:00 +0000

The Paradox

At some point in your journey as a software developer, you’ll reach the paradox.

The paradox is unavoidable and plagues all developers at some point in their career.

Now you may be asking, “What is the paradox?”. It’s this:

→ I feel like I’ve learned so much

→ I feel like I don’t know enough

These two counteracting feelings will take you through mountains and valleys. Moments of “I’m such a great developer and I’m doing so well” quickly followed by “I don’t understand nearly enough and was this the right career choice?”

Both feelings exist simultaneously and both will grow the longer you hone your craft. The more you learn and grow your skillset, the more you’ll become aware of tools, technologies, languages, concepts or frameworks that are out there that you currently know nothing about or have no experience in.

It’s an example of Einstein’s quote, “The more I learn, the more I realize how much I don’t know”.

This paradox is applicable to many aspects in life but particularly as a software developer. The reason being is that our industry evolves and changes at such a rapid pace. Often, as soon as you’ve mastered one framework, there is another one ready to take it’s place.

So how do we overcome the paradox?

I don’t think you can ever truly escape it but I believe there is an approach to help lesson it’s impact and increase your own confidence in your technical abilities.

The approach:

→ Specialize at what you enjoy doing and are good at

→ Obtain a general understanding of other aspects that you fear you don't know enough about

First things first:

Accept that you don't need to be an expert in everything. Don't waste your time trying to understand everything deeply because it's impossible. There is just too much. Rather acknowledge that there is value is knowing a little about everything and a lot about a little.

Java developers don’t need to know the latest changes to C# and frontend developers don’t need to know the crazy in-depth queries that one can write in SQL.

The confidence to overcome the paradox comes in specializing in something that you enjoy and are good at (your niche), followed by having a general understanding of the other things that are out there. The things that you hear about and suddenly have that sinking feeling followed by the thought, "I don't know enough".

Use that feeling to hone in on what you don't know and use it to your advantage. Use the paradox against itself.

Here’s my real world example:

I enjoy and love building frontend applications with backend-as-a-service technologies.

So I specialized in that to increase my technical knowledge and value that I can provide my teams and clients. React, Flutter, Angular, Firebase etc. That’s my niche and that’s what clients pay me for.

I then hear of technologies that send fear down my spine. "Should I know that?". "What if a client asks about that?". That's the paradox kicking in and showing me what I next to need to gain an understanding of.

Recently, it's been things like machine learning, Unity game development, low-code platforms etc. There is huge value in me gaining a good understanding of those things without needing to become a specialist in it.

I simply ask myself these 3 questions when researching something new:

→ What is its purpose?

→ When is it used?

→ How does it work?

We should be able to answer these 3 questions within a couple of minutes of researching. Let’s take machine learning for example:

→ What is its purpose? To allow software applications to become more accurate at predicting outcomes

→ When is it used? In projects that process data to help determine patterns or trends

→ How does it work? It uses algorithms to “learn” information from data without needing to rely on a predetermined equation model

There we go.

In 2 minutes of research, I’ve gained a super high level understanding of machine learning. I don’t know enough about it to go a build a model but luckily that’s not what I specialize in (currently). I have expanded my knowledge to be able to have a conversation about, use it in a sales meeting or identity a use case for it on a project.

Moral of the story:

Specialize in your niche. Generalize in everything else.

Join my newsletter, The 10X Developer, for weekly actionable insights and advice on how to become a better developer.

https://askharley.me/

We Use Flutter And So Should You

Harley Ferguson — Fri, 15 Jan 2021 04:52:43 +0000

^{Photo by Pallavi Wattamwar on Medium.}

If you like to stay on the bleeding edge of software development, then you may have heard of Flutter. If you haven't heard of Flutter, then you're about to find out why it's great and why you should be using it for your mobile app development.

This article isn't designed to directly compare Flutter to every other framework and assign a winner at the end of the day. This is more one man's opinion (who has used a ton of different frameworks and tools for developing mobile applications) on why Flutter is his favourite mobile SDK and why it could be yours.

What is Flutter?

Flutter is a UI SDK (software development kit) created and maintained by Google. Flutter can currently be used to build applications for Android, iOS, Linux, Mac and Windows devices. Flutter was initially released in May of 2017 but only really started getting the attention of the community around 2018. Flutter allows you to write a single code base that can be used to create multiple applications than run natively. Flutter makes use of a programming language called Dart.

What is Dart?

Dart is a programming language made by Google that is used to build Flutter applications. Dart boasts itself to be optimized for building UIs, however, Dart also allows for developers to build HTTP clients and services. This means that you could build a server using Dart as well as a have a single Dart code base that can build a whole host of applications on various platforms.

Some may find it frustrating that they would have to learn a new language in order to make use of Flutter but I'm here to tell you that picking up Dart is far easier than you think. Dart was designed to feel familiar to web developers. What this means is that the syntax and conventions in Dart were heavily inspired by JavaScript. Let's take a bit of language tour to see how simple Dart actually is.

Variables

Dart doesn't require you to provide explicit types as it has type inference.

var title = 'Star Wars';
var year = 1997;
var wasSuccessful = true;

Functions

We don't have to declare the types here but it's suggested to follow this standard when writing functions.

int isEven(int n) {
  if (n % 2 === 0) {
    print("This number is odd.");
  } else {
    print ("This number is even.");
  }
}

Imports

The import keyword is used to access other libraries and files.

// Importing a core library
import 'dart:io';

// Importing an external package library
import 'package:provider/provider.dart';

// Importing local files
import 'package:my_app/src/path/to/the_file.dart
import '..path/to/the_file.dart';

Comments

// This is a single line comment

/// This is multiline comment.
/// This type of comment is usually used in documentation.

/* Occcasionally you may see a comment like this. */

Classes

class Person {
  // class members
  String name;
  int age;

  // Constructor
  Person(this.name, this.age) {
    // initialization code goes here
  }

  // Getter method
  int get personName => name;

  // A method sitting on the class
  bool isLegalAge() {
    if (age > 18) {
      return true;
    } else {
      return false;
    }
  }
}

What makes Flutter so special?

Flutter allows us to build native applications from a single code base. This is a massive pro if you're needing to build a beautiful, scalable application on both iOS and Android but don't have the funding or means to build two separate native applications.

Flutter also make it incredilby simple to either run an emulator locally on your machine or to deploy it to your phone. Other tools require a large amount of setup or require you to learn a CLI while Flutter is close to offering a "plug and play" like feeling to getting your applications onto your devices.

Flutter also has built a very large, active and positive community. There are tons of articles, videos and answered questions about Flutter that will allow you to learn and grow rapidly.

pub.dev is a site that allows you to find and use Dart and Flutter packages. The website is incredibly simple to use and makes finding new or potentially useful packages very easy.

The Flutter community along with the help of pub.dev have really built some truly amazing packages that are available for you to use today. Wether it be for state management or displaying a beautiful confirmation dialog, you'll find it there.

How does Flutter work?

The Flutter docs themselves mention that the team that built the SDK drew great inspiration from React. In this fashion, everything in a Flutter is a widget (much like everything is a component in React). Widgets describe how a view should look based on what state is provided to the widget.

All of the widgets in your Flutter application fit together through a widget tree which defines the hierarchy of your application.

Flutter also makes use of an element tree. The element tree is responsible for holding the widgets after they've been built. This process retains the logical structure of the user interface. Widgets are immutable which means that they cannot remember their relationships with other parent or children widgets. The element tree is also responsible for holding the state objects that stateful widgets require.

What are Stateless and Stateful Widgets?

Stateless widgets do not require any mutable state. They are generally used to describe the UI by using structuring widgets, styling widgets or layout widgets. As they are stateless, everything is final.

Stateful widgets allow us to work with mutable state. Stateful widgets create a stage object (which will be held by the element tree) which has data that can be manipulated. Stateful widgets will inherit the setState() method which can be used to update the state object. Whenever setState() is called, the build() function for that widget will be rerun. This process will compare the new state with the previous state and rerender any changes that the UI needs to make. Once a widget's state has changed, it will mark itself as "dirty" and when the next frame comes along then it'll rerender that widget with the new state's implications.

Another amazing thing about Flutter is that it's designed stateful widgets to have a long life span. Let's think about it: if a parent widget is rerendered with new state then surely any state in child widgets would be lost, right? Wrong. Flutter holds onto the state in the element tree and if the "new" widget that is rerendered is the same type as the previous widget then Flutter will provide that widget with the last value of the state.

What makes Flutter better than something like React Native or Ionic?

It's worth mentioning how incredibly easy to create your first app and get it onto your phone right away. Other frameworks do require more setup to get to that point.

Flutter also boasts an incredibly powerful hot-reload functionality. Most SDKs also offer this but I've personally experienced great inconsistencies when dealing with React Native or Ionic's hot-reload. This ultimately improves the development time because you can very quickly view your changes to the code base without having to constantly reserve the application.

Flutter breaks the shackles introduced by the "JavaScript bridge" and is actually creating an application, not just an app wrapper over a web view (I'm looking at you Ionic). React Native does do a good job of building artifacts by making use of avarious compilers to make sense of the JavaScript code, however, these applications never really feel native. Flutter creates applications that are basically native and they feel that way. Flutter compiles the Dart code into native ARM machine code which gives the apps a native level of performance.

Hopefully this article has given you some insight into Flutter and potentially got you interested enough to give it a go.

We have several workshops on Flutter that start with the basics and progress to more advanced Flutter concepts that are going to be made available to the public. Feel free to give those a watch if you wish to have a further deep dive into Flutter and all of it's awesomeness.

Questioning Modern Web Development

Harley Ferguson — Wed, 26 Aug 2020 17:52:55 +0000

^{Photo by Markus Spiske on Unsplash.}

I personally have a lot of questions about modern web development. Why do we have so many JavaScript frameworks? Where is the web going to be 10 years from now? This article doesn't serve to answer these questions but to rather explore and dive deeper into the abyss.

Why is JavaScript so popular?

Don't get me wrong, JavaScript is personally my favourite language to write code in but I need to remain objective here. Why has this one language taken the world by storm?

The answer is most likely because JavaScript as a language has become so much better in comparison to how it used to be. Initially, a lot of tools and technologies were created to make up for JavaScript's shortcomings but now, like a fine wine, JavaScript has matured. This would have promoted more efforts into working with, exploring and expanding one's knowledge of JavaScript.

Then, we can't ignore that JavaScript is the only language that every browser supports. Let's add the fact that JavaScript can be rendered on client or server side. To the experienced developer, those are reasons enough to use this language but what about new developers?

New developers are far less likely to think of rendering or browser support so why would this language appeal to them? My guess would be because JavaScript is somewhat simple to pick up, easily accessible and allows for pretty much instant gratification with the code you write being executed in your browser.

Then what about developers who are wanting to explore concepts or programming paradigms? Object orientated vs functional? Imperative vs declarative?

JavaScript is a minimalistic language and does not tie you into anything. Languages like C# expect you to go ahead and write object orientated code. Languages like Scala are begging for pure functions and no side effects. JavaScript is agnostic (borderline atheist) and allows you to write the code in whatever convention, approach, paradigm or style you wish. This is a big draw for developers who are starting to expand their knowledge.

All of these factors resulted in millions of developers picking up the language and making it the popular girl at the dance.

Why are there so many JavaScript frameworks?

Long gone are the days of some PHP/Rails/whatever to generate your HTML with some jQuery thrown in the mix. Now we have a plethora of JavaScript libraries to choose from. React, Angular, Vue, Knockout and the list goes on. Every corner has a new framework (or library with it's own ecosystem, such as React) claiming to solve some problems better than other frameworks. Why do we have such a saturated market?

It's pretty simple actually and can be put simply by the infamous, The Notorious B.I.G: Mo Money Mo Problems. To translate this for those who aren't educated on the late 90's rap scene, the increase in JavaScript's popularity meant that more people were using it which would result in more opinions/arguments about how to achieve certain things.

For example, Google wants to build their web applications one way. Facebook wants to build their web applications another way. Google creates Angular. Facebook creates React. Both frameworks achieve the same thing. Both frameworks use the same language. Both frameworks have a legion of developers who have sworn allegiance. Both do some things better or worse than the other. Then Vue comes along and claims to be more progressive than it's competitors and, thusly, the market continues to grow with more options.

I'm all for competition. Competition is what pushes us forward as a species but the great JavaScript Framework war of the 2010s has taken it too far and doesn't seem to be slowing down. We are no longer looking for JavaScript developers in our hiring process. "We're looking for a developer with 2 years React experience coupled with Redux, a developer with 3 years Angular 2+ experience that knows NgRx". This is too much. I'm fully aware that talented developers will be able to translate their skills from one framework to another, however, what of the not-so-talented developers? Hitching your wagon to a single framework is too much of a risk in my opinion.

Not only does every framework have it's own design and architectural patterns but libraries and concepts are now being coupled with that framework. Angular developers are most likely not going to understand the Flux architecture that Redux follows and React developers aren't going to understand Angular's approach to resolvers. Each framework is going deeper and deeper down it's own path and as time passes, the similarities between them begin to thin.

I understand that certain minds will prefer to code in a certain framework. I, for one, am the biggest React fanboy out there. That's probably because I prefer functional code and React encourages writing functional JavaScript. However, the amount of tools, patterns and concepts that I have to learn that only hold water in a React ecosystem is ridiculous.

I don't know what the answer is. Maybe it's a completely open source (not owned by a FAANG company) framework? Maybe it's a framework that allows you to write code either in an object-orientated or a functional fashion? Maybe it's time we just give in and leave the title of "Frontend Developer" behind and take the helm of "React Developer", directly coupling our career and livelihood to the survival of something that is completely outside of our control.

How do we go about bundle splitting?

Time to get a little bit more technical.

As any application grows, so does it's bundle. If you're unfamiliar with how SPA (single paged applications) work, your browser downloads the whole application the first time you visit the website. This is an issue because if a user is only accessing the FAQ of your site, they've still had to download every other page that your site has to offer.

Bundle splitting helps solve this by breaking your code into multiple bundles that can be lazy loaded. In this way, only your FAQ page would be downloaded to the user's browser until the user requests a different page. First problem solved.

The next problem is that you're going to make changes and update your web application. This means that the bundle has changed and potentially the index file that was tracking the lazy loading of your modules has also been changed. This means that users with an outdated bundle will be viewing an outdated version of your website.

In my opinion, the best solution is to create a system that alerts the user that their version of the site is out of date. react-hook-form does this quite nicely by presenting the user with an alert, informing them to update to the latest version.

Even if this process is done tastefully, it's still a very off-putting experience to the average user and is something we need to figure out a better approach to.

Is Server-Side Rendering worth it?

Client side rendering looks something like this: the user navigates to a page which will initially be blank. That page will then be filled with JavaScript. This isn't exactly the best idea because regardless of how fast a client's machine is, the page is blank at some point.

Server-side rendering allows us to run JavaScript frontend code on the backend, which will then fill out the page with HTML. The user loads that page, which has some pre-rendered content and then the JavaScript loads which will make the page interactive. Better, worse? There isn't an initially blank page so maybe it's better? Not exactly.

Using server-side rendering means that your initial render actually provides the user with a dead page. You've now gone and created a Time To Interactive metric which Lighthouse will deduct points for. What a "dead page" means is that the user will see a "Login" button but there won't be any functionality when that button is clicked until the JavaScript has been loaded in. Now you've created more problems. You either have to forget about some interactive elements or spend a lot of time making sure your JavaScript loads before any user would be able to click a button. That doesn't sound like fun work.

SSR also introduces you to another problem: how are you going to go about authenticating your user? You're going to have to forward your cookies, tokens etc to the API for authorization/authentication. This means you could never cache the result either because what the server is going to render is dependent on the user's permissions. On top of this, you need to make a request to the server every time the user requests a new page.

SSR will solve some of your problems but it can introduce you to just as many.

Why must APIs be so infuriating?

APIs are there to bring the frontend to life. Give us the data we need so that we can show it to the world. Such a pure concept but the execution is nothing short of the Red Wedding from Game of Thrones.

For example, a REST API that follows the practice of not coupling too many things is going to result in the frontend having to make multiple requests just to display one page. Get me my permissions but also get me a list of users. Oh, also get me my profile data. Duh.

This is an incredibly annoying and tedious process, yet, I understand and accept it. We can't put all that data into one endpoint because then we're crossing concerns and mixing data objects together on our backend. I understand this and so I make multiple API calls to cater for the backend's philosophies. But what if my frontend philosophy is to not have to make 3 API calls before I'm allowed to even render anything to the user? Will the backend surrender to my frontend's will?

There is a disjoint between backend/APIs and frontend applications. Each have constructed their own way of doing things, best practices and so on. This is done without the other in mind. A backend without a frontend makes for a nearly impossible user experience that would only allow for users who have a good understanding of HTTP requests to be able to make use of the system. A frontend without a backend is just as pointless as a static website without any content.

We have the convention of using JSON so that our frontend doesn't have to care about what language the API is using. But what if it should? What if writing backend code and frontend code to not only work together but to also make each other better, without one compromising for the other, was possible? I'm not just talking about using the same language (JavaScript) to write your backend (Node) and your frontend (React, Angular, Vue, etc). While enjoyable, that doesn't exactly solve the problems of the two ends of our solutions making each other better without making compromises. In a perfect world...

Where will the web be 10 years from now?

I'm not even going to pretend to know the answer to this but I'll give it a go. The enhancements of sites like Wix scare me because potential client could have everything that they need right there, in a nice drag-and-drop UI. Potential clients that want to make use of my deep React knowledge could eventually replace me with something like GPT-3 if it gets to the point that it could seamlessly integrate, build and improve upon your code.

If we all still have jobs 10 years from now, this is how I see it: There will be a need for less developers than currently because of automation, maintenance and general development time will be made easier by new tools. JavaScript will continue to be the most popular languages unless we somehow stumble into a new internet that uses new browsers. Only 1 or 2 of the big 3 (React, Angular, Vue) will survive. The reason being because the sheer amount of extra things you need to know in order to be proficient at one will cause companies to only start developing in one framework. When this happens, it could quickly cause an increase in popularity of one framework and we'll see what happened with JavaScript all over again. I'm personally looking forward to this and my money is on React.

This post may seem pessimistic or negative, but that's not the case. I simply believe that we need to challenge and question everything. Questioning one of the most important inventions in human history and how we continue to build that invention is probably one of the greatest questions we can ask ourselves as web developers.

What is Recoil exactly?

Harley Ferguson — Wed, 29 Jul 2020 17:23:48 +0000

^{Photo by Ali Yilmaz on Unsplash.}

Recoil is new. Like, super new. As in it in version 0.0.10 and it's earliest commit on the public repo is from early May of this year.

Just because it's so new and is listed as "experimental" doesn't mean that we can't look into it and understand why it is so useful.

Why should I use Recoil in the first place?

Good question in this day and age where every corner has a different version of state management.

The Recoil docs themselves outline that React's built in state management is often more than enough, however, there are limitations.

Most state management frameworks require their to be a common ancestor (for mathematicians, a common denominator) where any state is then passed down to all of the lower leaves on the component tree. This is obviously ineffecient and can cause bloatage if one component is only one level lower than the common ancestor while another component is 4 levels lower. You'd have to pass that state into each component just to get it where you want it. This problem however is solved by most state management libraries but it's still something to be aware of.
The React Context API is built into React and solves the above problem. Great, we don't need to run npm i some-state-management-library right? Wrong. The Context API allows you to create global state, yes, but it does not allow you to store more than one value per context instance or have an indefinite number of values in a single context. So the Context API is great for storing if the user is using a dark or light theme but not if you're working with a list of data that could have the length of 0 to n.
Either approach (using React's build in functionality or bringing in another library like Redux) still results in your state having to live very high in your component tree when the component that actually needs the state could be very low. This is a problem because a re-render can become expensive as every component from the top of the tree where the state is defined down to the using component will be re-rendered.

Recoil allows you to create a provider/consumer approach to state management where consumers directly subscribe to a provider's values and re-renders will only occur when the value of a provider changes. This means that we aren't causing unmounts and remounts of our components tree every time we change state. Only the components that subscribe to a specific piece of state will be updated when the value changes.

How is Recoil different from Redux?

Redux follows the Flux architecture which makes use of actions, dispatches, reducers and stores. Data flows from actions, into a dispatcher where a reducer makes sense of what needs to be done before persisting anything to the store.

Recoil is a little simpler. It only has two components: atoms and selectors. Data flows from atoms through selectors and finally to our components.

What are atoms and selectors?

Atoms are units of states. The purpose of the atom is to house our stateful data and allow us to update and subscribe to them. What this means is that whenever an atom is updated to a new value, the components that are subscribed will re-render and be provided with the updated data. You could begin to see how atoms could begin to replace the use the useState() hook that passes down the same data to multiple children from the parents (this is also known as prop drilling).

Selectors are pure functions (a function that has the same return value provided the same input and has no side effects) which either accept atoms or either selectors. Selectors can help us to calculate derived or manipulated data (thusly mitigating the need for a reducer).

How do atoms work?

To declare an atom, we'll need to make use of the atom function from the recoil library.

const countState = atom({
    key: 'countState',
    default: 0
});

You can see here that an atom requires a unique key (generally just the variable name). This key must be globally unique. Atoms also need to be provided a default value.

If we need to read and write an atom from a component, we can make use of the useRecoilState hook. It's incredibly similar to the useState hook.

function Counter() {
    const [count, setCount] = useRecoilState(countState);

    return (
        <h2>{count}</h2>
        <button onClick={() => setCount((count) => count + 1)}>+</button>
    );
}

Other components would now also be able to access the current value the countState atom and would receive updates and re-renders whenever they happened.

How do selectors work?

Selectors are pieces of derived state. If that term is unfamiliar to you, derived state is essentially the resulting output of passing state to a pure function that will then modify the given state in some way (think of how a reducer works in Redux). An example of a derived state would be if you conducted a query to filter an array of data. Let's explore that a little further:

const filteredUsersListState = selector({
    key: 'filteredUsersListState',
    get: ({get}) => {
        const filter = get(currentFilterState);
        const list = get(currentUserListState);

        switch (filter) {
            case: 'Admin':
                return list.filter((user) => user.isAdmin)
            case: 'Other':
                return list.filter((user) => !user.isAdmin)
            default:
                return list;
        }
    }
})

We can see from the above example that we now have a selector which makes use of two other atoms (currentFilterState and currentUserListState). Any time either of those atoms are updated, this selector will then rerun and output the new filtered list. This is because the selector internally keeps track of those pieces of state.

Some things to note:

Selectors can also return multiple values which makes the potential heavy lifting they could do unfathomable.
Simpler applications don't have to make use of selectors if there is no need to have derived state. You could just have atoms and make use of the useRecoilState hook.

What are the common hooks I'd use in Recoil?

useRecoilValue - returns the value for a Recoil state value
useSetRecoilState - returns just a setting function for a Recoil state value
useRecoilState - returns a tuple that mimicks what the useState hook does. The first element is the value and the second element is a setter function for that value.

These are the main 3 hooks that I'd guess would be used most commonly. You can explore the other core hooks here.

Recoil doesn't aim to be the only state management tool you use in your apps. React's built in state hooks as well as the Context API will solve a lot of your problems, however, Recoil will help you to solve the rest of the scenarios without comprising the performance of your application.

That wraps up our basic introduction to what Recoil is. In our next post, we're going to be recreating ShopDrop which we initially built using Redux. If you're familiar with Redux, give that blog post a read so you'll better understand the comparisons between Redux and Recoil's approach to state management.

Writing Cleaner & More Readable Redux

Harley Ferguson — Wed, 29 Jul 2020 17:23:17 +0000

^{Photo by Amanda Jones on Unsplash.}

Writing Redux code can quickly become boilerplately and difficult to understand. This aplies especially on larger projects or when you're needing to update an incredibly nested property.

We can make use of two libraries to very easily adjust your approach while making your code much cleaner and far more readable.

The libraries redux-actions and @reactjs/toolkit are fantastic and can help us to write a lot less Redux code without losing functionality.

redux-actions allows us to rapidly produce generic action creators (as well as create action creators that manipulate the data before returning the action object) while reduxjs/toolkit allows for us to structure our reducers in a different way plus make us of immer. Immer is a library that allows us to write code in a mutable fashion by making use of a proxy state, however, the updates to our store are actually performed immutably.

This describes the flow of immer. You're provided with a draft (or proxy) state that represents the current one. You can then make changes to that draft state. After you're done making changes, that draft state will be persisted to the store as the next state.

Actions

Let's look at our actions.js file from the ShopDrop application we created in the previous blog.

Our actions currently look like this:

export const actionCreators = {
  addToList: data => ({ type: "ADD_TO_LIST", payload: data }),
  addToBasket: data => ({ type: "ADD_TO_BASKET", payload: data }),
  removeItem: data => ({ type: "REMOVE_ITEM", payload: data }),
  clearItems: () => ({ type: "CLEAR_ITEMS" })
};

If we import the redux-actions library into our project using npm i redux-actions, we'll then be able to import the createActions function. Using that function, we can rapidly produce action creators that would be identical to the example you see above.

import { createActions } from "redux-actions";

export const actionCreators = createActions(
  {},
  "ADD_TO_LIST",
  "ADD_TO_BASKET",
  "REMOVE_ITEM",
  "CLEAR_ITEMS"
);

All we need to provide this method is the type of the action (like we normally would) and it'll implicitly build a function that would take data and return that as a payload. The result of the above could would provide is with an actionCreators object that if we were to log, would look like this:

Object {
  addToList: function actionCreator() {}
  addToBasket: function actionCreator() {}
  removeItem: function actionCreator() {}
  clearItems: function actionCreator() {}
}

A function is generated in the form of camel case based on what string literal type we provided to the method.

Note: Check out the API to see how you could perform data manipulation prior to creating the action object.

Reducer

Our previous reducer.js would have looked like this:

const initialState = {
  items: []
};

const addItemToBasket = (array, action) => {
  return array.map((item, index) => {
    if (index !== action.payload) {
      return item;
    }

    return {
      ...item,
      inBasket: true
    };
  });
};

const removeItemFromList = (array, action) => {
  return array.filter((item, index) => index !== action.payload);
};

export default (state = initialState, action) => {
  switch (action.type) {
    case "ADD_TO_LIST":
      return {
        ...state,
        items: [
          ...state.items,
          {
            value: action.payload,
            inBasket: false
          }
        ]
      };
    case "ADD_TO_BASKET":
      return {
        ...state,
        items: addItemToBasket(state.items, action)
      };
    case "REMOVE_ITEM":
      return {
        ...state,
        items: removeItemFromList(state.items, action)
      };
    case "CLEAR_ITEMS": {
      return {
        items: []
      };
    }
    default:
      return state;
  }
};

After importing the new library using npm i reduxjs/toolkit, we could make use of the createReducer function. This function allows us to build a reducer without having to have a switch cache (and thusly mitigating the need for string constants for action types everywhere). The biggest bonus is that this library is a wrapper for immer which means it allows us to make changes mutably.

Our new reducer could look something like this:

import { createReducer } from "@reduxjs/toolkit";
import { actionCreators } from "./actions";

const initialState = {
  items: []
};

export default createReducer(initialState, {
  [actionCreators.addToList]: (state, action) => {
    state.items.push({
      id: state.items.length,
      value: action.payload,
      inBasket: false
    });
  },
  [actionCreators.addToBasket]: (state, action) => {
    state.items[action.payload].inBasket = true;
  },
  [actionCreators.removeItem]: (state, action) => {
    state.items = state.items.filter((item, index) => index !== action.payload);
  },
  [actionCreators.clearItems]: (state, action) => {
    state.items = [];
  }
});

You can see how much easier this makes updating nested properties and also how much easier it is to read. We could go from this:

return {
    ...state,
    first: {
      ...state.first,
      second: {
        ...state.first.second,
        [action.someId]: {
          ...state.first.second[action.someId],
          fourth: action.someValue
        }
      }
    }
  }

to this:

return {
  state.first.second[action.someId].fourth = action.someValue;
}

As usual a CodeSandBox for this project is available here if you want to mess around and dive into the code.

Build a React-Redux Shopping List App

Harley Ferguson — Wed, 29 Jul 2020 17:22:44 +0000

^{Photo by Jessica Lewis on Unsplash.}

If you don't know what Redux is, then go read this before starting so that you have an understanding of the fundamentals.

The Problem

We're needing to build an application that allows users to keep track of their shopping list. Let's call it ShopDrop. ShopDrop needs to meet certain criteria:

Users need to be able to add an item to their shopping list
Users need to be able to mark an item as in their basket
Users need to be able to remove an item from their shopping list
Users need to be able to clear the entire shopping list

That's the basic functionality of what a shopping list is. Now let's look at how we meet these criteria by using Redux to manage our state.

The Product

Above is an image of how I chose to design the user interface.

You'll notice how we have a text input where users can input the shopping item. They can then click the Add button to add that item to their list. They can click the Clear button to remove all items from the list. If the user taps an item, it'll mark that item as in their basket and the colour will change to grey. If they tap the item again, it'll remove that single item from the list.

I'm not going to cover the components I built to faciliate the project because that's not the purpose of this blog. This is purely how I decided to construct my UI. You can implement it however you wish, however, the final parts of this post will demonstrate exactly how I constructed my components.

Actions

Inside the src folder of our project, create another folder called store. We'll create two files in here - actions.js and reducer.js. Go ahead and create the first so long.

// actions.js

export const actionCreators = {
  addToList: data => ({ type: "ADD_TO_LIST", payload: data }),
  addToBasket: data => ({ type: "ADD_TO_BASKET", payload: data }),
  removeItem: data => ({ type: "REMOVE_ITEM", payload: data }),
  clearItems: () => ({ type: "CLEAR_ITEMS" })
};

This is how are action creators must look. We're following the FSA model that we discussed in the previous blog post. We need four (one for each manipulation of the store we need to perform). Notice how the first 3 all take in a payload. That's because they'll need to take in something like the value of the shopping item text or an id of the item to either mark it as in the basket or remove it from the list. The reason clearItems doesn't need any data is because all we'll need to do there is set the array in our store back to an empty array. Therefore, we don't need to pass any data through.

Add Item

Now go ahead and create reducer.js file inside of our store folder. Then let's set up our initial state which should look something like this:

const initialState = {
  items: []
}

Now let's create our reducer and the first action we'd need to handle which is adding a new item to the item array in our store.

export default (state = initialState, action) => {
  switch (action.type) {
    case "ADD_TO_LIST":
      return {
        ...state,
        items: [
          ...state.items,
          {            
            value: action.payload,
            inBasket: false
          }
        ]
      };
    default:
      return state;
  }
};

Since we're only going to export our reducer function from this file, we can use the keywords export default and not have to provide a function name. Our reducer function then takes in the initialState and the current action that's been sent to the store.

Before we dispatch any actions to the store, the value of our store would just be the empty items array. Then as actions start coming in, that value will change to reflect those changes. Don't get confused and think that we're resetting state to the value of initialState each time an action comes into our reducer.

Our ADD_TO_LIST case might look a little confusing if you're new to Redux and immutable update patterns in JavaScript, however, it's fairly simple what's actually going on. When the action.type is of the value ADD_TO_LIST, we'll make use of the spread operator to return the current value of the state and then append a new item to the current state.items array.

This is how we immutably update the state. A summary is that we take the current state value, make our changes immutably and then return that entirely new object which is the set as the new state value.

Clear Items

You may already have an idea on how to handle the functionality for clearing the items:

case "CLEAR_ITEMS": {
      return {
        items: []
      };
    }

Here we've added another case to our reducer and all it has to do is return the new state object with items as an empty array. That's it.

Add Item To Basket

Note: For demonstration purposes, I'm going to be making use of an the index to match our item with the same item in the array. I wouldn't normally condone using indices instead of a unique identifier but for simplicity's sake, let's go with the index.

We've looked at adding an item to the array and then clearing the whole array. Now is where we properly need to think about immutable update patterns. Adding an item to our basket means that we need to reassign the inBasket propety on that item to true.

If you go read the Redux guide to immutable update patterns, you'll see that they mention using a function to handle updating an item in an array that looks like this:

function updateObjectInArray(array, action) {
  return array.map((item, index) => {
    if (index !== action.index) {
      // This isn't the item we care about - keep it as-is
      return item
    }

    // Otherwise, this is the one we want - return an updated value
    return {
      ...item,
      ...action.item
    }
  })
}

Let's follow how the guides tell us to do things (at least in this instance). Add the above function to your reducer.js file but outside of our reducer, however, let's make a slight change so that we're properly updating the inBasket to true. We'll do this in the last return object since that means the indices matched.

    return {
      ...item,
      inBasket: true
    }

This function is only going to be used by our reducer so we don't have to export it.

Our case for marking an item as in our basket would then look like this:

case "ADD_TO_BASKET":
      return {
        ...state,
        items: updateObjectInArray(state.items, action)
      };

We call the updateObjectInArray function and provide it with our items array along with the current action that our reducer is making sense of. The updateObjectInArray function will then return to us the updated items array.

Remove An Item From The List

Again, we can reference the immutable update patterns documentation to see how they suggest remove an item from an array.

The show a couple variations but this is the simplest:

function removeItem(array, action) {
  return array.filter((item, index) => index !== action.index)
}

Once again, let's add that function as a private function to our reducer.js file.

Our REMOVE_ITEM case will then look a little something like this:

case "REMOVE_ITEM":
      return {
        ...state,
        items: removeItemFromList(state.items, action)
      };

Just like our previous case, we're calling off to a function which we provide an array (our items) and the current action. What's returned to use is a new items array with the relevant changes having been made.

Our entire reducer.js file should look something like this:

const initialState = {
  items: []
};

const updateObjectInArray = (array, action) => {
  return array.map((item, index) => {
    if (index !== action.payload) {
      return item;
    }

    return {
      ...item,
      inBasket: true
    };
  });
};

const removeItem = (array, action) => {
  return array.filter((item, index) => index !== action.payload);
};

export default (state = initialState, action) => {
  switch (action.type) {
    case "ADD_TO_LIST":
      return {
        ...state,
        items: [
          ...state.items,
          {            
            value: action.payload,
            inBasket: false
          }
        ]
      };
    case "ADD_TO_BASKET":
      return {
        ...state,
        items: updateObjectInArray(state.items, action)
      };
    case "REMOVE_ITEM":
      return {
        ...state,
        items: removeItem(state.items, action)
      };
    case "CLEAR_ITEMS": {
      return {
        items: []
      };
    }
    default:
      return state;
  }
};

Add Item Component

Now is the part where we would actually need to build our component that is going to dispatch our actions. For adding an item, all you'll need is an input that keeps track of the value and a button that when clicked, will dispatch an addToList action with the current value of the input. Let's save time and implement the clearing items functionality here too.

Using hooks and the react-redux library, you can import dispatch and then just wrap any of your action creators method in dispatch. Your component could end up looking something like this:

import React, { useState } from "react";
import { Button } from "react-bootstrap";
import { useDispatch } from "react-redux";
import { actionCreators } from "../../store/actions";

export default function AddItem() {
  const dispatch = useDispatch();
  const [input, setInput] = useState("");

  const handleInputChange = event => {
    return setInput(event.target.value);
  };

  const handleSubmit = () => {
    dispatch(actionCreators.addToList(input));
    setInput("");
  };

  const handleClear = () => {
    dispatch(actionCreators.clearItems());
  };

  return (
    <div>
      <input
        className="input"
        placeholder="Add item..."
        value={input}
        onChange={handleInputChange}
      />
      <Button className="button" variant="outline-dark" onClick={handleSubmit}>
        Add
      </Button>
      <Button className="button" variant="outline-dark" onClick={handleClear}>
        Clear
      </Button>
    </div>
  );
}

We've setup the input and make use of the useState hook to track and clear that value. The handleInputChange simply updates that value on each JavaScript event that is emitted with each key press. We then have two buttons for our two operations. Each button has a handler method that just dispatches the relevant action (which we import from our /store/actions file).

Viewing The Shopping List

Now let's build a componentt to display our current list of items as well as provide us with an interface in which to mark the items as either in our basket or removed.

Again we'll import our action creators as well as useDispatch from the react-redux library but we'll also import useSelector from the same library. useSelector is a selector hook that allows us to get values out of the store.

import React from "react";
import { ListGroup } from "react-bootstrap";
import { useDispatch, useSelector } from "react-redux";
import { actionCreators } from "../../store/actions";

export default function ShoppingList() {
  const dispatch = useDispatch();
  const items = useSelector(state => state.items);

  const addItemToBasket = index => {
    dispatch(actionCreators.addToBasket(index));
  };

  const removeItemFromList = index => {
    dispatch(actionCreators.removeItem(index));
  };

  return (
    <ListGroup className="m-4" variant="flush">
      {items.map((item, index) => {
        return item.inBasket ? (
          <ListGroup.Item
            key={index}
            variant="dark"
            onClick={() => removeItemFromList(index)}
          >
            {item.value}
          </ListGroup.Item>
        ) : (
          <ListGroup.Item
            key={index}
            variant="danger"
            onClick={() => addItemToBasket(index)}
          >
            {item.value}
          </ListGroup.Item>
        );
      })}
    </ListGroup>
  );
}

You'll notice that when we are mapping over the items, we're either rendering an item that is dark (grey) and calls off to removeItemFromList when clicked or we're rendering an item that is danger (red) that calls off to addItemToBasket. Ideally I'd have created two different components and move them into their own file but for demonstration purposes it made more sense to keep them unabstracted.

Both addItemToBasket and removeItemFromList both take in the index of the selected item and simply dispatch that as data along with their relevant action.

Lastly, The Setup

Now that we have everything we need (action creators, a reducer to handle our actions and components to dispatch actions), we need to setup our store so that our application can make use of Redux. You'll need to locate our index.js file and make some simple changes there.

You'll need to import creatStore from the redux library as well as Provider from the react-redux library. We'll use createStore to generate a store from the reducer we created. Your index should look something like this:

import React from "react";
import { render } from "react-dom";
import { createStore } from "redux";
import { Provider } from "react-redux";
import App from "./App";
import reducer from "./store/reducer";

const store = createStore(reducer);

render(
  <Provider store={store}>
    <App />
  </Provider>,
  document.getElementById("root")
);

Now our application will be able to make use of Redux because Provider makes the store available to any nested components.

You should have everything you need to get this application up and running. If there is anything that is unclear, check out my CodeSandBox which will provide you full access to repo so that you can see the entire solution or just mess around.

What is Redux exactly?

Harley Ferguson — Wed, 29 Jul 2020 17:19:03 +0000

^{Photo by Austin Chan on Unsplash.}

You've seen Redux mentioned in nearly every "Getting Started with React" article you've read. Terms like actions, reducers and store keep cluttering your understanding. Let's break down what Redux is from a top-down approach and then look at some code.

Redux, State Management and State

Redux is a predictable state container. What does that mean? It means that Redux provides tools for you to help manage state within your applications in a predictable way. Redux makes this process "predictable" by defining a pattern you must follow to make changes to your state. This pattern follows an immutable approach.

State management is a way of allowing us as developers to add, remove, update and access state in our applications.

State is the current representation of all the actions the user has performed. Clicking a button to get a list of data from an API is state. Tracking if the user is typing with a variable called isTyping is state. Filling in information on a form is state.

Global and Local State

These are terms you'll see often and a part of what Redux solves.

Local state is local to a given component. Like with our previously mentioned isTyping variable. That variable is only relevant to the component that is making use of it or even just the input field that is making use of it.

Say we fetch a user's profile details from an API. What if we need to show the user's name on the DashboardComponent.js and then on a ProfileComponent.js? Would you make two API calls to the same endpoint to get the same data or would you rather make a single call, store that data somewhere and allow both components to have access to that data? This data would then be regarded as being global state because the entire application can access it. This is the type of situation that Redux helps solve.

Is Redux the only solution?

Hell no. Redux is one of the oldest and most popular forms of state management in React but it is by no means the only approach. Libraries like mobx-state-tree and recoil provide you with alternative ways of managing state. Also, Redux is just a pattern with corresponding npm libraries. You could take this pattern and implement it on your own or in other technologies/stacks/languages like what they've done in Flutter.

How does Redux work?

Redux was created by Dan Abramov and Andrew Clark in 2015. They decided to build off of Flux and implement some of it's key concepts like a unidirectional data flow pattern.

Flux and Redux's data flow looks like this:

Actions

Actions are payloads of information that are dispatched to the store. Dispatching an action is the only way to manipulate the store.

// example action
{
    type: 'ADD_ITEM',
    payload: {        
        value: 'Chocolate' 
    }
}

Actions follow the general model of a FSA (Flux Standard Action) which is a human-friendly model that allows us to more easily reason with actions.

Note: It's suggested that the type is a string constant and if your app's scale is increasing, then you move those constants into their own module. This avoids using string literals and potentially having a typo between the type value in your action and then type value we'll perform a switch on in our reducer. For this demonstration, we'll just use a string literal for simplicty's sake.

Action Creators

We create action objects by defining an action creator. Action creators are functions that we call to create an action for us.

// example action creator
const actionCreators = {
    newItem: (data) => { type: 'ADD_ITEM', payload: data }
}

This provides us with an object that has a function property called newItem. If we provide that object with a data value of say "Chocolate", it'll produce an action like the one we saw in initial example of an action object.

Dispatcher

The dispatcher's job is to simply dispatch actions. The reducer will listen out for any dispatched actions and then act accordingly.

Before the React Hooks era, you could make use of store.dispatch() to dispatch your actions for you.

With React Hooks, you can write an implementation like this:

import { dispatch } from 'react-redux';

const dispatch = useDispatch();

Then just wrap any action or action creator method in dispatch().

Reducers

Reducers are functions that specify how are state must change in response to each action. Action objects are only telling us which action happened and provide any relevant data. It's the reducer's job to actually build the new state.

To build off of our current example:

const initialState = {
    items: []
}

function itemReducer(state = initialState, action) {
    switch (action.type) {
        case 'ADD_ITEM':
            return {
                ...state,
                items: [...state.items, action.payload]
            }
        case default:
            return state;
    }
}

We've created our initialState object that just has a property of items which is an empty array to begin with.
We've defined a reducer that takes in two arguments, state and action.
The state represents the current state and is provided an initial value thanks to our initialState variable.
action is the action that has just been dispatched to the reducer.
We perform a standard switch case on the action.type to see if it's match.
Making use of spread operator in ES6 (check this out if you're unfamiliar with ES6 awesomeness), we return a new state object that has the payload value from the action appending to our list array.

That's pretty much it for describing and setting up the unidirectional data flow in your application.

Our next post will look at implementing Redux into your React application a little bit more indepth. We'll build an app called "ShopDrop" that allows for users to add items to their shopping list, mark them as in their basket, remove an item from their list or clear the whole list.

This should give you some more insight into Redux's role in a full scale React app.

JavaScript's const keyword

Harley Ferguson — Thu, 07 May 2020 07:24:17 +0000

^{Photo by Martin Adams on Unsplash.}

JavaScript's introduction of the const keyword in ES6 is amazing but has some hidden passages that you may not be aware of.

The `const` keyword

const is used to create block-scoped variables that provide a read-only reference to a value.

const name = "John";
name = "Ringo"; 
console.log(name); // John

We can see here how we've declared a constant variable called name with the value of "John". If we try to reassign that value to "Ringo", the application will throw an error and inform us that the name variable is read-only.

`const` and Objects

Like mentioned above, the const keyword will create a read-only variable, however, that does not mean that the actual variable reference is immutable.

const beatle = {
    name: "John",
    surname: "Lennon"
}

beatle.name = "Ringo";
console.log(beatle.name); // Ringo

We were able to reassign the property on the constant because we haven't attempted to change the variable's reference but rather the value on a property in that reference. const only allows us to not reassign the reference.

`const` and Arrays

const beatles = ['John', 'Paul', 'George'];
beatles.push('Ringo');
console.log(beatles); // ["John", "Paul", "George", "Ringo"]

beatles.pop();
beatles.pop();
console.log(beatles); // ["John", "Paul"]

beatles = ["Noel", "Liam"]; // TypeError

Once again we can see how we can manipulate a const variable array by adding and remove elements, however, as soon as we attempt to reassign the variable to a new array an error is thrown.

Constants and Enums

So if we have a const keyword that doesn't allow reassignment to a new reference but still allows you to reassign a property, how could we make that not possible at all for the use case of constants or enumerators?

The answer to that is Object.freeze(). This method will "freeze" an object which means that the object can no longer be changed, properties cannot be added and properties cannot be removed. It even prevents the prototype being changed.

const beatle = Object.freeze({
    name: "John",
    surname: "Lennon"
});

beatle.name = "Ringo";
console.log(beatle.name); // John

Object.freeze() allows us to create constants and enums with the guarantee that the values won't be changed in anyway.

Note: Nested objects within a frozen objects need to be frozen as well. Freezing an object only freezes the parent object.

When to use `const`

const should be used when you're wanting to create a block-scoped variable where you know that the value isn't going to change.

// INCORRECT
const beatles = ['John', 'Paul', 'George', 'Ringo'];

for (const i = 0; i < beatles.length; i++) { // TypeError as you're reassigning i
    console.log(beatles[i]);
}

// CORRECT
const beatles = ['John', 'Paul', 'George', 'Ringo'];

for (const member of beatles) {
    console.log(member);
}

Imperative vs Declarative Programming

Harley Ferguson — Thu, 30 Apr 2020 17:20:26 +0000

^{Photo by Émile Perron on Unsplash.}

The term 'declarative programming' has regained popularity in the recent years. But what exactly is it and how does it compare to imperative programming?

Wikipedia defines imperative programming as:

A programming paradigm that uses statements that change a program's state. An imperative programing consists of commands for the computer to perform.

While declarative programming is defined as:

A style of building the structure and elements of computer programs—that expresses the logic of a computation without describing its control flow.

Okay so what do these definitions actually mean and how are they different? Let's explore a simple analogy.

If I had a butler robot and I wanted it to make me a sandwich, imperatively I'd have to tell it this:

1. Go to the kitchen
2. Grab the bread, peanut butter and a butter knife
3. Remove 2 slices of bread
4. Use the knife to butter one slice of bread
5. Place the other slice on top of the buttered slice
6. Bring me the sandwich

To do the same thing declaratively would look like this:

Hey Mr Robot, I feel like a peanut butter sandwich.

Quite the difference, right? Imperatively means that we have to tell our butler robot (the program) every step it needs to do in order to complete the task. Doing the same thing means that we just declare our final state (having a sandwich) and we don't really care how it gets to that point.

This means that declarative programming is generally simpler to code because it's far more readable, doesn't require concerning yourself with lower level logic and allows use to define the solution and not each procedure.

You may have been writing declaratively without even knowing it:

SQL

SQL queries can also be declarative.

SELECT * FROM GAMES

Here we are just saying that we want all of the games in our database but we aren't instructing the computer on how it should be getting every game.

CSS

CSS is declarative programming. Our CSS classes are actually just defining how our elements should look while the browser takes care of the implemenation.

C Sharp

C# allows for developers to write both imperatively and declaratively.

var results = games.Where(game => game.Series == "God of War")

The above code is an example of how, using Linq, we can write declarative code. All we are asking for us a list of games that a part of the "God of War" series but we don't care how the program gives us that data. That's Linq's problem.

Achieving the same functionality imperatively would look like this:

List<Game> results = new List<Game>();
foreach(var game in games)
{
    if (game.Series == "God of War")
    {
        results.Add(game);
    }
}

Okay so why has "declarative" programming become more popular in recent years? Well that would be because of React.

React has heavily promoted itself as declarative. The reason for this is because alternative frameworks (like Angular) or libraries (like jQuery) are imperative. This may leave you wanting a code example but the difference between React and Angular is a blog post on it's own.

Writing less code with regards to your UI rendering does come at a cost in React though. You're going to need to now understand state and how to manage it so that you can effectively render your UI.

Hopefully now you have an idea on what these concepts are so the next time some hot shot coder is throwing around terms like "paradigm" and "declarative programming", you can ask them how their robot butler is doing.

A Reintroduction to ES6

Harley Ferguson — Tue, 21 Apr 2020 13:06:58 +0000

^{Photo by Adam Solomon on Unsplash.}

ES6 may be nearly 5 years old but I still see tons of code that isn't making use of the full ES6 awesomeness. Let's have a quick reintroduction so we can start writing nicer code again.

ECMAScript 6 (or ES6 for short), is the sixth iteration in the JavaScript standardization. If you have no idea what I'm talking about, the TL;DR is that ES and all of it's versions aim to standize the way we write JavaScript by providing a scripting-language specification.

Now that you know what it is, let's start diving into the main differences between ES6 and it's previous version.

`let` and `const` keywords

These are two new keywords that are probably going to fully replace your use of the var keyword.

Creating a variable with const means that it cannot be reassigned and is immuatble (except when it is used with objects but that's another blog post).

Trying to reassign the value of a const will actually throw an error.

const name = "Luke";
name = "Han";
console.log(name);
// --> Error: "name" is read-only

let creates mutable variables that can be reassigned.

let name = "Luke";
name = "Han";
console.log(name);
// --> Han

Both let and const make us of block scoping which we'll speak more about now.

Block Scoping

A block scope generally refers to the area between two curly brackets. The introduction of let and const allow for us to write code that is only relevant within a certain block.

let name = "Harry";

if (name === "Harry") {
    let name = "Ron";
    console.log(name);
}
console.log(name);
// --> Ron
// --> Harry

We can see how block scoping allowed us to create a variable of the same name but it causes no issue as the second use of name is block scoped. Let's see what would happen if we tried this using var in ES5.

var name = "Harry";

if (name === "Harry") {
    var name = "Ron";
    console.log(name);
}
console.log(name);
// --> Ron
// --> Ron

Here, the declaration of the name variable inside the if statement actually just reassigns the original variable's value instead of creating a new one.

Arrow Functions

Arrow functions are just new ways of writing functions that allow for shorter syntax and simpler anonymous functions. The biggest bonus is that they're just way more readable. Let's take a look:

// ES5
function greeter(name) {
    return "Hello " + name;
}

OR

greeter = function(name) {
    return "Hello " + name;
}

// ES6
greeter = name => {
    return "Hello " + name;
}

We can actually make this 1 line as arrow functions implicitly return if they're on a single line.

greeter = name => "Hello " + name;

An arrow function that takes in multiple (or no) parameters would make use of parenthesises.

greeter = (name, surname) => "Hello " + name + " " + surname + "."

Arrow functions have also made anonymous functions (like the ones used with .map, .reduce etc) much easier.

const hobbits = [
  'Frodo',
  'Sam',
  'Mary',
  'Pippin'
];

// ES5
console.log(hobbits.map(function(hobbit) {
    return hobbit.length
}));

// ES6
console.log(hobbits.map(hobbit => hobbit.length));

Side note: Arrow functions no longer need a binding to the this keyword. The reason for that is because regular functions require this to represent the object that called them. In arrow functions this represents the owner of the function.

Template Literals

If you were paying attention, you would have noticed how I was returning the greeting in our greeter method. It looked like this:

greeter = (name, surname) => console.log("Hello " + name + " " + surname + ".")
greeter("John", "Cena");
// --> "Hello John Cena."

Template literals save us from writing + over and over again. Let's refactor our above code into something much cooler:

greeter = (name, surname) => console.log(`Hello ${name} ${surname}.`)
greeter("The", "Rock");
// --> "Hello The Rock."

Default Parameters

Finally, right? I'm sure we are all aware of why this is awesome. Not having undefined thrown in our face because we forgot to guard against it is a lifesaver.

// Without default parameter
greeter = (name, surname) => console.log(`Hello ${name} ${surname}.`)
greeter("Brad")
// --> "Hello Brad undefined

// With default parameter
greeter = (name = "John", surname = "Doe") => console.log(`Hello ${name} ${surname}.`)
greeter("Brad")
// --> "Hello Brad Doe"

Array & Object Destructuring

This is a really simple and super effective trick. Destructuring basically allows for us unpack values from arrays and properties from objects into their own variables.

Previously we'd have to do this quite manually:

// ES5
const person = {
    name: "Marty",
    surname: "McFly",
    age: 18
}

var name = person.name;
var surname = person.surname;
var age = person.age;

console.log(name, surname, age);
// --> "Marty" "Mcfly" 18

Now let's do the same thing but with destructuring:

const person = {
    name: "Marty",
    surname: "McFly",
    age: 18
}

const {name, surname, age} = person;

console.log(name, surname, age);
// --> "Marty" "Mcfly" 18

Destructuring an array makes use of the rest operator and looks like this:

const hobbits = [
  'Frodo',
  'Sam',
  'Mary',
  'Pippin'
];

const [first, second, ...rest] = hobbits;
console.log(first);
console.log(second);
console.log(rest);
// --> "Frodo"
// --> "Sam"
// --> ["Mary", "Pippin"]

Spread Operator

The spread operator has the same syntax as the rest operator but it takes the whole array/object itself instead of just the arguments.

numbers = [1, 2, 3];
sum = (a, b, c) => a + b + c;
total = sum(...numbers);
console.log(total);

The spread operator can also be use effectively when copying parts of objects.

originalPerson = {
  name: "Billy",
  surname: "Joel",
  age: 70
};

newPerson = {
  ...originalPerson,
  surname: "Eilish",
  age: 17
}

console.log(originalPerson);
console.log(newPerson);

The spread will overwrite whatever properties are specifided but otherwise take all of the properties as they exist on the original object.

Promises

If you're integrating with an API, promises are your best friend. They allow developers to write asynchronous code.

Promises are made up of a resolve and a reject. If we wrote our own to just return a subtle Star Wars quote, it'd look like this:

quote = () => {
    return new Promise((resolve, reject) => {
        resolve("Why hello there.")
    })
}
quote().then((res) => console.log(res));

What's happening here is we're calling the quote() method and then telling it what to do when the method resolves through the use of the .then. This means that our code can continue to do other things while we wait for the promise to resolve. An example of what an HTTP request looks like (since getting data from an API would need to be asynchronous) can be found below:

// Using the axios library to handle our API call
axios.get("https://my-json-server.typicode.com/askharley/nintendo-power-json-api/users/1")
    .then(result => console.log(result))
    .catch(error => console.log(error))

Here we can see if that if our call (which is a promise) resolves, we'll log the data through the .then callback and if it's rejected, we'll log the error through the .catch callback.

Imports & Exports

This very simple concept allows for one of the greatest things there is in coding: seperation of concerns. We can now effectively create and separate components which allows for easier reusability.

// greeter.js
export default function greeter(name) {
    return `Hello ${name}.`
}

// home.js
import greeter from './greeter';

const greetings = greeter("Jack");
console.log(greetings);
// --> "Jack"

If a file exports multiple modules then we just throw them inside curvy brackets.

import {greeter, farewell} from './interactions';

Classes

Last but not least, we have classes. Classes are the building block for object orietated programming and help encapsule our code. ES6 introduces all the normal bells and whistles that comes with classes such as instantiation, constructors, inheritance etc.

// Parent class
class Car { 
    constructor(name, colour) {
        this.name = name;
        this.colour = colour;        
    }

    startCar() {
        console.log(`Car: ${this.name} has started.`);
    }
}

// Child class
class Tesla extends Car {
    activateInsanityMode() {
        console.log("Activated Insanity mode.");
    }
}

const roadster = new Tesla("Roadster", "Red");
roadster.startCar();
roadster.activateInsanityMode();

That wraps up our introduction/reintroduction to the major changes that came with ES6. Hopefully you learnt a thing or two. There are many more goodies that came with ES6 but these were the ones I felt like writing about.

Please reach out to me on any of my socials or check out my personal blog here.

Forem: Harley Ferguson

The Paradox of a Software Developer

The Paradox

So how do we overcome the paradox?

First things first:

Here’s my real world example:

We Use Flutter And So Should You

What is Flutter?

What is Dart?

Variables

Functions

Imports

Comments

Classes

What makes Flutter so special?

How does Flutter work?

What are Stateless and Stateful Widgets?

What makes Flutter better than something like React Native or Ionic?

Questioning Modern Web Development

Why is JavaScript so popular?

Why are there so many JavaScript frameworks?

How do we go about bundle splitting?

Is Server-Side Rendering worth it?

Why must APIs be so infuriating?

Where will the web be 10 years from now?

What is Recoil exactly?

Why should I use Recoil in the first place?

How is Recoil different from Redux?

What are atoms and selectors?

How do atoms work?

How do selectors work?

What are the common hooks I'd use in Recoil?

Writing Cleaner & More Readable Redux

Actions

Reducer

Build a React-Redux Shopping List App

The Problem

The Product

Actions

Add Item

Clear Items

Add Item To Basket

Remove An Item From The List

Add Item Component

Viewing The Shopping List

Lastly, The Setup

What is Redux exactly?

Redux, State Management and State

Global and Local State

Is Redux the only solution?

How does Redux work?

Actions

Action Creators

Dispatcher

Reducers

JavaScript's const keyword

The const keyword

const and Objects

const and Arrays

Constants and Enums

When to use const

Imperative vs Declarative Programming

SQL

CSS

C Sharp

A Reintroduction to ES6

let and const keywords

Block Scoping

Arrow Functions

Template Literals

Default Parameters

Array & Object Destructuring

Spread Operator

Promises

Imports & Exports

Classes

The `const` keyword

`const` and Objects

`const` and Arrays

When to use `const`

`let` and `const` keywords