Forem: Charles Stover

Manage your customers’ clipboard with React hooks.

Charles Stover — Tue, 08 Oct 2019 02:25:10 +0000

Modern web applications have an abundance of tools available for improving user experience. When implementing a new feature, a sizable chunk of UI/UX discussion is typically devoted to reducing the number of necessary clicks and keystrokes required to perform a task. The ability to automate the repetitive or predictable behavior is one of the largest driving forces behind the software industry, and I think it is beautiful that we have blossomed from calculators saving hours of error-prone manual labor to user interfaces automating seconds.
It is no shock that most large projects inevitably reach a point where we can predict that the user is going to want to copy or paste something, and we inevitably attempt to automate that workflow. Clipboard interactions are one of the oldest attempts to hijack a user’s system for their own good, and it is time that these APIs integrate with React.

In this article, I will walk through how I created use-clippy, a React Hook for writing to or reading from the user’s clipboard. Not to be confused with Microsoft Office’s assistant, Clippy 📎.

This package was interesting to develop for a few reasons:

Clipboard APIs are old — so old that they have been deprecated and re-invented. We want to make sure that all users, regardless of their browser version, are able to use this feature.
Clipboard APIs are both synchronous and asynchronous, and we need to account for not knowing whether the action will occur immediately or with delay.
Clipboard APIs, being a security concern, are permission-based in modern browsers. The primary reason they are asynchronous is due to the time between you attempt to hijack the user’s clipboard and the customer actually approving the permission request.
Clipboard APIs are not integrated into TypeScript by default. use-clippy is a TypeScript package, so we have the joy of writing those types ourselves.

“I don’t care how it works. I just want it now.” ⏳

You can install use-clippy from NPM with npm install use-clippy or yarn add use-clippy.

Using this package is as easy and intuitive as the useState React Hook.

import useClippy from 'use-clippy';

function MyComponent() {
  const [ clipboard, setClipboard ] = useClippy();
  // ...
}

Just use clipboard to read the contents of the user’s clipboard, and use setClipboard to set the contents of the user’s clipboard. It’s that easy.

use-clippy is also open source on GitHub. The source code is available for anyone to peruse, and public contributions are welcome.

Creating a Hook 🎣

I always start every project by imagining how I would want to interact with the package as a consumer/developer. As a React hook, I want an interface that is intuitive. As such, use-clippy is patterned after useState, the built-in React hook for managing a value and its setter.

const [clipboard, setClipboard] = useClippy();

With this interface, I have read and write capabilities for the clipboard that match my existing component state management code.

As a TypeScript project, everything will be strongly typed. While there are no parameters to useClippy, there is a return value, which is defined as such:

type ClipboardTuple = [
  string,                      // getter for the clipboard value
  (clipboard: string) => void, // setter for the clipboard value
];

The first thing we’ll need to do is copy the clipboard into a local state for this React component so that changes trigger a re-render.

function useClippy(): ClipboardTuple {
  const [ clipboard, setClipboard ] = useState('');
  return [ clipboard, ... ];
}

While the clipboard value in the state should match the user’s clipboard value (with a browser-enforced delay as the user authorizes permission to do this), the setClipboard function here only sets the local React state value, but not the user’s actual clipboard value. Therefore, that is not the function we will be returning to the component consuming useClippy.

The Clipboard API 📋

There are two ways to read from a clipboard. Modern browsers have an asynchronous, permission-based clipboard API. A developer may request access to a user’s clipboard, at which point the browser prompts the user to authorize this behavior. Older browsers have a synchronous clipboard API, wherein the developer simply tells the browser to read or write to the clipboard, and the browser simply does it or refuses, with no user interaction.

useClippy accounts for both.

// Determine if the asynchronous clipboard API is enabled.
const IS_CLIPBOARD_API_ENABLED: boolean = (
  typeof navigator === 'object' &&
  typeof (navigator as ClipboardNavigator).clipboard === 'object'
);

Why “as ClipboardNavigator”?

TypeScript does not contain the Clipboard API in its definition of the navigator object, despite it being there in many browsers. We must override TypeScript’s definitions in a few places to essentially say, “We know better.”

// In addition to the navigator object, we also have a clipboard
//   property.
interface ClipboardNavigator extends Navigator {
  clipboard: Clipboard & ClipboardEventTarget;
}

// The Clipboard API supports readText and writeText methods.
interface Clipboard {
  readText(): Promise<string>;
  writeText(text: string): Promise<void>;
}

// A ClipboardEventTarget is an EventTarget that additionally
//   supports clipboard events (copy, cut, and paste).
interface ClipboardEventTarget extends EventTarget {
  addEventListener(
    type: 'copy',
    eventListener: ClipboardEventListener,
  ): void;
  addEventListener(
    type: 'cut',
    eventListener: ClipboardEventListener,
  ): void;
  addEventListener(
    type: 'paste',
    eventListener: ClipboardEventListener,
  ): void;
  removeEventListener(
    type: 'copy',
    eventListener: ClipboardEventListener,
  ): void;
  removeEventListener(
    type: 'cut',
    eventListener: ClipboardEventListener,
  ): void;
  removeEventListener(
    type: 'paste',
    eventListener: ClipboardEventListener
  ): void;
}

// A ClipboardEventListener is an event listener that accepts a
//   ClipboardEvent.
type ClipboardEventListener =
  | EventListenerObject
  | null
  | ((event: ClipboardEvent) => void);

Now that we know if the asynchronous Clipboard API is enabled, we can use it with graceful degradation.

Re-render when the clipboard is updated.

The asynchronous Clipboard API allows us to subscribe to clipboard changes. We can use this to synchronize our React component’s local state value to the user’s actual clipboard value.

// If the user manually updates their clipboard, re-render with the
//   new value.
if (IS_CLIPBOARD_API_ENABLED) {
  useEffect(() => {
    const clipboardListener = ...;
    const nav: ClipboardNavigator =
      navigator as ClipboardNavigator;
    nav.clipboard.addEventListener('copy', clipboardListener);
    nav.clipboard.addEventListener('cut', clipboardListener);
    return () => {
      nav.clipboard.removeEventListener(
        'copy',
        clipboardListener,
      );
      nav.clipboard.removeEventListener(
        'cut',
        clipboardListener,
      );
    };
  },
  [ clipboard ]);
}

Since IS_CLIPBOARD_API_ENABLED is true, we know that navigator is a ClipboardNavigator as defined above, so we override TypeScript’s definition. When the user updates their clipboard by copying or cutting, we want this component to re-render with the new value, because this component is reading the user’s clipboard. When the component unmounts, we remove these event listeners. The current clipboard value is a dependency, because we use it in the clipboard listener to only re-render the component if the new value is different than the old value.

The clipboard event listener is defined below:

const clipboardListener = ({ clipboardData }: ClipboardEvent) => {
  const cd: DataTransfer | null =
    clipboardData ||
    (window as ClipboardDataWindow).clipboardData ||
    null;
  if (cd) {
    const text = cd.getData('text/plain');
    if (clipboard !== text) {
      setClipboard(text);
    }
  }
};

Get the clipboardData from the event itself. In some cases, it is instead defined on the window object. If the user did not allow us to read this value, we may instead receive null.

Again, TypeScript does not support the Clipboard API in its definitions, so we must manually define window as an object that may contain a clipboardData property.

interface ClipboardDataWindow extends Window {
  clipboardData: DataTransfer | null;
}

If the user did authorize us to read the clipboard, we use getData to convert our DataTransfer object to plain text. Only if the new clipboard contents differ from the ones we already have, we set our React component’s local state value to the new clipboard value.

Initial Clipboard Value 🔰

Above, we allowed our component to update asynchronously as the customer updates their clipboard. However, when the component first mounts, we need to read the clipboard immediately. Here, we may attempt to read the clipboard synchronously.

// Try to read synchronously.
try {
  const text = read();
  if (clipboard !== text) {
    setClipboard(text);
  }
}

Reading a clipboard synchronously through older browser APIs is a complex process, so it has been abstracted away and defined below. If it occurs successfully, however, we can set the React local state value to the clipboard value.

Reading the clipboard synchronously.

In order to read the clipboard synchronously, we must first paste the clipboard somewhere.

const read = (): string => {
  // Create a temporary input solely to paste.
  const i = createInput();
  i.focus();
  // Attempt to synchronously paste.
  // (Will return true on success, false on failure.)
  const success = document.execCommand('paste');
  // If we don't have permission to read the clipboard, cleanup and
  //   throw an error.
  if (!success) {
    removeInput(i);
    throw NOT_ALLOWED_ERROR;
  }
  // Grab the value, remove the temporary input, then return the
  //   value.
  const value = i.value;
  removeInput(i);
  return value;
};

Creating and removing the temporary input is more of a CSS tutorial — a challenge in the art of hiding the input from user perception while still being accessible to the browser API. An input that has a display value of none or a height or width of 0 cannot be interacted with. If you are interested, you may inspect the source code.

Initializing the local state value asynchronously.

When synchronous initialization fails, we can fallback to the slower, but modern asynchronous Clipboard API. If it is enabled, simply read from it and set the local state.

// If synchronous reading is disabled, try to read asynchronously.
catch (e) {
  if (IS_CLIPBOARD_API_ENABLED) {
    const nav: ClipboardNavigator = navigator as ClipboardNavigator;
    nav.clipboard.readText()
      .then(text => {
        if (clipboard !== text) {
          setClipboard(text);
        }
      })
      // Fail silently if an error occurs.
      .catch(() => {});
  }
}

If both synchronous and asynchronous attempts to read the clipboard failed, there is simply nothing we can do. The browser does not support it, and we fail silently.

Set the Clipboard ✍

At the very beginning, we created a tuple that contains the clipboard’s value for reading the user’s clipboard and a setter for setting the user’s clipboard. We have now implemented the first item in that tuple, and it is now time to create the setter.

function clippySetter(text: string): void {
  try {
    write(text);
    setClipboard(text);
  }
  catch (e) {
    if (IS_CLIPBOARD_API_ENABLED) {
      const nav: ClipboardNavigator =
        navigator as ClipboardNavigator;
      nav.clipboard.writeText(text)
        .then(() => {
          setClipboard(text);
        })
        .catch(() => {});
    }
  }
}

The first thing we do is attempt to write to the clipboard synchronously. We do this with the same complex behavioral pattern we used for reading synchronously.

const write = (text: string): void => {
  const i = createInput();
  i.setAttribute('value', text);
  i.select();
  const success = document.execCommand('copy');
  removeInput(i);
  if (!success) {
    throw NOT_ALLOWED_ERROR;
  }
};

Create an input, give it the value we want in the customer’s clipboard, select the contents of that input, then execute a copy command. It will either succeed to synchronously set the user’s clipboard, or it will throw an error.

In the event it was successful, we set the React component local state to the new value, keeping it in sync with the actual clipboard.

In the event of an error, we fallback to the asynchronous Clipboard API. If it succeeds to writeText, we set the React component local state to the new value. If it does not succeed, we fail silently.

Always update. 🆕

When reading the clipboard, we would only set the React local state if the new value was different than the existing value. When setting the clipboard, we always set the user’s clipboard and the React local state, even if the new value is the same as the existing one.

We always set the user’s clipboard in order to account for when the user updates their clipboard from outside the application. In this case, the clipboard value in the local state may be different from the actual clipboard value, and we want to ensure that our new value gets set, even if our local state value is wrong.

We always set the React local state in order to trigger any re-render animations or effects, such as a “Clipboard copied!” notification.

Conclusion 🔚

This package is available on NPM and open source on GitHub.

If you have any questions or great commentary, please leave them in the comments below.

To read more of my columns, you may follow me on LinkedIn and Twitter, or check out my portfolio on CharlesStover.com.

Become the junior developer that companies want to hire.

Charles Stover — Tue, 18 Jun 2019 23:10:56 +0000

Preface 🔰

Who am I, and why listen to me?

As a self-taught web developer, I struggled to overcome the barriers of entry into the workforce. I had always done well in academia, which resulted in professor affirmation, offers for advanced classes, and offers for scholarships. I naively believed the workforce to behave similarly: that all I had to do was be good at what I did and the jobs would come to me. If I could pass an interview the way I could pass a test, my encyclopedic knowledge of programming would make finding a job easy.

That was not the case. Not only did job offers not come flooding into my mailbox, but I could rarely get a response to an application when I reached out to companies directly. What was wrong? I was a good developer. I could solve real world problems. I had created applications and met customer demands. Somehow, I was wholly unprepared for an enterprise setting.

I doubted my abilities. My ego was crushed. I thought I was intelligent; I thought my projects pushed the envelope; but employers seemed to disagree. They often did not see me as even worth interviewing. The most common feedback I received was that they required a degree. The fact that I had invented applications that generated revenue did not matter. I gave up and pursued other passions, leaving web development as my favorite pastime that it had always been.

Years later, I decided to pursue web development again after encouragement from my peers. I was still passionate about it. I was good at it. It made me happy. I attempted to re-enter the workforce, knowing from past experience that it would not be easy. I took the act of job searching much more seriously than before. The difference? Humility. You should know what you don’t know, and I knew there was something I did not know about web development careers and how they differed from web development as a hobby.

I spent a lot of time researching how to build a résumé and portfolio, the interview process, and the soft skills of developer careers. I sought résumé and portfolio critique. I did as many practice interviews as I could book. I networked every opportunity. I still research these topics to this day. I take a strong interest in them, as my ignorance of these topics held me back for so long. I am passionate that other developers be prepared to face these issues as well, especially those whom are self-taught, because they are often overlooked in academia and barely existent online.

Since entering an enterprise setting, I have been involved with as much interview training, sat on as many interview panels, and gathered as much employee feedback as possible. I have applied what I have learned to everyone I have come across who seeks it — from Reddit threads to direct LinkedIn messages. This is my attempt to publicly document and share this knowledge, in hopes that talented and self-motivated developers receive the fair shot at success they deserve.

Education 👨‍🎓👩‍🎓

Before you can become a junior developer that is in demand, you must first become a junior developer. This article is not equivalent to an education. This article is meant to be supplemental to an education, be it formal or self-driven.

Cracking the Coding Interview by Gayle Laakmann McDowell is another powerful education supplement that I highly recommend. It covers many of the soft skills required by companies and ensures you know the hard skills. You will see it recommended time and time again online, and it is easily worth the $30 investment.

I encourage anyone to at least read the data structures and algorithms discussed in that book. If you can already solve the problems, implement the data structures, or create the algorithm, then just go to the next one. If you find yourself feeling a bit hazy about the implementation details, I strongly recommend that you write it yourself. This will add to your portfolio and help solidify the knowledge in your mind. Learning through teaching is a practice that I recommend often. It was my inspiration for Implementing Quicksort in JavaScript and the resulting GitHub repository and NPM package for my portfolio.

You need go a step further than merely knowing what the data structures and algorithms are. Understand the trade-offs between them. When do you choose one over another? Which is more extensible and under what conditions? Which uses less memory or is faster to execute? When would you want to trade memory or efficiency for these other features and why? Knowing the answers to these questions will be very important during your interview process. You will almost certainly be asked to solve a problem that requires a complex data structure. Whichever you choose, you will want to be able to defend. “It’s the first data structure I remembered” does not fly too well on a production application, so it does not fly too well in an interview either.

Open Source 📄

It may seem obvious, but a portfolio is meant to be a document of your accomplishments. So document them! Thoroughly. I mistakenly spent my earliest years creating proprietary software. My server-side code was backed up to several hard drives, and my JavaScript never saw user eyes without first being ran through a minifier. I believed that in order for code to be profitable, it can’t be copied. I was wrong.

I encourage you to open-source as much as possible. Your Quicksort implementation is not doing you any favors on your hard drive. Your intro-to-programming video game may be embarrassingly inefficient, but you are selling it short. These beginner’s projects show:

You wanted to make something and have an interest in programming outside of work.
You learned to make something and are both willing and capable of learning new technologies as needed.
You completed a project without giving up. You can see challenges through to the end by overcoming obstacles instead of quitting.
You did something. If you do not publish your code, employers will assume that you never wrote it. It is so much better to write something inefficient than to write nothing at all.

Since open-sourcing my projects, my development career has earned more value than those projects ever offered me on their own. I have received a significant amount of community feedback that has allowed me to prioritize what is important to customers and account for use cases and environments I never would have otherwise considered. Bugs that never existed in my environment have arisen in others’. From their reports, I have identified and learned from mistakes in my code designs. Today, I can create components and packages that are extensible to more use cases than just my personal portfolio and projects. These learned concepts and deeper understanding of technologies improve my quality of work.

For each project, I recommend adding the following to its README.md:

An actual name. repository-name is nice and automated, but try to give it a description that differentiates you from other candidates. Every candidate has a “TODO App” and “Shopping List.” Why is yours better? Try “React TODO App” or “MongoDB Shopping List.”
An actual description. “TODO App” can mean a lot of things. It is obvious to you, because you made it. What CRUD operations does it support? Does it use server-side code? Who is the target audience? What problem are you solving and how? For example, my Shopping List application “was created for my father, who needed a printable shopping list for his home care aides. To support his declining memory, the application keeps track of past items so that they may be re-added with ease.” I have put the customer first, identified a problem, and executed on a solution.
The tech stack used. HTML, JavaScript, React, PHP, SQL, Docker? Let people know what you have experience using. Even if your project is not the cleanest code or optimal implementation, you have demonstrated that you understand these technologies at least in concept. You know what problems they solve, and that’s the largest hurdle. Perfecting their use can be learned on the job.
Nobody, and I mean nobody, is going to clone your repository, install it, then run it locally just to see your work. Companies are often flooded with candidates (whether or not they are good candidates). They will just move on to the next candidate instead. At this point in time, to the company, you are statistically likely to be average. Their time is better spent researching another candidate than wasting time or muddying their machine. If your project is front end, consider deploying it to GitHub Pages. If your project is not front end, consider adding screenshots of any GUI, linking to a live demonstration of any API, or documenting example inputs and outputs.
Document your API, if there is one. This is good experience and practice for when you are creating highly used, production-facing APIs in an enterprise setting. Companies want good documentation, even for APIs that are only used internally. Every time an internal customer references the documentation, there is one less support ticket to answer and one more free hour for a developer to implement new features instead of support existing ones. When the creator of an API leaves the company, how quickly can their replacement support the service they have inherited? Many companies have been burned by this before, and they know that good documentation is indicative of team-thinking.

Networking 🌐

If you want to stand out, then you first need to stand. Not only should recruiters be able to find you, they should be impressed by what they see. Get your name out there for good reasons.

Under your Career Interests, let recruiters know you are open. Reply to every recruiter, whether or not you want the job. Practice your professional communication skills. Practice putting complex social and career situations into words that are articulate and unoffensive. These skills will translate both into an interview setting and the workplace. Sometimes, you know what you want, but you do not quite know how to say it. Later, when you are interviewing, it will be good to be able to articulate professionally what it is that you want from the job — and that is the best way to get it.

Practice declining jobs in which you are not interested without burning bridges. That recruiter may reach out to you in the future with a better opportunity more tailored to your interests. Similarly, job offers that you do not accept today may become desirable in the future. Finally, when you leave your first job for your second, your experience in rejecting your current company without burning bridges will help you get that professional recommendation.

Squeeze recruiters for information. Find out what is in demand. For what skills are they looking? If they inform you that you are not the right fit for a position, ask them why. What are you lacking? What should you study? If you re-apply in some number of months, what do they want to see improved that could land you the position? Drop your pride, up your humility, and understand that employers want an employee that can learn, not one who thinks they know everything already. A candidate telling me that they will be back and more ready than ever is a very positive sign. It shows dedication, it shows an eagerness to learn, and if they come back having corrected their faults, it shows an ability to succeed at their goals.

Learn your worth. No matter the recruiter or the position, what is the compensation? What does a front end engineer make in Seattle? What does a PHP developer make in Indiana? What does a React Native developer make in India? (Do note that I included a location in each of these. The greatest determinant for compensation is location!) When your first job offer inevitably asks what you want as far as compensation, you will know what you are worth. Do not be afraid to high-ball. Once they have decided that they want you, they will not just reject you for asking too much. They will counter with their max. This is better than low-balling yourself and making closer to minimum wage than your worth. This is a great way to lose motivation, feel underappreciated, and quickly burn out during your job.

Link to your LinkedIn profile liberally. Your projects outside of LinkedIn should include links to LinkedIn. Recruiters who are impressed by your work need a way to contact you. Developers who are impressed by your work may be willing to give you a job recommendation. For example, I end every Medium article with “Follow me on LinkedIn.” At this time, these link shares have resulted in 300 connections.

Stand, and allow yourself to be found.

Twitter

Keep your Twitter account professional. It is okay to have personal tweets, but do not have anything controversial. Build a following by constantly tweeting what you have accomplished, and share your Twitter profile on your projects to build a following. For example, I end every Medium article with “Follow me on Twitter.” At this time, these link shares have resulted in 300 followers.

Twitter is free marketing. I have never made a social tweet. I maintain a strictly business Twitter account. If I post what I have made, people will see it, interact with it, provide feedback, and share it. Related hashtags, such as the tech stack, can be used to encourage bots to auto-retweet you for a wider audience.

Résumé 💼

The million dollar questions are, “How do you stand out from every other equally-education recent college graduate?” and “How do you show that your self-taught education is equal to your accredited competitors?”

First things first, actually write your résumé! Be sure to keep your portfolio and résumé in sync with your LinkedIn. This helps recruiters find you and know what tech stacks with which you are familiar.

Keep your résumé to one page. If you think you need more than that because you have accomplished so much, you are wrong. For reference, my 17 years of experience is still a one page résumé. It is more likely that you are including information that should not be in a résumé. Remember that a résumé gets you to the interview. The fine details come up in the interview itself.

LinkedIn often has promotions with free courses on their LinkedIn Learning platform. Completing these courses adds a Certification entry to your LinkedIn profile — an easy and fun way to stand out.

Tailor your résumé to the job to which you are applying. Your education, experience, interests, and goals can all be conversation pieces during the interview. Know how they relate to the job. What formal training have you had in the field? Note college courses or online training that were particularly relevant. What past work applies specifically to this job? Remove unrelated projects. An employer seeking a front end engineer is not going to ask you about the time you coded a Caesar cipher in assembly. Any time they spend reading about it is mental fatigue that turns them off to you as a candidate. Any time they spend discussing it with you is likely time wasted. They will not have learned if you are a correct fit for the job. That time is better spent informing them of your strengths in the field.

Do not list items on your résumé that you cannot defend. You may think you need to lie to land an interview, but you do not. Part of the interview process is specifically tailored to weed out liars. You achieve nothing more than wasting everyone’s time, including your own. You will be grilled on technologies you list and asked to give specifics about past projects. It will be apparent if you are not familiar with these technologies or supposed projects. It does not look good to claim to have worked with NPM and Travis CI but be unable to define them, what problems they solved, or how these tools solved those problems. Even vague answers can be red flags. You know that NPM managed your Node packages, but you do not know what packages, why you would want this tool on your project, or the commands you used. These are great reasons to explicitly not hire you. It would realistically be a better choice to hire a candidate who has no experience with NPM than one who supposedly does have experience but cannot answer the above. The inexperienced candidate may be able to learn. The lying candidate has demonstrated that they are incapable of learning.

I do not say the above to make you fear of listing a technology on your résumé. I say the above to emphasize how many candidates lie, how employers have come to expect this, and to encourage you not to waste your time lying also. If you honestly have experience with a technology, do not be afraid to list or discuss it. If you do not know the answer to a question, admit it and explain why. “We used NPM to install packages, but the only one I know is npm install. The CI/CD pipeline ran the rest automatically, so I am unfamiliar with them.” You have demonstrated that you do understand what the tool is and what the tool solves. You have not demonstrated that you are incapable of learning. If I heard this answer, I would think you are perfectly capable of learning NPM better on the job. This is in stark contrast to the lying candidate who claims to have used a tool but cannot offer specifics about when, where, or why.

Sell yourself. Don’t sell yourself short. Be proud of what you have accomplished and be confident in your verbiage. You did not “make a small website for a friend.” You “exceeded a customer’s expectations by delivering a accessibility-compliant single-page-application and maintain it through an Issues tracker and a CI/CD pipeline.” Employers do not want to make small websites for your friends. They want to make SPAs, perform long-term maintenance, track issues, and automate deployment. Your description of your project should not be “I made a tic-tac-toe clone in the browser,” but “A React application that implements Flux architecture through Redux, supporting keyboard navigation and performing animations with CSS.” Remember to tailor the résumé to the job and describe your projects with marketable terms.

Mentality 🧠

Know yourself.

Why are you interviewing for this position? What are your short and long term goals, and how does this position help you reach them?

For my last interview, my answers to these questions were: I want a higher skill ceiling than my previous job. I want to be challenged to learn new technologies and better myself. I feel like I have plateaued at my previous place of employment, and I have an intrinsic motivation to become the best developer that I can be.

Employers want to know you are a right fit for them. If you just want money, you are a right fit anywhere — meaning there is no guarantee you will remain loyal when a competitor offers more. They do not want to invest in you if this is the case. For my last career shift, I would have been willing to take a pay cut, because it meant I could achieve greater things, and that is what mattered to me.

Interviews should not be scary.

You should have the mentality that every interview is good for you. Much the way you can squeeze a recruiter for information, you can do the same with an interview. Determine what tech stacks their company uses, what skills are in demand, and why they are not interested. Some interviewers are unable to give you this information without first passing it through to HR, so be sure to follow up with HR after the interview. Use this information to better yourself between interviews.

Interview places that you “know” you will not accept. I put know in quotes, because I have known someone to accept a job offer after following this advice, interviewing with no intention of accepting, finding out they actually loved the company, and accepting the offer. This is my only morally-ambiguous piece of advice. Practice interviewing at places in which you do not have an interest. Squeeze them for the same information — what is their tech stack, what skills do they value, in what areas can you improve, and if you receive a job offer, what is your worth? These practice interviews will allow you to better communicate your soft skills with less anxiety, and it will show when you take on an interview for a job that you really want.

Treat your interview like it your first day on the job. This should help decrease your anxiety and feel less pressure of being judged. Interact with the interviewer as if they are your coworker. The entire point of an interview is for the interviewer to determine how you would behave on the job. When they ask you questions, it is not because this is a test, and you have to achieve 90% of higher to pass. It is because they want to see your thought process when you are given real world problems to solve. This thought process is not just getting a right or wrong answer. How many edge cases did you consider? Could you discern which did or did not apply to the customer in this use case? Did you take extra steps when solving the problem to make your code extensible to possible future modification, despite it not being a part of the current feature request? Can you communicate difficult technical concepts, data structures, algorithms, and their trade offs? Do you know when to ask for help, or do you think you know everything? These are potential areas in which the interviewer is taking notes, because these are the things you will work on in a team. Engage your interviewer. Talk to them. Ask them questions. Describe your thought process. Think out loud. Seeing them as a coworker really helps aid in this task.

Interview Preparation 👨‍💼👩‍💼

To prepare for your interview, make sure that you are intimately familiar with the S.T.A.R. format. When your interviewer asks you to describe an event, try your best to answer with S.T.A.R. This ensures you provide the information for which your interviewer is probing and that there is no miscommunication between the two of you. If your misinterpreted the question, it should become clear by the situation or task that you are answering the wrong question. If you are answering the right question, the interviewer may be looking for relevant experience (situation), problem identification or communication skills (task), problem-solving or technical skills (action), or ability to deliver results, compromise, or learn from mistakes (result). By answering with S.T.A.R., your bases are covered, and strong communication is achieved.

Create a list of your most impressive projects.

Impressive is subjective, but here I mean the projects that were the most extensive or unique. You worked on a team, you worked with clients, you worked with a manager, you received notable amounts of community feedback, it went viral, or you accomplished something that took weeks not hours. Prepare to reference your most impressive projects during behavioral questions. Unlike the quantitative, encyclopedic knowledge of programming, sometimes you can draw a blank when asked qualitative questions. You have so much experience writing for loops and traversing arrays that it comes second nature when asked to do so. Unfortunately, when asked to “name a time you had a disagreement with a superior,” you might not have an example at the ready. Your mind can go blank as you try to process this question.

What if I’ve never had a disagreement? If I say I have not, do I sound inexperienced or like I’m lying? And if I have, will it sound like I am difficult to work with or oppositional? What counts as a disagreement? Who counts as a superior? I have little to no work history! How am I supposed to have disagreed with a superior?

Do be aware that behavioral questions do not typically mean on the job. In the previous question, a superior may be a professor or a mentor. A disagreement does not need to be a heated argument, but could be different opinions on implementation details. You can make the question as generic as it needs to be to have an answer, and that’s why creating a list of your most impressive projects up front can be beneficial.

I highly recommend reading through Amazon’s Leadership Principles. These are some of the most well-rounded, all-encompassing, and rigorously tested behavioral skills on the Internet. You would be hard-pressed to find a soft skill that is both important and not on this list. For each leadership principle, I recommend associating it with one of your impressive projects. Add new projects or situations as needed.

Project A — I learned something new.
Project B — I invented a tool to aid the development process.

You may absolutely assign multiple principles to a single project, but I strongly recommend that you have a project or situation for each principle. If you find yourself unable to associate some, think harder. Try removing the job or development aspect from the association. A time you were frugal may have just been in your day-to-day life, where you have managed to cut expenses in order to prioritize paying off your student loans and therefore decreasing your accumulated interest.

Once you have associated each leadership principle with a project or situation, clean up your list. Remove projects or situations that are not associated with any soft skills. You should be left with just a list of your actual most impressive projects.

Bring this list with you to interview. When you are asked a behavioral question, if needed, read over this list to jog your memory of a time it applied. Do not write the soft skills next to the projects. The point of this list is to be memory-jarring. You should be able to skim it in a few seconds in response to a question, not spend several minutes reading a page of summaries before you answer. The combination of the location (project) and event (question) should be enough to quickly jog your memory of any relevant experience you may have.

It may feel odd to have to look at notes of your own life story in response to a question about yourself, but do not worry. Interviewers are aware of the impact of nervousness during the interview process, and I assure you no one will mind that you took notes about your own soft skills. People struggle with these questions more than any others, so your ability to answer at all will put you ahead of the curve.

Bring data.

Numbers are the universal language. They remove ambiguity and drive business decisions. If you have data to accommodate your claims, bring it. By what percentage did you boost productivity or revenue? How much money did you generate? How much time did you save? If you only have qualitative results, they are better than nothing. Measuring your efficiency not only drives home the reality of your value, but it shows a mindset of valuing analytical data that indicates that you will do the same on the job.

For example, some data I collected prior to my last interview:

I reduced network traffic by 30% (gzipped) to 60% (non-gzipped) by implementing an opt-in (backwards compatible) compression algorithm on the API. This was not a complicated algorithm. I never had formal training in compression or data. I simply noticed that network traffic was being wasted downloading the same property names repeatedly. A quick Google search shows that I was not the only one to seek this data conversion. I measured the packet sizes with and without this change, and viola — data.
I simplified an existing internal testing framework for a project. This resulted in the development time for end-to-end testing decreasing from 3 days per path to just 1. This wasn’t rocket science. I was annoyed by how difficult the existing framework was to use, so I turned common commands into re-usable function calls. When the team responded that it was much nicer to use, I documented the change in development time.

Be confident.

Confidence is important. Identify your insecurities and practice addressing them. If your interviewer probes these aspects of you and your achievements, you do not want to validate their concerns by lacking answers.

Do you lack a degree? Why? You thought it was the right choice for you to make. Why? You decided that you could achieve academic equality to a college graduate. Why? Leave your fear of judgment behind and take pride in your decisions. If you cannot be confident that your choices thus far are the right ones, how can you be trusted to make the right choices for the company?

I lack a degree in Computer Science. It was my biggest insecurity in my first attempt to enter the workforce. Now, I am outspoken against learning software development through college curriculums. I am confident that it was the correct decision for me. It would have cost me too much money and provided too little benefit. I learned faster on my own than in a classroom. I have worked with developers in open-source, in person, and engaged myself in as many developer communities as I can find. I have proven that I can comprehend and discuss complex topics, so I am confident that a college education would not improve myself as a developer. I can articulate that sentiment to an interviewer.

Once you understand yourself, practice articulating it. Practice by yourself, putting your thoughts into words. There is a lot of emotion behind anxiety, insecurity, and fear of judgment. It can be difficult to find the right words to label emotionally-charged aspects of your life. Practice, practice, practice. Once you believe you have adequately described your biggest challenges, practice with friends and relatives. Then, practice with mentors and coworkers. Practice, practice, practice.

Seek honest feedback. If your goal is to improve or land a job, you do not want your ego stroked. You want constructive criticism. Make sure those close to you know that they should not be afraid of hurting your ego, and make sure your ego is not hurt by opportunities for self-improvement.

In the end…

When the interview has come to a close, your interviewer will often give you an opportunity to ask questions. Do ask questions. This shows that you have an actual interest in the company and are not just here for a paycheck. Do not ask about pay, vacation time, time off, or anything else that insinuates that you care more about money than your career. Do ask about company culture, opportunities for growth, team dynamics, tech stacks, and making sure you are a good fit for each other. You are interviewing the company just as much as the company is interviewing you. They do not want to put you in an environment where you will not be happy — that’s the fastest way to have an employee quit. Identify what is important to you, and ask how questions related to your short and long term goals.

End the interview with a closing statement. It does not feel as natural as it should, but after you have asked your questions, segue to a closing statement. “I don’t have any further questions, but I do have one comment.” This is your opportunity to describe your best qualities and what you can bring to the team. Instead of the interviewer leaving the interview fixated on your minor imperfections, have them leave with a positive thought. If your greatest qualities did not come up naturally during conversation, now is your opportunity to address them. During an interview, the bottom of my notes reference a few of what I consider to be my strongest qualities. If they came up already, I ignore them; if they did not come up, I bring them up now.

Conclusion 🔚

If you have any questions or relevant great advice, please leave them in the comments section.

To read more of my articles or follow my works, you may connect with me on LinkedIn and Twitter. It’s quick, it’s easy, and it’s free!

You can also check out my portfolio on CharlesStover.com.

Implementing Quicksort in JavaScript

Charles Stover — Wed, 05 Jun 2019 23:53:19 +0000

Quicksort is one of the most efficient methods for sorting an array in computer science. For a thorough breakdown, it has its own Wikipedia article.

This article will cover implementing quicksort in JavaScript. Quicksort is not built in to JavaScript. Due to the sort method on the Array prototype, sorting is rarely questioned or optimized in the language. Despite that, Quicksort is still an important algorithm to at least comprehend, whether or not you use it.

How does it work? 🤔

Quicksort works by picking an element from the array and denoting it as the “pivot.” All other elements in the array are split into two categories — they are either less than or greater than this pivot element.

Each of the two resulting arrays (array of values less-than-the-pivot and array of values greater-than-the-pivot) is then put through that very same algorithm. A pivot is chosen and all other values are separated into two arrays of less-than and greater-than values.

Eventually, a sub-array will contain a single value or no value at all, as there will be no more values with which to compare it. The rest of the values were all denoted to be “pivots” at some previous point and did not trickle down to this lowest sub-array. At that point, the values will be sorted, as all values have now been declared as less than or greater than all other values in the array.

How do we implement it? 💡

Since the Array prototype method sort uses its own sorting algorithm, we cannot use it for implementing quicksort. We must create a function that receives the array-to-sort as a parameter and return the sorted-array.

const quickSort = (unsortedArray) => {
  const sortedArray = TODO(unsortedArray);
  return sortedArray;
};

Since the “value” of the item in the array may not be immediately obvious, we should offer an optional parameter for the comparator. Sorting strings or numbers is built in to JavaScript, but sorting objects isn’t. We may want to sort a collection of user objects ({ name: 'Charles', age: 21 }) by age.

const defaultComparator = (a, b) => {
  if (a < b) {
    return -1;
  }
  if (a > b) {
    return 1;
  }
  return 0;
};

const quickSort = (
  unsortedArray,
  comparator = defaultComparator
) => {
  const sortedArray = TODO(unsortedArray);
  return sortedArray;
};

Since the number of times we can divide this array into less-than/greater-than halves can vary towards infinity, we want to recursively define our logic so that we aren’t repeating our code (“pick a pivot, split, repeat”).

You may use any index as the pivot location: first, middle, last, random. Assuming randomly-sorted data, the location of the pivot won’t impact the time complexity. I will be using the last index, because that is what Wikipedia uses in its demonstration graphic, and it is nice to have a visual to coincide with the code.

The array in front of the pivot is split into two: less than the pivot at the front, greater than the pivot at the end. Finally, the pivot itself is moved between the two sub-arrays, then the sub-arrays are sorted by the same quicksort algorithm.

const quickSort = (
  unsortedArray,
  comparator = defaultComparator
) => {

  // Create a sortable array to return.
  const sortedArray = [...unsortedArray];

  // Recursively sort sub-arrays.
  const recursiveSort = (start, end) => {

    // If this sub-array is empty, it's sorted.
    if (end - start < 1) {
      return;
    }
    const pivotValue = sortedArray[end];
    let splitIndex = start;
  };

  // Sort the entire array.
  recursiveSort(0, unsortedArray.length - 1);
  return sortedArray;
};

We create sortedArray as a new array so as not to mutate the original array. This isn’t necessarily required, but it’s good practice.

We create recursiveSort as the recursive function that will take a subarray (from start index to end index) and quicksort it, mutating the sortedArray along the way. The entire array is the first array to be passed to this recursive function.

Finally, the sorted array is returned.

The recursiveSort function has a pivotValue variable to denote the value of our pivot and a splitIndex variable to denote the index delimiting the less-than and greater-than arrays. Conceptually, all less-than values will be at indices less than splitIndex and all greater-than values will be at indices greater than splitIndex. splitIndex is initialized to the start of the subarray, but as we discover values less than the pivot value, we will adjust splitIndex accordingly.

We’ll loop through all the non-pivot values, moving the ones less than the pivot value to before the start index.

const quickSort = (
  unsortedArray,
  comparator = defaultComparator
) => {

  // Create a sortable array to return.
  const sortedArray = [ ...unsortedArray ];

  // Recursively sort sub-arrays.
  const recursiveSort = (start, end) => {

    // If this sub-array is empty, it's sorted.
    if (end - start < 1) {
      return;
    }

    const pivotValue = sortedArray[end];
    let splitIndex = start;
    for (let i = start; i < end; i++) {
      const sort = comparator(sortedArray[i], pivotValue);

      // This value is less than the pivot value.
      if (sort === -1) {

        // If the element just to the right of the split index,
        //   isn't this element, swap them.
        if (splitIndex !== i) {
          const temp = sortedArray[splitIndex];
          sortedArray[splitIndex] = sortedArray[i];
          sortedArray[i] = temp;
        }

        // Move the split index to the right by one,
        //   denoting an increase in the less-than sub-array size.
        splitIndex++;
      }

      // Leave values that are greater than or equal to
      //   the pivot value where they are.
    }

    // Move the pivot value to between the split.
    sortedArray[end] = sortedArray[splitIndex];
    sortedArray[splitIndex] = pivotValue;

    // Recursively sort the less-than and greater-than arrays.
    recursiveSort(start, splitIndex - 1);
    recursiveSort(splitIndex + 1, end);
  };

  // Sort the entire array.
  recursiveSort(0, unsortedArray.length - 1);
  return sortedArray;
};

We move all values less than the pivot value to splitIndex and all leave all other values where they are (by default, greater than the splitIndex, since the split index starts at the beginning of the sub-array).

Once the sub-array has been reordered, we move the pivot itself to the split, since we know it is located between all less-than and greater-than-or-equal-to values.

All values to the left (from start to splitIndex - 1) get recursively sorted and all values to the right (from splitIndex + 1 to end) get recursively sorted. splitIndex itself is now the pivot value, which no longer needs to be sorted.

Conclusion 🔚

You can find the code in this article published in TypeScript on GitHub.

You may also add this code to your projects from NPM.

If you liked this article, feel free to give it a heart or a unicorn. It’s quick, it’s easy, and it’s free! If you have any questions or relevant insight, please leave a comment.

To read more of my columns or contact me, you can find me on LinkedIn, Medium, and Twitter, or check out my portfolio on CharlesStover.com.

Variable length currying in JavaScript

Charles Stover — Wed, 05 Jun 2019 23:44:47 +0000

This is an interesting programming challenge that reddit user i7_leaf claims to have received as an interview question.

Preface ⭐

There is one key difference between the original question and what I will cover in this article. The interview question asked the candidate to write a function that executes as follows:

addSubtract(1)(2)(3);          // 1 + 2 - 3             = 0
addSubtract(1)(2)(3)(4)(5)(6); // 1 + 2 - 3 + 4 - 5 + 6 = 5

It is worth noting that this curried function does not end in any sort of delimiter, e.g. a terminating method .execute() or empty parameter (). What makes this challenge both difficult and interesting is the lack of signal that “this is the last digit in the sequence.”

I agree with the majority of comments in the discussion thread that the interviewer did not mean to ask this question per se. As postulated, this function cannot exist. It is impossible for addSubtract(1)(2)(3) to both be a primitive (the number 0 in the first example) and a function (that accepts 4 as a parameter in the second example).

That said, this is conceptually possible with a very slight tweak. While the following two statements cannot both be true, the third statement can.

// This cannot be true with the following statement.
addSubtract(1)(2)(3) === 0;

// This cannot be true with the preceding statement.
addSubtract(1)(2)(3)(4)(5)(6) === 5;

// This can be true:
addSubtract(1)(2)(3) + addSubtract(1)(2)(3)(4)(5)(6) === 5;

// These can be true too:
+addSubtract(1)(2)(3) === 0;
+addSubtract(1)(2)(3)(4)(5)(6) === 5;

I believe the interviewer was actually testing the candidate’s ability to write a curried function that alternates add and subtract operations, but innocently did not realize the two function examples were mutually exclusive. The scenario in the third statement is such an obscure functionality of JavaScript that I do not support its use as an interview question. It’s a “think outside the box” solution, but not a practical one.

How does it work? 🤔

Any object can be type cast to a string or number using built-in methods.

The use of + in the third example attempts to type cast both sides of the argument to a Number type. If there is no way to type cast to a Number type, it will attempt to typecast to a String type (the same way 'Hello ' + 123 === 'Hello 123'). It is because of our ability to explicitly define how to type cast an object that we are able to solve the problem of addSubtract(1)(2)(3) + addSubtract(1)(2)(3)(4)(5)(6), and it is because of JavaScript lack of type casting when calling the object by itself that it cannot know that addSubtract(1)(2)(3) is the primitive 0. It is, in fact, not the primitive number 0. It is a function, which is why we can both treat it as an object able to be type cast and call it as a function:

const x = addSubtract(1)(2)(3); // function
+x;    // type cast to 0
+x(4); // type cast to 4

When treating an object (or function) as a number, the valueOf method of that object will be called, the return value of which is what is used for the numerical operation. When treating an object as a string, the toString method of that object will be called.

const myStrObject = {
  toString: function() {
    return 'Str';
  }
};
console.log('My object is ' + myStrObject); // 'My object is Str'
console.log(myStrObject + 297);             // 'Str297'

const myNumObject = {
  valueOf: function() {
    return 123;
  }
};
console.log('My object is ' + myNumObject); // 'My object is 123'
console.log(myNumObject + 297);             // 420

Let’s curry 🍛

That’s really all the introduction you need to solve this problem, so I’ll provide the solution.

// Given an array of numbers, if the index is even, add.
//   If the index is odd, subtract.
const addSubtractReducer = (total, current, index) =>
  (index % 2) === 0 ?
    total + current :
    total - current;

const addSubtract = x => {
  const nums = [ ];

  // Recursive function that accumulates numbers for the operation.
  const f = y => {
    nums.push(y);
    return f;
  };

  // When the recursive function is type cast to a number,
  //   reduce the accumulated numbers.
  f.valueOf = () => {
    return nums.reduce(addSubtractReducer, x);
  };

  // Return the recursive function, having added the first digit.
  return f;
};

I defined the reducer function outside of the main function for readability. You may prefer including it in the function for better encapsulation.

The reducer merely alternates addition and subtraction. Given a running total and a new number, if it’s an even index, add; if it’s an odd index, subtract.

The recursive function f is used to curry parameters. Every function call to f just returns f, allowing you to call it ad nauseum, each time adding the new parameter to the array of numbers that we will add/subtract.

The function f has a valueOf property. When we type cast f to a number, this property will get called. Starting with the first provided number (x), this valueOf property reducers the remaining numbers using the aforementioned alternating operations.

The first call to addSubtract then returns the recursive function f after having created it.

Limitations 🙅

In typical interview fashion, this solution is not perfect. If an interviewer were to grill you about limitations, this has weird behaviors when caching the return value of any of the function calls. Each function call beyond the first call to addSubtract will be using the same array of nums. This may cause unintended behavior.

const addTo1 = addSub(1); // nums = [1]
+addTo1(2); // 3             nums = [ 1, 2 ]
+addTo1(2); // 1             nums = [ 1, 2, 2 ]

The nums array is stored inside addTo1. The first call adds 2 to the value. The second call subtracts 2 from the value. This can be resolved by returning a new instance of an array for each function call. The original interview question did not stipulate this as a requirement, so I opted to provide the solution with less code complexity.

Conclusion 🔚

I loved the obscurity of this problem, and users seemed to enjoy my solution. I decided I would share out of love for JavaScript language. If you are an interviewer, do not ask this question during interviews. Make sure your curried examples have the same number of parameters or a terminating method. As a JavaScript expert, I do not believe this is a good interview question for JavaScript comprehension. This knowledge makes for a good puzzle, but not for a better developer. If you are an interviewee, do not expect this during an interview. Ask the interviewer for clarification on the different parameter lengths. It was probably a mistake on their part. (If it wasn’t, at least now you know how to solve it!)

If you liked this article, feel free to give it a heart or a unicorn. It’s quick, it’s easy, and it’s free! If you have any questions or relevant insight, please leave a comment.

To read more of my columns or contact me, you can find me on LinkedIn, Medium, and Twitter, or check out my portfolio on CharlesStover.com.

Manage global state with React hooks.

Charles Stover — Wed, 05 Jun 2019 23:06:25 +0000

Since the announcement of experimental Hooks in React 16.7, they have taken the React community by storm.

Unfortunately, the same way class components only manage local state, the built-in useState React hook only manages local state in functional components. Global state management is still left to higher-order components and community-contributed endeavors.

The reactn package, while also targeting class components, offers React hooks for accessing and managing global state in functional components. The ReactN package intends to integrate global state into React as if it were native functionality. In contrast to libraries like MobX and Redux, which are state-first solutions to state management, ReactN aims to be a React-first solution to global state management.

To read more about or contribute to the ReactN project, the GitHub repository is welcoming to the community. To install ReactN, use npm install reactn or yarn add reactn.

A useState Overview 🏁

Analogous to the built-in React hook useState, the useGlobal hook of ReactN behaves as similar as possible, with a few key differences. To clearly identify these differences, I’ll first provide useState’s behavior.

The useState function takes a default value and returns a 2-item array, where the first item is the state value and the second item is a function that updates that state value.

const [ value, setValue ] = useState(DEFAULT_VALUE);

import { useState } from 'react';

const MyComponent = () => {
  const [ avatar, setAvatar ] = useState('anonymous.png');
  return (
    <img
      alt="Avatar"
      onClick={() => {
        const newAvatar = prompt("Enter your avatar URL:");
        setAvatar(newAvatar);
      }}
      src={avatar}
    />
  );
};

In the above example, MyComponent renders an image anonymous.png (because that is the default value of the state). When you click the image, you are prompted for a new avatar URL. The functional component’s state updates with this new URL, and it re-renders (due to state change), displaying the image you entered instead.

This works great if you want to track the avatar only in this component. But what if you have multiple components that display the user’s avatar? Or multiple instances of this same component? Each instance of MyComponent will have its own instance of state, meaning each instance of MyComponent can have a different state. In many cases like these, developers opt for a global state instead — insuring that all components are in sync with each other. If one component updates the user’s avatar, then all other components displaying the user’s avatar need to update too.

Global State Differences 🆚

An important distinction when dealing with global state is how nonsensical it is to have a default value when instantiating the state. If every component that relied on the user’s avatar had to have a default value, then the value isn’t really global: The components would not be in sync with each other, because each one would have its own, different value. You can give them each the same default value, but at that point you are not using DRY code. Every time you want to change the default value, you have to go through the effort of changing it on every component. Not only is that a huge annoyance, but it opens you up for error when one of the components coincidentally is forgotten about during the change.

Because of this, global state is typically instantiated outside of the components that use it. If the global state is given a value up front, then the components don’t need to provide a default value in case one does not already exist — it does already exist.

Instantiating the Global State 🌞

With ReactN, you can instantiate the global state with the setGlobal helper function. Just provide the state object, and you’re done.

import { setGlobal } from 'reactn';

setGlobal({
  avatar: 'anonymous.png'
});

It is recommended that this occur before ReactDOM.render, because you typically want the state to exist before any components attempt to mount.

Using the Global State 🌎

As mentioned, using the global state is meant to be as straightforward as using the local state. It is a React hook, prefixed with use, placed at the top of your functional component, that returns a 2-item array where the first item is the state value and the second item is a function that updates the state value. Since the default value is instantiated elsewhere, you do not pass the default value as a parameter to the global state hook; instead, it receives the property name of the global state that you want to access. The global state is an object of many different values that you may want to manage throughout your entire application, not a single value. In the instantiation example, we created an avatar property, so we will access it here.

import { useGlobal } from 'reactn';

const MyComponent = () => {
  const [ avatar, setAvatar ] = useGlobal('avatar');
  return (
    <img
      alt="Avatar"
      onClick={() => {
        const newAvatar = prompt("Enter your avatar URL:");
        setAvatar(newAvatar);
      }}
      src={avatar}
    />
  );
};

That’s it. We changed useState to useGlobal and we replaced the default state value with the property we wanted to access. Whenever the global property avatar is updated by any component, all components using useGlobal('avatar') will re-render with the new value.

Can I access the entire global state? 👪

Yes! If you do not provide a property to useGlobal, it will return the entire global state for you to use as you please.

const MyComponent = () => {
  const [ global, setGlobal ] = useGlobal();
  return (
    <img
      alt="Avatar"
      onClick={() => {
        const newAvatar = prompt("Enter your avatar URL:");
        setGlobal({
          avatar: newAvatar
        });
      }}
      src={global.avatar}
    />
  );
};

The same as when you provide a specific property, your component will only re-render if you access a property, not any time the global state is updated. This may be useful if you want to conditionally subscribe to certain properties. Your component will only re-render if it accesses global.property instead of every time global.property updates.

const MyComponent = () => {
  const [ global, setGlobal ] = useGlobal();
  if (global.x) {
    return global.x;
  }
  return global.y;
};

In the above example, if global.x is truthy, your component will only re-render when the x property of the global state updates, not when the y property of the global state updates. This is because the y property of the global state does not impact the render of your component at all!

If the x property is falsey, your component will update whenever either x or y update. This is because both x and y changes will impact the render of your component.

The “magic” here is simply that your component re-renders when there is a change in a global state property that your component has accessed. Above, if x is truthy, the y property is never accessed. The component returns before ever getting the chance. If x is falsey, the y property is accessed.

If you were to useGlobal('x') and useGlobal('y'), you would be accessing both the x and y properties — even if you were to ignore y. As a result, your component would update when the unused y property is changed.

What about Reducers? 🤔

React 16.7 introduced a beautiful hook alongside useState known as useReducer. The useReducer hook allows you to pass a reducer function and initial state. It returns the state and a dispatch function. Unlike setState returned by useState, the dispatch function passes your arguments along to the reducer function.

Here is the reducer demonstrated by the React documentation:

const initialState = { count: 0 };

function reducer(state, action) {
  switch (action.type) {
    case 'reset':
      return initialState;
    case 'increment':
      return { count: state.count + 1 };
    case 'decrement':
      return { count: state.count - 1 };
  }
}

function Counter() {
  const [ state, dispatch ] = useReducer(
    reducer,
    {count: initialCount}
  );
  const reset = () => dispatch({ type: 'reset' });
  const increment = () => dispatch({ type: 'increment' });
  const decrement = () => dispatch({ type: 'decrement' });
  return (
    <>
      Count: {state.count}
      <button onClick={reset}>Reset</button>
      <button onClick={increment}>+</button>
      <button onClick={decrement}>-</button>
    </>
  );
}

In the above example, useReducer returns the state, which defaults to { count: 0 }, and a function that passes your parameters on to the reducer. The reducer takes the current state and your parameters to determine what the new state should be. Since actions such as { type: 'increment' } depend on the current state, the reducer returns the current state plus one.

ReactN uses useDispatch to handle reducers. The above example using global state would look like this:

import { useDispatch } from 'reactn';

setGlobal({ count: 0 });

function reducer(count, action) {
  switch (action.type) {
    case 'reset':
      return 0;
    case 'increment':
      return count + 1;
    case 'decrement':
      return count - 1;
  }
}

function Counter() {

  // Subscribe to changes to count, because our view depends on it.
  const [ count ] = useGlobal('count');

  // Dispatch changes to count using our reducer function.
  const dispatch = useDispatch(reducer, 'count');

  const reset = () => dispatch({ type: 'reset' });
  const increment = () => dispatch({ type: 'increment' });
  const decrement = () => dispatch({ type: 'decrement' });
  return (
    <>
      Count: {count}
      <button onClick={reset}>Reset</button>
      <button onClick={increment}>+</button>
      <button onClick={decrement}>-</button>
    </>
  );
}

Summary 📝

Similarities:

useGlobal and useDispatch are React hooks.
useGlobal returns a value and a function for changing that value.
useDispatch supports reducers.
useDispatch returns a function for changing the current state.

Differences:

useGlobal takes an property name instead of an initial value.
useGlobal can return the entire global state by not providing a parameter.
useDispatch takes a property name in addition to a reducer.
useDispatch does not (currently) return the value of the property, so as not to subscribe to it.
- If your Component only updates the value, it does not need to re-render when that value changes. It may not display that value at all.

To install ReactN, use npm install reactn or yarn add reactn.

Conclusion 🔚

Community feedback and pull requests for improving the useGlobal and useDispatch React hooks, as well as the plethora of other global state features of the ReactN package, are appreciated on the GitHub repository.

If you liked this article, feel free to give it a heart or unicorn. It’s quick, it’s easy, and it’s free! If you have any questions or relevant great advice, please leave them in the comments below.

To read more of my columns, you may follow me on LinkedIn, Medium, and Twitter, or check out my portfolio on CharlesStover.com.

React Suspense with the Fetch API

Charles Stover — Wed, 05 Jun 2019 21:21:09 +0000

Dan Abramov, in response to a React developer asking why Suspense was not responding to the fetch API:

From the legend Dan Abramov himself, we receive such gems as “There is [no data fetching solution compatible with React Suspense] that exists yet,” and “[React Cache] will be the first one,” and “Suspense is limited to code splitting.”

If I have one thing to tell Daniel “Abra Cadabra” Abramov, besides how impressed I am with his work, it’s this:

Let’s reveal the magic behind the curtain that is React Suspense. For educational purposes, I’ll cover how I created this package.

Shut Up and Give Me the Package! 💰

If you’re just here for solutions, I don’t blame you. You can find fetch-suspense on NPM and the most extensive documentation of your life on the GitHub repository.

import useFetch from 'fetch-suspense';

const MyComponent = () => {

  // "Look! In the example! It's a fetch() request! It's a hook!"
  //   "No! It's kind of like both at the same time."
  const serverResponse = useFetch('/path/to/api', { method: 'POST' });

  // The return value is the body of the server's response.
  return <div>{serverResponse}</div>;
};

How Does Suspense Work? 🔮

A lot of the new React features are built into the React library, as opposed to being external packages, due to the performance benefits of being tightly coupled to the engine that powers React, known as React Fiber.

Due to React Fiber’s direct integration with features such as Suspense and hooks, you cannot create a verbatim copy of Suspense in React 16.5. However, you can probably make a less performant polyfill. I’ll use some polyfill examples so that you can conceptualize what is happening with Suspense.

class Suspense extends React.Component {

  constructor(props) {
    super(props);
    this.state = {
      error: null
    };
  }

  componentDidCatch(e) {
    this.setState({ error: e });
  }

  render() {
    if (this.state.error) {
      return this.props.fallback;
    }
    return this.props.children;
  }
}

/*
<Suspense fallback={<Loading />}>
  <ErrorThrower />
</Suspense>
*/

Here is ye olde class component: a fossil remnant of yonder days of React development. The componentDidCatch method is a method that fires whenever a child component throws an error. This allows you to replace uncaught JavaScript errors with a nice UI for your users or otherwise implement important logic during application errors.

What the above does is mounts Suspense. Since there is no error in the local state, the children of Suspense are mounted too. In this case, the <ErrorThrower /> component is mounted, and it throws an error.

That error bubbles up to the Suspense instance, where the componentDidCatch method receives it. It handles that error by saving it to its state, causing it to re-render.

Now that it has rendered with an error in its local state, it no longer renders its children prop, nor the <ErrorThrower /> devil-child as a result. Instead, it renders its fallback prop, which we have set to a nice <Loading /> modal.

This is how Suspense works now, except instead of throwing errors, JavaScript Promises are thrown. When Suspense catches a Promise, it re-renders, displaying the fallback prop instead of the children that previous threw a Promise. When the Promise resolves, it re-renders again; this time no longer displaying the fallback prop, and instead attempting to re-render the original children, under the presumption that the children are now ready to be rendered without throwing Promises around like they’re meaningless.

An implementation may look something like this:

class Suspense extends React.Component {

  constructor(props) {
    super(props);
    this.state = {
      promise: null
    };
  }

  componentDidCatch(e) {

    // Drake meme where he says no to errors here.
    if (e instanceof Error) {
      throw e;
    }

    // Drake meme where he says yes to promises here.
    if (e instanceof Promise) {
      this.setState({
        promise: e
      }, () => {

        // When the promise finishes, go back to rendering the original children.
        e.then(() => {
          this.setState({ promise: null });
        });
      });
    }

    // This line isn't compatible with the Drake meme format.
    else {
      throw e;
    }
  }

  render() {
    if (this.state.promise) {
      return this.props.fallback;
    }
    return this.props.children;
  }
}

/*
<Suspense fallback={<Loading />}>
  <PromiseThrower />
</Suspense>
*/

It’s important to note here that the original children attempted to render before the fallback occurred. It never succeeded.

How Does This Apply to Fetch Hooks? 🎣

What you should have gathered by now is that the fetch hook will need to throw Promises. So it does. That promise is conveniently the fetch request. When Suspense receives that thrown fetch request, it falls back to rendering its fallback prop. When that fetch request completes, it attempts to render the component again.

There’s just one little tricky dicky problem with that — the component that threw the fetch request had only attempted to render, but did not succeed. In fact, it is not a part of the fallback at all! It has no instance. It never mounted. It has no state (not even a React hook state); it has no component lifecycle or effects. So when it attempts to render again, how does it know the response of this fetch request? Suspense isn’t passing it, and it — not being instantiated — cannot have data attached to it.

Golly, How Do You Solve That Conundrum? 🤔

We solve it with memoization!

“Like that fancy new React.memo feature?”

“Yes!” (in concept)

“No!” (more literally)

It does not use React.memo, which memoizes React components based on their props. Instead, I use an array of infinite depth to memoize the parameters passed to fetch.

If a request comes in to fetch data that has been requested before (the second attempt to instantiate after the first attempt failed with a Promise), then it simply returns the data that eventually resolved from the first request’s Promise. If this is a fresh request, then we fetch it, cache it in the memoization array, and throw the fetch Promise. By comparing the current request to all entries in the memoization array, we know if we have dispatched this request before.

const deepEqual = require('deep-equal');

interface FetchCache {
  fetch?: Promise<void>;
  error?: any;
  init: RequestInit | undefined;
  input: RequestInfo;
  response?: any;
}

const fetchCaches: FetchCache[] = [];

const useFetch = (input: RequestInfo, init?: RequestInit | undefined) => {
  for (const fetchCache of fetchCaches) {

    // The request hasn't changed since the last call.
    if (
      deepEqual(input, fetchCache.input) &&
      deepEqual(init, fetchCache.init)
    ) {

      // If we logged an error during this fetch request, THROW the error.
      if (Object.prototype.hasOwnProperty.call(fetchCache, 'error')) {
        throw fetchCache.error;
      }

      // If we received a response to this fetch request, RETURN it.
      if (Object.prototype.hasOwnProperty.call(fetchCache, 'response')) {
        return fetchCache.response;
      }

      // If we do not have a response or error, THROW the promise.
      throw fetchCache.fetch;
    }
  }

  // The request is new or has changed.
  const fetchCache: FetchCache = {
    fetch:

      // Make the fetch request.
      fetch(input, init)

        // Parse the response.
        .then(response => {

          // Support JSON.
          if (Object.prototype.hasOwnProperty.call(response.headers, 'Content-Type')) {
            return response.json();
          }

          // Not JSON.
          return response.text();
        })

        // Cache the response for when this component
        //   attempts to render again later.
        .then(response => {
          fetchCache.response = response;
        })

        // Cache the error for when this component
        //   attempts to render again later.
        .catch(e => {
          fetchCache.error = e;
        }),
    init,
    input
  };

  // Add this metadata to the memoization array.
  fetchCaches.push(fetchCache);

  // Throw the Promise! Suspense to the rescue!
  throw fetchCache.fetch;
};

That Sounds Like a Memory Leak 💧

It can be a feature or a bug!

But if you think it’s a bug in your project, you can invalidate the cache by providing a lifespan in milliseconds to the fetch request. Passing a third parameter (a number) to the useFetch hook will tell it to remove the metadata from the memoization array after that many milliseconds. We implement it as easily as so:

// NEW: lifespan parameter
const useFetch = (
  input: RequestInfo,
  init?: RequestInit | undefined,
  lifespan: number = 0
) => {

  // ...

  const fetchCache: FetchCache = {
    fetch:

      // Make the fetch request.
      fetch(input, init)
        .then( /* ... */ )
        .then( /* ... */ )
        .catch( /* ... */ )

        // Invalidate the cache.
        .then(() => {

          // If the user defined a lifespan,
          if (lifespan > 0) {

            // Wait for the duration of the lifespan,
            setTimeout(
              () => {

                // Find this fetch request and kill it
                //   from the memoization array.
                const index = fetchCaches.indexOf(fetchCache);
                if(index !== -1) {
                  fetchCaches.splice(index, 1);
                }
              },
              lifespan
            );
          }
        }),
    // ...
  };
  // ...
};

// ...

When the fetch has completed, and we’ve updated the metadata, tick-tock. It’s important that the lifespan timer occurs after the catch of the Promise, because we want it to set even if an error occurred.

Conclusion 🍬

When Dan Abramov tells you that you can’t do something, you do it.

If you liked this article, feel free to give it a heart or a unicorn. It’s quick, it’s easy, and it’s free! If you have any questions or relevant great advice, please leave them in the comments below.

To read more of my columns, you may follow me on LinkedIn, Medium, and Twitter, or check out my portfolio on CharlesStover.com.

How to convert withRouter to a React hook.

Charles Stover — Wed, 05 Jun 2019 18:46:36 +0000

One of the greatest benefits of React Hooks in the new v16.7 is the removal of the reliance on higher-order components. While in the process of migrating my class states to functional hooks, I was giddy at the opportunity to port my with-router higher-order component to a hook as well. I have been using this custom implementation to re-render my components on route change. react-router's built-in withRouter HOC does not re-render components on route change, and it is a difficult issue to work around.

This article should serve as a tutorial for implementing a React hook with pub-sub functionality. Pub-sub, short for “publish-subscribe,” is a programming methodology wherein a set of subscription processes become notified when an update is published. In short, when the location changes (the published event), I want to re-render my component (the listener subscription).

The final product requires React Router v4.4 or greater, as previous versions of React Router did not expose the Router Context, which we are using to listen to location changes. If the latest version of React Router is not accessible to you, you can listen to the window history state as an alternative. I opted to use the same “single source of truth” that react-router uses, insuring that my states are always in sync.

You may use this package yourself via use-react-router on NPM or contribute to, fork, or otherwise spy on the open-source GitHub repository.

The User Experience 🙃

I start every project by asking the question, “What do I want to do?” This does not mean, “How do I want to implement this feature?” It means, as a developer, how do I wish this feature was already implemented. What do I want to have to do to use this feature in the future? How do I make it intuitive and easy to use?

Luckily, withRouter is not a difficult implementation, so neither is its hook.

I will want to import a hook from a default package export.

import useReactRouter from 'use-react-router';

I want to call that hook and be done with it.

const { history, location, match } = useReactRouter();

This declutters the history, location, and match props from my component and allows me to pick and choose which I want to have exist.

I do not want to have to implement further logic to re-render on location change. I want that functionality to be already implemented, in stark contrast to react-router's implementation of the HOC. That’s just personal preference, and you may agree with their implementation instead. This tutorial will discuss how to implement either, as it is a common feature request, and it was highly relevant to my personal use case.

The Implementation

The Dependencies 👶

First, our dependencies.

We will need the router context from the react-router package, as it contains the data we are wanting to access in our component, and we will need the useContext hook from the react package to “hook” to the Router Context. Since we are implementing pub-sub functionality, we also need the useEffect hook built into React. This will allow us to subscribe and unsubscribe from the location changes.

import { useContext, useEffect } from 'react';
import { __RouterContext } from 'react-router';

Lastly, I am going to import useForceUpdate from the use-force-update NPM package. It is merely a shorthand for calling the useState hook to force a re-render, which is what we’ll be doing when the location changes.

import useForceUpdate from 'use-force-update';

The Hook 🎣

With our dependencies imported, we can begin writing the hook

const useReactRouter = () => {
  const forceUpdate = useForceUpdate();
  const routerContext = useContext(__RouterContext);
  /* TODO */
  return routerContext;
};

We begin by instantiating all other hooks that we’ll be needing. forceUpdate is a now a function that, when called, re-renders the component. routerContext is now the contents of the react-router context: an object with history, location, and match properties — the very same that you would expect to receive as props from withRouter.

If you do not want the re-rendering functionality, you can stop here. You can remove the forceUpdate variable, the useEffect import, and use-force-update dependency. I would advise using an external useReactRouter hook over calling useContext within your component solely because of the __RouterContext name and @next semvar currently needed to access React Router v4.4. Accessing this context may be subject to change, and making that adjustment in the single package is significantly less work than making that adjustment in every router-dependent component you use in your project. It is also ever-so-slightly more intuitive for developers to useReactRouter than useContext(__RouterContext) — the additional context import is redundant and unchanging.

The Pub-Sub 📰

To implement pub-sub behavior, we will want to useEffect. This will allow us to subscribe on component mount and unsubscribe on component unmount. Theoretically, it will unsubscribe from an old context and re-subscribe to a new one if the router context were to change (a desirable behavior if that were to happen), but there’s no reason to assume that will ever happen.

Replace our /* TODO */ with the following:

useEffect(
  () => {
    // TODO: subscribe
    return () => {
      // TODO: unsubscribe
    };
  },
  [ /* TODO: memoization parameters here */ ]
);

useEffect takes a function that will execute every mount and update. If that function returns a function, that second function will execute every unmount and pre-update.

Where effect1 is the outer function and effect2 is the inner function, the component lifecycle executes like so:

mount > effect1 ... effect2 > update > effect1 ... effect2 > unmount

The outer function executes immediately after a mount or update. The inner function waits until the component is about to update or unmount before executing.

Our goal is to subscribe to location changes once our component has mounted and unsubscribe to location changes just before our component unmounts.

The memoization array of useEffect says “do not execute these effect functions on update unless this array of parameters has changed.” We can use this to not continuously subscribe and unsubscribe to location changes just because the component re-rendered. As long as the router context is the same, we do not need to alter our subscription. Therefore, our memoization array can contain a single item: [ routerContext ].

useEffect(
  function subscribe() {
    // TODO
    return function unsubscribe() {
      // TODO
    };
  },
  [ routerContext ]
);

How do you subscribe to location changes? By passing a function to routerContext.history.listen, that function will execute every time the router history changes. In this case, the function we want to execute is simply forceUpdate.

useEffect(
  function subscribe() {
    routerContext.history.listen(forceUpdate);
    return unsubscribe() {
      // TODO
    };
  },
  [ routerContext ]
);

And how do you unsubscribe from location changes? We can’t just let this subscription exist after the component unmounts — forceUpdate will be called, but there won’t be a component to update!

routerContext.history.listen returns an unsubscribe function that, when called, removes the subscription listener (forceUpdate) from the event.

useEffect(
  () => {
    const unsubscribe = routerContext.history.listen(forceUpdate);
    return () => {
      unsubscribe();
    };
  },
  [ routerContext ]
);

Not that there is any benefit to this, but if you want to make this code a little shorter, you can:

useEffect(
  () => {
    const unsubscribe = routerContext.history.listen(forceUpdate);
    return unsubscribe;
  },
  [ routerContext ]
);

And even shorter:

useEffect(
  () => routerContext.history.listen(forceUpdate),
  [ routerContext ]
);

Where to Go From Here? 🔮

The HOC implementation of withRouter provided by the react-router package pulls history, location, and match from component props and gives them higher priority than the context API’s values. This is likely due to the <Route> component providing these as props, and match’s value needing to come from Route's path interpretation.

While I have not harnessed this in my package yet, I think a solid next step would be to use the hooked component’s props as a parameter to useReactRouter, allowing it to use the same prop prioritization.

Conclusion 🔚

If you want to contribute to this open-source package or see it in TypeScript, you can star it, fork it, open issues, or otherwise check it out on GitHub. You may use this package yourself via use-react-router on NPM.

To read more of my columns, you may follow me on LinkedIn, Medium, and Twitter, or check out my portfolio on CharlesStover.com.

No-boilerplate global state management in React

Charles Stover — Wed, 05 Jun 2019 17:20:22 +0000

When your React application reaches a certain size and scope, attempting to manage state within component instances adds too much complexity, prop drilling, and code smell. Developers inevitably turn to global state management tools, such as MobX or Redux, to solve these problems and make their lives simpler. I strongly endorse Redux and use it in my personal projects, but not all developers share my sentiment.

I have worked on quite a few large projects that have demanded a global state powerhouse behind the React UI. No matter application size, team size, or member seniority, the almost universal opinion of these global state management packages has been overwhelmingly negative.

The top two complaints? Boilerplate and learning curve. While these packages solve a lot of problems and solve them well, it is not without cost. Developers are not happy with how many files, code blocks, and copy-pasting is required to set up or modify their global states. More importantly, junior developers have a hard time overcoming the learning curve required of them. Creating a global store is a nightmare for some, and extending it with functionality, such as developer tooling and asynchronous features, was a task that took too much company time and caused too many employee headaches.

I polled many developers to gauge their top complaints when integrating global state management into their React applications. You can skip to the end of the list if you don’t want to read them all. These excerpts are merely outline common difficulties when integrating global state into React applications and barriers faced by real React developers.

“Newer developers may require a longer ramp-up time along with proper training.”
“New developers have a problem with flux architecture and functional concepts… They should essentially be producing events that describe how the application changes instead of imperatively doing it themselves. This is vastly different than the more familiar MVC-esque patterns.”
“I found trying to manage a complex state tree in Redux very challenging and abandoned it early on for my app. I really struggled to understand what best practices are outside of simple to-do app examples. I just never really understood how to use Redux in a real-world app with a complex state.”
“It often feels tedious to do trivial state changes.”
“It takes junior developers some time to get their head around the magic of autoruns, reactions, etc. Debugging becomes harder when you have to step through MobX code in order get to your own.”
“It’s annoying that Redux does not handle asynchronous actions out of the box. You have to spend a day figuring out this basic and essential use case. You have to research thunks and sagas. Then, you still have to figure out how to tie them in with actions. It’s a lot to deal with and makes you wish for good old Promises.”
“For Redux, I dislike that it creates a side-effects vacuum, which has to be filled by a bunch of middlewares. There is a problem in that none of the middlewares out there are perfect.”
“Whenever I use Redux, I ask myself, ‘What on earth was I thinking?’ It overcomplicates everything. Some would argue that the benefit of Redux is that you can choose the features you need (immutable, reselect, sagas, etc.); but in the end, you’ll be adding all of these to every project anyway.”
“Redux requires a ton of files to establish a new reducer. A lot of the advantages in practice do not tend to be worth the disadvantages.”
“Redux has too much boilerplate, and I have to maintain all of it.”
“You really need to use decorators for MobX. The non-decorator syntax is not nice, and it’s a big dependency.” MobX currently weighs in at 47kB.
“Redux requires a ton of tedious code to do the most basic things: declare your action name in your action file, create a saga file, add it to your root sagas, create your action generator to call the saga, connect your component to Redux so it can access the store, write mapStateToProps which calls a selector, write your selector to get your user info out of the store, write a mapDispatchToProps so you can dispatch an action in your component, dispatch an action in your component’s componentDIdMount, add an action to handle the result of your network request, write a reducer that saves the user info to the store, add another action to handle an error, add another action to handle loading state, write selectors and reducers for the error and loading actions, call your selector in the render function of your component to get and display the data. Does that seem reasonable for a simple network request? Seems like a pile of hot garbage to me.” While I’m not as experienced with sagas, I will plug my methodology for handling API requests with redux thunk.
“Global state packages are very cumbersome and complex to set up. They violate the KISS principle — Keep It Simple, Stupid.”

After this list, I feel the need to reiterate: I am a fan of Redux, and I use it on my personal projects. The purpose of this article is not to trash Redux or MobX, or to propose that they are flawed systems. It is to highlight a real issue: There is difficulty integrating these packages into real applications, and most of this difficulty seems to stem from the learning curve. These packages are “too clever” and are not as accessible to junior developers, who tend to make up the majority of contributors to projects.

One piece of feedback I received explicitly blamed the users of the packages: “Users don’t put enough effort into evaluating their needs; don’t use [the packages] judiciously or as advised; don’t give a second thought to any dependencies they add; and never revisit their design decision, then complain about them.” I think they were onto something. I don’t think Redux or MobX are innately flawed, but I think there is a real difficulty in integrating them into enterprise projects. They may not be the best solution, not out of function, but out of complexity.

I am hoping with the release of React 16.7 Hooks and its re-conceptualization of how a readable React application looks, we will see global state solutions that harness creative new methods that appeal to wider audiences. With the ultimate goal of no boilerplate and intuitive syntax, this article will offer my opinion on how a global state management system for React can be structured and finally my open-source attempt of that implementation.

You may use this implementation yourself via reactn on NPM or contribute to, fork, or otherwise spy on the open-source GitHub repository.

Keep It Simple, Stupid 💋

An Intuitive Approach

My personal take on the matter is that global state management systems appear to be designed with global state management in mind, not React. They are designed so broadly that the intention is to be usable even outside of React projects. That’s not a bad thing, but it is unintuitive for junior developers who may already be overwhelmed by learning React.

React has state management built-in — this.state, this.setState, and the new useState and useReducer hooks. I posit that global state management should be as simple as local state management. The migration to or from global state should not require an entirely new skill set.

We read from and write to a local component state using the following syntax:

// Class Component
this.state.name;
this.setState({
  name: 'Charles',
});

// Functional Component
const [ name, setName ] = useState('Default Name');

We should be able to harness the power of global state similarly:

// Class Component
this.global.name;
this.setGlobal({
  name: 'Charles',
});

// Functional Component
const [ name, setName ] = useGlobal('name');

Each property on the global member variable this.global can harness a getter that subscribes that component instance to property changes in the global store. Whenever that property changes, any instance the accessed it re-renders. That way, updating property name in the global store does not re-render a component that only accesses property this.global.age, but it does re-render components that access this.global.name, as would be intuitive behavior of a state change.

As a technical necessity, a global hook would need the property name (instead of a default value) in order to access that specific property. I would opt away from a default value on a global hook. Almost by definition, a global state property is to be accessed by multiple components. Having to put a default on each component, which should theoretically be the same default value for all instances of that property, is not DRY code. Global defaults should be managed externally, such as an initializer.

And if you want the entire global state object in a hook:

const [ global, setGlobal ] = useGlobal();

Though a functional component, global would be analogous to this.global and setGlobal would be analogous to this.setGlobal in a class component.

No Boilerplate 🔩

Minimal Setup or Modification

When we strip a lot of the features of Redux or MobX that developers find unnecessary, tedious, or otherwise superfluous, there isn’t much boilerplate needed. Especially when we gear our package towards React itself and not on being a global state solution for the Internet as a whole.

If we want this.global and this.setGlobal in class components, then it needs to be on the class each component extends — React.Component and React.PureComponent. That new class, with global state functionality, would extend the original React.Component or React.PureComponent. There are a few different ways to go about this. I opted for what I would consider to be the easiest for any developer: a single byte change.

The package, named ReactN, exports an exact copy of React, except the Component and PureComponent properties extend the originals by adding the global member variable and setGlobal method.

import React from 'react'; // before
import React from 'reactn'; // after

Whenever you add this single byte to a file, all references to React.Component and React.PureComponent now have global functionality built in, while all references to other React functionality, such as React.createElement are completely unaltered. This is accomplished by copying the references to the same React package you are already using to a new object. ReactN is lightweight as a result, as opposed to a copy-paste clone of the React package, and it doesn’t modify the original React object at all.

But what if you don’t want the React object that you import to have these new properties? I completely understand. The default import of ReactN also acts as a decorator.

import React from 'react';
import reactn from 'reactn';

@reactn
export default class MyComponent extends React.Component {
  render() {
    return <div>{this.global.text}</div>;
  }
}

No decorator support in your create-react-app? Class decorators are easy to implement in vanilla ES6.

import React from 'react';
import reactn from 'reactn';

class MyComponent extends React.Component {
  render() {
    return <div>{this.global.text}</div>;
  }
}

export default reactn(MyComponent);

One of these three solutions should meet the style guidelines of your team, and any of the three options have no more than one line of “boilerplate” to implement.

But what about setting up the store? The aforementioned initializer? The aforementioned Redux nightmare? My best solution thus far is to simply pass a state object synchronously, but I feel it’s an area that could use some improvement from community feedback.

import { setGlobal } from 'reactn';

setGlobal({
  a: true,
  b: false,
  name: 'Charles',
  age: 'Forever 21'
});

React Hooks 🎣

“I’m sorry, is this 24 Oct. 2018? React Hooks are here now, and I never have to use a class component again!”

You’re right. React global state management solutions should harness the power of React Hooks — after all, functional components use useState, so in order to be intuitive to what React developers already know and use, there should be an analogous global state hook.

import React, { useState } from 'react';
import { useGlobal } from 'reactn';

const MyComponent = () => {
  const [ localText, setLocalText ] = useState('Hello world!');
  const [ globalText, setGlobalText ] = useGlobal('text');
  return <div>{localText}... {globalText}</div>;
};

We can offer a completely analogous solution; and, as it should, it shares global state with the global text property used in the class component demo. There’s no reason why functional and class components can’t share their global states. Using hooks-within-hooks, we can force a component to re-render when a global state property to which it is “hooked” changes — just as you would expect with local state.

A little more versatile, we can use useGlobal the same way class components use it. This may be more accessible to the user migrating from classes.

import React from 'react';
import { useGlobal } from 'reactn';

const MyComponent = () => {
  const [ global, setGlobal ] = useGlobal();
  return (
    <button
      onClick={() => {
        setGlobal({
          x: global.x + 1
        });
      }}
    >
      Click Me {global.x}
    </button>
  );
};

setGlobal also accepts a function parameter, the same way this.setState does.

setGlobal(oldGlobal => ({
  x: oldGlobal.x + 1
}));

Reducers: Modern Staples of State Management 🔉

With Redux’s dependency on reducers and React 16.7’s introduction of useReducer, I simply couldn’t pretend that reducers aren’t a modern day implementation of state management. How do you manage a third party global state without the boilerplate of reducers?

I’ve implemented two solutions. One, for class syntax:

import { addReducer } from 'reactn';

// this.dispatch.addCard('Ace of Spades')
addReducer('addCard', (state, dispatch, card) => ({
  cards: state.cards.concat([ card ]),
}));

This introduces the familiarity of Redux reducers with less boilerplate: the functions are smaller and easier to code split, and there are no higher-order components to cloud the React component tree. Altogether this, to me, feels more maintainable.

The second solution is inspired by the functional useReducer.

import { useDispatch } from 'reactn';

const addCardReducer = (cards, card) =>
  cards.concat([ card ]);

const MyComponent = () => {

  // addCard takes a card and concats it
  //   to the global state cards property.
  const addCard = useDispatch(
    addCardReducer, // <-- reducer function
    'cards', // <-- the property being reduced
  );

  // Display a button.
  return (
    <button
      onClick={() => {

        // Add "Ace of Spades" to the global state.
        addCard('Ace of Spades');
      }}
    >
      Click me
    </button>
  );
};

Like useReducer, you can use this returned dispatch function to modify the global state. Your reducers can thus be code split or even imported if that is preferred to the aforementioned addReducer. If addReducer is preferred, you can still access your added reducers in functional components via const addCard = useDispatch('addCard');.

Conclusion 🔚

This isn’t the documentation for ReactN, so I won’t detail the bells and whistles. I do want to outline a system that I believe is significantly more intuitive to React developers, in hopes that it may inspire creativity that is targeted to React solutions. There is absolutely no reason a global state package should require so much boilerplate or add so much complexity to a project. All of the above takes up a whopping 4.3kB, and supports asynchronous state change out of the box (with no need for middleware).

If you want to contribute to this project, it is open-source on GitHub, and I would be absolutely ecstatic for more community feedback. If you want to play around with this project, simply npm install reactn or yarn add reactn.

To read more of my columns, you may follow me on LinkedIn, Medium, and Twitter, or check out my portfolio on CharlesStover.com.

The Fetch API and asynchronous Redux state

Charles Stover — Wed, 05 Jun 2019 15:33:09 +0000

If you are building a complex React application, you are likely using a back end service and an API. If you are managing state in React, you likely are using redux. Both are great choices that I would highly recommend for your React application's architecture. However, redux's out-of-the-box synchronous state manipulation is not particularly compatible with asynchronous server responses, leaving many developers scratching their heads. There are a lot of states involved in an asynchronous call, but isn't an API call just a single action?

I would like to walk you through the standardized states involved in an asynchronous API call and their relationship to the redux store.

By the end of this article, you should understand how to write an asynchronous redux action that handles each state of an API call. Each API call has the same states and logic behind when those states are triggered, so in order to prevent copy-pasting the same boilerplate for each asynchronous redux action, I will also offer an open-source package that I've used almost religiously that will handle the action creation for you.

Prerequisites 📍

To enable asynchronous actions on your redux store, you will want to apply the redux-thunk middleware.

For API calls, I will be using the standardized fetch API. If your target browser does not support the fetch API, I would recommend a fetch polyfill. I also recommend using an AbortController polyfill if you want to be able to abort your API calls, but not if you do not desire this feature. If you prefer an alternative to the fetch API, such as axios or XMLHttpRequests, they are absolutely capable of handling asynchronous Redux state management, but my code examples will be based on the fetch API.

What is an asynchronous action? 🐌

The first step is understanding what you are creating - unlike previous action creators that returned an action object that was immediately sent to the reducers, an asynchronous action is not an object but a function that is immediately invoked. That function accepts two parameters, each of which is a function. The first is the dispatch function, used to dispatch an action; the second is a getState function, used to get the current Redux state.

// Synchronously add an employee.
// addEmployee("Bob");
const addEmployee = (name) => ({
  type: 'ADD_EMPLOYEE',
  name
});



// Asynchronously add an employee.
// addEmployeeAsync("Bob")
const addEmployeeAsync = (name) => {

  // Since the return value of this action creator
  //   accepts dispatch as a parameter instead of
  //   returning what is to be dispatched,
  //   I may dispatch at my leisure and as many times as I want.
  return (dispatch, getState) => {

    // I want to immediately and synchronously add the employee.
    dispatch(addEmployee(name));

    // I want to asynchronously remove the employee.
    // This is a second action in a single action creator.
    setTimeout(
      () => {
        dispatch(removeEmployee(name));
      },
      0
    );

    // I want to asynchronously re-add that employee after 5 seconds.
    // This is a third action in a single action creator.
    setTimeout(
      () => {
        dispatch(addEmployee(name));
      },
      5000
    );
  };
};

Normally, when your action creator returns an object, that object gets passed to your reducer. Now, when your action creators return functions, the redux-thunk middleware will immediately invoke that function instead of passing it to the reducer. That function can do anything. Unlike other action creators, this function does not return the action object. Using the dispatch parameter, you can dispatch action objects to the reducer. The upside of manually dispatching them instead of returning them is that you can dispatch as many actions as needed, such as one for each state in an API call, despite having only dispatched one action creator.

In summation, your components dispatch one asynchronous action (in this case, addEmployeeAsync). That asynchronous action in turn dispatches multiple actions (addEmployee, removeEmployee, then addEmployee again). There is no reason to add, remove, then add again. It’s just an example of your freedom in design.

The States of the Fetch API 🎌

Now that we know how to create an action that can dispatch multiple states over time, let’s identify and dispatch the states of a fetch request.

The first state of an API request is requested (loading). The request has been dispatched, but we have not yet received a response.

The subsequent state of an API request is either received (success) or rejected (error) depending on the response from the server.

The final, potential state of an API request is aborted (cancelled) for if you or the user terminates the request before receiving a response.

For each API endpoint required to power your application, an initial Redux state may look something like this:

{
  "myApiData": {
    "abortController": null,
    "aborted": false,
    "error": null,
    "loading": false,
    "response": null
  }
}

You will want an action for each of these states, since each of the API request’s states should be reflected in your application.

// When the API is requested,
//   this action is sent to the reducer.
// The abortController tied to the request,
//   so passed to the request action creator.
// You may store it in your redux state for future use.
const requestMyApi = abortController => ({
  type: 'REQUEST_MY_API',
  abortController
});

// When the API responds,
//   this action is sent to the reducer.
// It includes the response, which is probably
//   the entire point of this process.
const receiveMyApi = response => ({
  type: 'RECEIVE_MY_API',
  response
});

// When the API fails to respond,
//   this action is sent to the reducer.
// The provided error is included, which can
//   be used to display to users or debug.
const rejectMyApi = err => ({
  type: 'REJECT_MY_API',
  error: err
});

// When the API request has been aborted or cancelled,
//   this action is sent to the reducer.
const abortMyApi = () => ({
  type: 'ABORT_MY_API'
});

The Abort Action 🙅

In order for the API request to notify the developer that it has been cancelled, it must be passed an AbortSignal at instantiation. Despite this not being the first action dispatched, it will be the first we write, because it must be written before the API request is initialized.

let abortController = null;
let signal;

// Since AbortController is not well-supported yet, we check for its existence.
if (typeof AbortController !== 'undefined') {
  abortController = new AbortController();
  signal = abortController.signal;
  signal.addEventListener('abort', () => {
    dispatch(abortMyApi());
  });
}

If the browser supports it, we create an AbortController, and we add a listener for the abort signal. When the abort signal event occurs, we dispatch the abort action. The AbortController will later be passed as a part of the request action. This allows you to store it in your redux state, giving your components and users access to manually abort an API request via the controller.

When a ABORT_MY_API action is received by your reducer, you can manipulate the state accordingly: It is no longer loading, there was no response, there was no error, and it was aborted. You may prefer replacing the aborted flag with an error string to simplify your logic, if that matches your use case. I would suggest against it, however, due to such logic differences as “Can the user re-request the payload if they aborted the previous one? If an error occurred during the previous one?”

The Request Action 📞

You should use the request action to enable a loading view. Consider using a loading animation or text to notify your user that something is happening. The feedback goes a long way in making your application feel responsive. The REQUEST_MY_API action will toggle the state.myApi.loading from false to true. Your components can now respond to this redux state accordingly. Components that depend on the response from my API can display that they are in the process of loading.

Since a request is instantiated immediately, you can dispatch that action immediately in your asynchronous action creator: dispatch(requestMyApi(abortController)).

Since we have told the reducer that we have requested the data, we should actually request it: fetch(URL, { signal }). You can adjust your fetch options as needed. The signal is the one created as a part of the abort handler above.

It takes more than just requesting the data, we also need to handle the response.

The Response Action 🙌

Once the fetch Promise resolves, we can take that response, parse it accordingly (as text or JSON), and send the parsed data to the reducer, making it accessible to your components.

fetch(URL, { signal })
  .then(response => {

    // If this payload is JSON, use this:
    return response.json();

    // If this payload is not JSON, use this:
    return response.text();
  })
  .then(data => {

    // Now that we've parsed the response,
    //   we can send it to the reducer.
    dispatch(receiveMyApi(data));
  });

The Error Action ❌

The error action is even easier. Since we’re working with promises, we just catch!

fetch(URL, { signal })
  .then(parseData)
  .then(receiveMyApi)
  .then(dispatch)
  .catch(err => {

    // An error occurred at some point in this Promise.
    // Pass the error to the reducer.
    dispatch(rejectMyApi(err));
  });

Considerations 🤔

There is more complex error-handling involved if your API is successfully responding with error status codes and an error message as a part of the parsed payload. I won’t cover that case in detail here, because it does not apply to all APIs, but you can see how I handled it in the source code of this package.

You also have the power of the getState function. You may use the current redux state to modify (or even ignore) your current fetch request. Depending on the scenario and action, sometimes I will get the current state to see if the request is already loading or has responded in the past. If it has, I just don’t fetch. The async action was clearly dispatched in error, so I can safely ignore it — I already have the data, so fetching it will provide me with no benefit.

Can’t Most of This Be Automated? 🤖

Yes! The fetch-action-creator package does all of the above so that you don’t have to copy-paste this boilerplate for every API action. Every API call will do the same series of things: create an abort controller and signal, fetch the request, parse the response, check the response for error status codes, and dispatch an action for each of the four states involved in the process.

If I love anything, it’s DRY code! That’s why I use and recommend a function that will do all of these things for you. All you are left to do is provide the differences between any two given API calls: a unique identifier, the URL, and the fetch options.

Just npm install fetch-action-creator or yarn add fetch-action-creator!

fetch-action-creator 🐶🎾

Be sure to understand the difference between an action and an action creator. The fetch-action-creator package does not return an action creator. It is an action creator, so it returns an asynchronous action, meaning it returns the (dispatch, getState) => {} function.

Your action creator will look something like this:

import fetchActionCreator from 'fetch-action-creator';

export const fetchMyApi = () =>
  fetchActionCreator(
    'MY_API',
    'https://path.to/api',
    null // fetch options, if any
  );

The 'MY_API' string is used to generate the Redux action types: 'REQUEST_MY_API', 'RESOLVE_MY_API', 'REJECT_MY_API', and 'ABORT_MY_API'.

Your React components will only bind and call the fetchMyApi action creator, which notably has no parameters in this example.

You can use parameters to customize your fetch actions. It’s a little more work to extend your actions inline, but the payoff in extensibility is huge.

import fetchActionCreator from 'fetch-action-creator';

// We now call fetchAddEmployee("Bob")
const fetchAddEmployee = name =>
  fetchActionCreator(
    'ADD_EMPLOYEE',
    'https://path.to/employees',

    // POST Bob
    {
      body: name,
      method: 'POST'
    },

    // For each action, merge with object { name }
    //   to add a name property containing
    //   employee's name to the action object.
    {
      onAbort: { name },
      onReject: { name },
      onRequest: { name },
      onResolve: { name }
    }
  );

You can check out the documentation for advanced options on mutating the Redux actions.

The fetch-action-creator package is open-source on GitHub. Pull requests are welcome!

Conclusion 🔚

If you liked this article, feel free to give it a heart or unicorn. It’s quick, it’s easy, and it’s free! If you have any questions or relevant commentary, please leave them in the comments below.

To read more of my columns, you may follow me on LinkedIn, Medium, and Twitter, or check out my portfolio on CharlesStover.com.

Fixing React Native WebView’s postMessage for iOS

Charles Stover — Tue, 04 Jun 2019 20:00:32 +0000

In 2016, GitHub user Robert Roskam (raiderrobert) opened an issue on the React Native repository reporting the error “Setting onMessage on a WebView overrides existing values of window.postMessage, but a previous value was defined”. In the two years since then, nothing has been done to resolve it within the internal React Native implementation of WebView.

The React Native community has forked WebView specifically to maintain it as a third party package and fix many of these ongoing issues. However, in order to implement these third party packages, you must be able to link React Native packages — react-native link react-native-webview. If you are able and willing to do this, your problem is solved. The installation instructions for the community edition of WebView are as simple as:

yarn add https://github.com/react-native-community/react-native-webview
react-native link react-native-webview

Note: In order to react-native link ..., you must first yarn global add react-native.

Unfortunately, if you are unable or unwilling to do this, there has simply been no solution to this problem. For years!

Users of Expo, for example, would have to eject their project and write their own native, non-JavaScript implementation of features. Expo will, theoretically, be using these community edition packages in future releases; but with a launch window only weeks away, my team and myself were not willing to wait.

The Solution 💡

If you care more about getting this solved right now than how it works, this section is for you.

Either npm install rn-webview or yarn add rn-webview to add the rn-webview package to your project.

Wherever you are using import { WebView } from 'react-native', simply replace it with import WebView from 'rn-webview'. Then just use the new WebView component as you would the React Native internal implementation, including the use of the onMessage prop. The rn-webview package is just a wrapper for the internal React Native implementation that intercepts messages through a different channel than the internal onMessage prop, but handles it with its own onMessage prop, giving the illusion that you are actually using the internal onMessage with expected results.

Caveats 🤕

The rn-webview package works by directing window.postMessage traffic to history.pushState instead. While React Native’s iOS implementation cannot handle window.postMessage correctly, it can handle navigation state changes. Because of this, the navigation state change event is the channel through which messages are transferred between the WebView and the native application.

If manipulation of the history state is an important aspect of your application, this solution may not suit your needs. Feel free to fork the project on GitHub to offer alternative solutions.

The Implementation 🔨

Export 🚢

First and foremost, the ref prop of WebView is a particularly important one. Because of this, we don’t want the user to lose access to it. We start the package with a forwardRef implementation, where WebViewPostMessage is the class name used for this package.

export default React.forwardRef((props, ref) =>
  <WebViewPostMessage
    {...props}
    forwardedRef={ref}
  />
);

Render 🎨

The output of this component is going to be the React Native internal implementation of WebView, with a few tweaks. We aren’t going to give it the forwardedRef prop, because that is only used to give the parent access to the ref and is totally meaningless to the internal WebView. Most importantly, we aren’t going to give it the onMessage prop, because that is the source of all of our problems — it’s not supported by iOS!

render() {
  const props = {...this.props};
  delete props.forwardedRef;
  delete props.onMessage;

  return (
    <WebView
      {...this.props}
      onNavigationStateChange={this.handleNavigationStateChange}
      ref={this.handleRef}
    />
  );
}

We have a custom navigation state change listener, because that is the channel through which we will be listening for messages.

We have a custom ref handler, because we both 1) need access to it inside this component and 2) need to pass the ref back to the parent container via the forwardedRef prop.

Ref 👋

When the internal WebView gives us its ref, we store it on the instance (this.ref = ref) for use later. If the parent requested the ref as well, we forward it.

handleRef = ref => {
  this.ref = ref;

  // If the caller also wants this ref, pass it along to them as well.
  if (this.props.forwardedRef) {
    this.props.forwardedRef(ref);
  }
};

Inject window.postMessage 💉

Now, a custom implementation of window.postMessage needs to exist on any page in the WebView. Whenever the navigation state changes, if it has finished loading, we inject JavaScript into it to override what window.postMessage does.

handleNavigationStateChange = e => {

  /* We'll do something here later. */

  // If this navigation state change has completed, listen for messages.
  if (
    !e.loading &&
    this.ref
  ) {
    this.ref.injectJavaScript(injectPostMessage);
  }

  /* We'll do something here later. */
};

I defined and importedinjectPostMessage from a different file for readability.

export default `
(function() {
  var EMPTY_STATE = Object.create(null);
  var escape = function(str) {
    return str.replace(/'/g, '\\\\\'');
  };
  var postMessage = window.postMessage;
  window.postMessage = function() {
    if (postMessage) {
      postMessage.apply(window, arguments);
    }
    history.pushState(
      EMPTY_STATE,
      document.title,
      location.href +
      '#window.postMessage(\\\'' +
      escape(arguments[0]) +
      '\\\')'
    );
  };
})();
`;

It is an immediately-invoked function expression to make sure none of our variables conflict with the web page.

The EMPTY_STATE is what is pushed to history, since we won’t be using a state object for our event listener.

The escape function escapes apostrophes in a string so that we can place that string in apostrophes. Since the navigation state that we push is not real JavaScript and won’t be passed through any sort of JavaScript interpreter, this step is not exactly necessary. It just allows the state we push to more closely mimic real JavaScript.

The postMessage variable checks to see if a postMessage function already exists. If so, we’ll want to execute it also during any window.postMessage calls.

We define our own window.postMessage function. The first thing it does is executes the previous window.postMessage function, if it existed.

Next, we push to the history state. We have no state object, so we use the aforementioned empty one. The title of the document is not changing, so we just use the current one. The location of the document is also not changing per se: we are merely appending a hash.

That hash, which we’ll be listening for later, is window.postMessage('the message'). It looks like JavaScript, by design, but is not going to be evaluated by any real JavaScript interpreter. We just need a unique hash that won’t collide with real, in-document hashes.

postMessage Listener 📬

Now that we have our own window.postMessage event emitter, we need to listen for it. This is the code that goes at the top of the handleNavigationStateChange method.

const postMessage = e.url.match(/\#window\.postMessage\('(.+)'\)$/);
if (postMessage) {
  if (
    e.loading &&
    this.props.onMessage
  ) {
    this.props.onMessage({
      nativeEvent: {
        data: unescape(postMessage[1])
      }
    });
  }
  return;
}

We check if the new URL matches the postMessage hash we defined earlier. If it does, we’re going to return so that the rest of the navigation state change event listener doesn’t fire. This is a message event, not a navigation state change (technicalities aside).

Each postMessage event will fire the navigation state change twice — once for loading: true and one, almost immediately after, for loading: false. We are only listening for the loading: true event, because it occurs first. The loading: false event is ignored, because it is just a duplicate.

Only if the parent component passed an onMessage event handler, we call that handler with a mock event that contains the message. We unescape the message before passing it, because we escaped the apostrophes earlier.

The unescape function is defined at the top of the document, because it is constant (does not depend on the instance) and does not need to be a method of the component. You may import it if you prefer to code split it.

const unescape = str =>
  str.replace(/\\'/g, '\'');

onNavigationStateChange 🕵

The above covers everything we need for intercepting window.postMessage and handling it with one’s own onMessage event listener. Our original problem is already solved — onMessage works with this WebView. However, since we have overwritten the internal onNavigationStateChange listener, the parent is no longer receiving navigation state change events.

At the bottom of the handleNavigationStateChange event listener, add the following:

if (this.props.onNavigationStateChange) {
  return this.props.onNavigationStateChange(e);
}
return;

If the parent has included an onNavigationStateChange prop, call it, and give it this navigation state change event.

The empty return is simply personal preference — I don’t believe functions should conditionally return, even if it’s functionally equivalent to an implicit return.

Conclusion 🔚

As a reminder, you can include the component just outlined by installing the rn-webview package from NPM. You may also fork it on GitHub.

If you liked this article, feel free to give it a heart or unicorn. It’s quick, it’s easy, and it’s free! If you have any relevant commentary, please leave it in the comments below.

To read more of my columns, you may follow me on LinkedIn, Medium, and Twitter, or check out my portfolio on CharlesStover.com.

Are you underqualified to apply to a software development position?

Charles Stover — Sun, 02 Jun 2019 22:12:25 +0000

Reddit user orduk asked, “How under qualified were you when you applied for your current position?”

There are a lot of misconceptions about what constitutes as “qualified.” Job postings are notorious for having laughable minimum requirements: more years of experience using a language than it has existed, senior level requirements for junior positions, or years of experience expected of fresh college graduates. It’s no surprise than many juniors feel the “you need experience to get experience” barrier is all too real.

I wanted to make one thing clear:

You should always be under qualified. 🎯

The top comment, by user vidro3, to orduk’s question is a great reflection of the developer experience: “Bold assumption that I’m now qualified for my current position.”

Your job pays you twice — once with money, and once with knowledge. This does not only apply to juniors; it applies to seniors as well. If you are only getting paid one of these ways, you are underpaid. If you are not growing at your job, you are being held back from advancing your career. By definition, then, you must be “under qualified” or else be stagnant in your personal growth.

This changes the perception of qualified. If you expect to grow at your job, and your company expects you to grow at your job, then you cannot have perfected or know all aspects of your job. You must be hired at a level where you can grow: you must be under qualified. This really just means that under qualified is the qualification level.

Red Flags 🚩

Good tech companies will hire “under qualified” individuals because that individual has potential for growth. It is a red flag when a tech company wants an overqualified individual. They don’t want the individual to learn anything new or better themselves. “This is the level you are hired at, and this is all you will ever be. Don’t expect a raise or a promotion, because your job is not going to change, and your performance will never improve.”

You should always be underqualified for any job to which you apply. The biggest sell of a candidate is not their encyclopedic knowledge, but their eagerness and ability to learn what they don’t know. If an employer invests in you as a junior, they hope to eventually have a senior with company loyalty.

Underqualified is Qualified 💼

Do not ever treat a “minimum requirements” as a wall. Apply anyway, if only for the interview experience. I’ve been a web developer for 17 years now, and I still rarely meet all the minimum requirements.

To answer orduk’s question, I am currently a front end engineer for the largest cloud service provider in the world. Outside of OneDrive for personal file storage, I had never used a cloud service a day in my life. I had not even used services that would have aided my development career; I always hosted my applications myself. I had no experience with serverless. I had not studied system design until two weeks before my interview — because they told me to study it for my interview. I did not know how most cloud services worked, but I am learning on the job, and the knowledge I am gaining, in addition to my paycheck, is that additional compensation that will allow me to grow as a person, as a developer, and in my career.

It’s about selling yourself. 💸

Being a self-taught front end engineer, not having a degree was one of my biggest hurdles. It took a long time for me to learn how to sell myself. I knew a great deal, I had great learning potential, but I didn’t have the confidence or soft skills to know how to convey that potential in an interview. I read “college degree” on minimum requirements and gave up. If only I knew then what I know now, I would be so much further in my career! Going to interviews for the sake of learning how to interview was one of the best things I could have done. Even when I was rejected, I learned what was in demand from those interviews, and I learned those things. Then, they stopped caring about my degree and started caring that I was A) passionate, B) eager to learn, and C) dove deep into material for a below-surface-level understanding.

Minimum requirements are not minimum requirements. Underqualified is expected. Soft skills are the greatest asset, not a degree or encyclopedic knowledge. You need experience to get experience is true, but knowing how to sell your self-taught or practice experiences as real experience is the confidence that can come from practice interviewing.

Confidence Speaks Volumes 🧠

As an example, a not-so-confident statement would be, “I published some of my JavaScript to NPM.” The interviewer knows that you know JavaScript and NPM. That’s okay.

A confident way of saying the same thing would be, “I designed a reusable component that was extensible to all customer use cases. With GitHub Issues, I engaged customers to meet their needs, prioritized features, and maintain my service to them.” The interviewer knows that you can communicate technical ideas to users who are not on the same level of expertise, can design code that works across teams, can account for edge cases, can prioritize features, and can offer long-term support and maintenance. 👌

I am talking about the same code in both cases. Both statements come from the same level of qualification. One is selling myself and the other is selling myself short. Practice interviews worked wonders for me. I was able to learn what companies wanted (“Discuss a time you had a conflict with a superior and how you resolved it.”), practiced talking about my skills at home without the pressure or anxiety, then interviewed again with confidence. Rinse and repeat.

Interviewing is Win-Win 🏆

Interviewing is not a test where you fail for not getting hired. If you do not get hired, you still learned something. You should be using the company when you interview. Determine what is important to them. You should leave the interview more knowledgeable than you entered. You are a better developer after failing an interview because you know something you didn’t know the day before — you know some in demand tech stacks, you know some soft skills that are higher priority, and hopefully you will know what steps to take next to acquire any skills you are lacking.

Keep at it and see the opportunity in every obstacle.

Conclusion 🔚

If you liked this article, feel free to give it a heart or a unicorn. It’s quick, it’s easy, and it’s free! If you have any questions or great commentary, please leave them in the comments below.

To read more of my columns, you may follow me on LinkedIn, Medium, and Twitter, or check out my portfolio on CharlesStover.com.

Cache your React event listeners to improve performance.

Charles Stover — Sun, 02 Jun 2019 20:41:40 +0000

An under-appreciated concept in JavaScript is how objects and functions are references, and that directly impacts React performance. If you were to create two functions that are completely identical, they are still not equal. Try for yourself:

const functionOne = function() { alert('Hello world!'); };
const functionTwo = function() { alert('Hello world!'); };
functionOne === functionTwo; // false

But check out the difference if you assign a variable to an already-existing function:

const functionThree = function() { alert('Hello world!'); };
const functionFour = functionThree;
functionThree === functionFour; // true

Objects work the same way.

const object1 = {};
const object2 = {};
const object3 = object1;
object1 === object2; // false
object1 === object3; // true

If you have experience in other languages, you may be familiar with pointers. What is happening here is that each time you create an object, you are allocating some amount of memory on the device. When I said that object1 = {}, I have created a chunk of bytes in the user’s RAM that is dedicated specifically to object1. It is fair to imagine object1 as an address that contains where in RAM its key-value pairs are located. When I said object2 = {}, I created a different chunk of bytes in the user’s RAM that is dedicated specifically to object2. Does the address of object1 match the address of object2? No. That is why the equality check for the two variables does not pass. Their key-value pairs may be exactly the same, but their addresses in memory are different, and that is what is being compared.

When I assigned object3 = object1, I am assigning the value of object3 to be the address of object1. It is not a new object. It is that same location in memory. You can verify this like so:

const object1 = { x: true };
const object3 = object1;
object3.x = false;
object1.x; // false

In this example, I created an object in memory and assigned it to object1. I then assigned object3 to that same address in memory. By mutating object3, I have changed the value at that location in memory, meaning all other references to that location in memory change as well. object1, which still points to that location in memory, now has a changed value.

This is a very common error for junior developers to make, and likely warrants an in-depth tutorial of its own; but this particular tutorial is about React performance, which may be compromised even by developers with more seniority who have simply not considered the implications of variable references.

What does this have to do with React? React has an intelligent way of saving processing time to boost performance: If a PureComponent’s props and state have not changed, then the output of render must not have changed either. Clearly, if all things are equal, nothing has changed. If nothing has changed, render must return the same output, so let’s not bother executing it. This is what makes React fast. It only renders as needed.

React determines if its props and state are equal the same way JavaScript does — by simply comparing them with the == operator. React does not shallow or deep compare objects to determine if they are equal. Shallow comparison is a term used to describe comparing each key-value pair of an object, as opposed to comparing the memory address. Deep comparison is going one step further and, if any of the values in the key-value pair are also objects, comparing those key-value pairs as well, ad nauseum. React does neither: it merely checks if the references are the same.

If you were to change a component’s prop from { x: 1 } to another object { x: 1 }, React will re-render, because those two objects do not reference the same location in memory. If you were to change a component’s prop from object1 (from above) to object3, React would not re-render, because those two objects are the same reference.

In JavaScript, functions are handled the same way. If React receives an identical function with a different memory address, it will re-render. If React receives the same function reference, it will not.

This is an unfortunately common scenario I come across during code review:

class SomeComponent extends React.PureComponent {

  get instructions() {
    if (this.props.do) {
      return 'Click the button: ';
    }
    return 'Do NOT click the button: ';
  }

  render() {
    return (
      <div>
        {this.instructions}
        <Button onClick={() => alert('!')} />
      </div>
    );
  }
}

This is a pretty straightforward component. There’s a button, and when it is clicked, it alerts. Instructions tell you whether or not you should click it, which is controlled by the do={true} or do={false} prop of SomeComponent.

What happens here is that every time SomeComponent is re-rendered (such as do toggling from true to false), Button is re-rendered too! The onClick handler, despite being exactly the same, is being created every render call. Each render, a new function is created (because it is created in the render function) in memory, a new reference to a new address in memory is passed to <Button />, and the Button component is re-rendered, despite absolutely nothing having changed in its output.

The Fix

If your function does not depend on your component (no this contexts), you can define it outside of the component. All instances of your component will use the same function reference, since the function is identical in all cases.

const createAlertBox = () => alert('!');

class SomeComponent extends React.PureComponent {

  get instructions() {
    if (this.props.do) {
      return 'Click the button: ';
    }
    return 'Do NOT click the button: ';
  }

  render() {
    return (
      <div>
        {this.instructions}
        <Button onClick={createAlertBox} />
      </div>
    );
  }
}

In contrast to the previous example, createAlertBox remains the same reference to the same location in memory during every render. Button therefore never has to re-render.

While Button is likely a small, quick-to-render component, you may see these inline definitions on large, complex, slow-to-render components, and it can really bog down your React application. It is good practice to simply never define these functions inside the render method.

If your function does depend on your component such that you cannot define it outside the component, you can pass a method of your component as the event handler:

class SomeComponent extends React.PureComponent {

  createAlertBox = () => {
    alert(this.props.message);
  };

  get instructions() {
    if (this.props.do) {
      return 'Click the button: ';
    }
    return 'Do NOT click the button: ';
  }

  render() {
    return (
      <div>
        {this.instructions}
        <Button onClick={this.createAlertBox} />
      </div>
    );
  }
}

In this case, each instance of SomeComponent has a different alert box. The click event listener for Button needs to be unique to SomeComponent. By passing the createAlertBox method, it does not matter if SomeComponent re-renders. It doesn’t even matter if the message prop changes! The address in memory of createAlertBox does not change, meaning Button does not have to re-render, and you save processing time and improve rendering speed of your application.

But what if my functions are dynamic?

The Fix (Advanced)

Author’s Note: I wrote the following examples off the top of my head as a way to repeatedly reference the same function in memory. These examples are meant to make comprehension of references easy. While I would recommend reading this section for the purpose of comprehending references, I have included a better implementation at the end that was generously contributed by Chris Ryan via comment. His solution takes into account cache invalidation and React’s built-in memory management.

There is a very common use case that you have a lot of unique, dynamic event listeners in a single component, such as when mapping an array.

class SomeComponent extends React.PureComponent {
  render() {
    return (
      <ul>
        {this.props.list.map(listItem =>
          <li key={listItem.text}>
            <Button onClick={() => alert(listItem.text)} />
          </li>
        )}
      </ul>
    );
  }
}

In this case, you have a variable number of buttons, making a variable number of event listeners, each with a unique function that you cannot possibly know what is when creating your SomeComponent. How can you possible solve this conundrum?

Enter memoization, or what may be easier to refer to as simply, caching. For each unique value, create and cache a function; for all future references to that unique value, return the previously cached function.

This is how I would implement the above example.

class SomeComponent extends React.PureComponent {

  // Each instance of SomeComponent has a cache of click handlers
  // that are unique to it.
  clickHandlers = {};

  // Generate and/or return a click handler,
  // given a unique identifier.
  getClickHandler(key) {

    // If no click handler exists for this unique identifier, create one.
    if (!Object.prototype.hasOwnProperty.call(this.clickHandlers, key)) {
      this.clickHandlers[key] = () => alert(key);
    }
    return this.clickHandlers[key];
  }

  render() {
    return (
      <ul>
        {this.props.list.map(listItem =>
          <li key={listItem.text}>
            <Button onClick={this.getClickHandler(listItem.text)} />
          </li>
        )}
      </ul>
    );
  }
}

Each item in the array is passed through the getClickHandler method. Said method will, the first time it is called with a value, create a function unique to that value, then return it. All future calls to that method with that value will not create a new function; instead, it will return the reference to the previously created function in memory.

As a result, re-rendering SomeComponent will not cause Button to re-render. Similarly, adding items to the list prop will create event listeners for each button dynamically.

You may need to use your own cleverness for generating unique identifiers for each handler when they are determined by more than one variable, but it is not much harder than simply generating a unique key prop for each JSX object in the mapped result.

A word of warning for using the index as the identifier: You may get the wrong result if the list changes order or removes items. When your array changes from [ 'soda', 'pizza' ] to just [ 'pizza' ] and you have cached your event listener as listeners[0] = () => alert('soda'), you will find that when you users click the now-index-0 button for pizza that it alerts soda. This is the same reason React advises against using array indices for key props.

A Better Implementation

Courtesy of Medium user Chris Ryan.

Conclusion

To read more of my columns, you may follow me on LinkedIn, Medium, and Twitter, or check out my portfolio on CharlesStover.com.