DEV Community: Justin Mitchell

The keys to interview success - landing that dream job

Justin Mitchell — Thu, 04 Mar 2021 03:46:49 +0000

Mastering the interview technique is one of the most important things you need to do, to land not just your dream job, but any job. In today's IT industry, technical skills are often less important than interpersonal skills. The ability to work in a team, enhance culture, become a leader and contribute to engineering improvements are highly regarded skills. You will noticed though, that there's a combination of hard skills and soft skills in that statement.

Let's address the elephant in the room - interviews are daunting, nerve wracking experiences. They frequently don't reflect the abilities or skills of the applications and nerves often get the better of people, applicants and interviewers alike. In my time in IT, I've either conducted or been an applicant in dozens of interviews, and I have what I believe is a fantastic recipe for success, and will certainly help you land that dream job.

1. Dress for success, but let's not get stuffy about it!

Yes, the great statement of dress for success and you'll land that role. Let's face it though, IT is one of the most casual work environments you're ever likely to see. I've seen people work in crocs, shorts and tees, and as bizarre as the look was, management didn't say a thing. There are times when dress codes are mandated, and you should dress accordingly, but the best way to know about dress code is to ask.

Don't be afraid to ask what the code should be, and there's not a lot more uncomfortable for everyone involved, when the interviewers are dressed in jeans, sneakers and a tee, and the applicant is wearing a 3-piece suit with mirror-shine shoes. Jeans and a shirt used to be taboo; it's still not widely accepted for interviews, but don't have to overdo it.

2. Your resume must make a statement

There are a lot of resume templates on the internet, a lot of advice, and the constant advocacy of cover letters. The cold hard truth is that recruiters and companies can see dozens, if not hundreds of resumes by the time the interviews are set. A simple, direct, no frills and no-nonsense resume will put you at the top of the pile. The 80's, 90's and 2000's are long gone - don't get crazy and creative in Word, it's not required anymore.

Cover letters? Don't bother. Recruiters often demand them, and if they do, just copy the career overview from your resume. I haven't seen a single cover letter, nor would I read it.

You still need to tailor your resume for the type of role and even the type of company you're applying for, and you should emphasize the qualities, skills and qualifications that any employer is looking for. Most importantly though, you should always put more focus into soft skills over hard skills, and you shouldn't exaggerate on your resume. A little embellishment is expected, but don't outright lie. Any interviewer worth their salt will pick it out straight away because it doesn't line up, or will have an interview strategy to really focus on those points. A senior engineer or tech lead will have a plan ahead of the resume, based on experience and technical background, and will have very specific questions and problems for the interviewee to think and explain their way through.

I have created an example resume that you can use as a base and a reference.

3. Soft skills are more important than technical skills

Culture in the workplace is vital. It's one of the intangibles that drive success. Highly successful companies will hire people that are far better cultural fits than they are technical fits. There will of course be times when the technical fit just outweighs the cultural fit, but this is becoming far less common than it used to be, as workplace laws and expectations evolve.

Companies have identities, which are intrinsically tied to their culture. Success begets culture, and culture drives success, it's a symbiotic relationship of mutual reward. Personalities are assessed from multiple factors:

Language used and structure of resume
History of conflict resolution
Motivation, empowerment and teamwork
Exposure to, and experience with team based methodologies.

While it's not entirely fair for a lot of applicants, you need to remember that a lot of judgement is made based on technical match, and even some cultural considerations, when the final interview list is finalised.

4. Open source is great, but not it's not the silver bullet

Open source software is great, and ongoing contributions to, or even maintaining an OS tool/library is fantastic, but it often doesn't line up with the expectations of organisations, or even the company you're applying for. Technology companies have become far more flexible in their working environments and arrangements in the last 5 years, but this still doesn't guarantee success.

Why? There have been a number of OSS contributors that I've worked with who were not team players. By no means does it mean that everyone that works on OSS is like that, far from it, but someone that spends a significant amount of time working on projects, especially popular ones, are more likely to form less desirable soft skills, that don't suit or work with corporate life.

There are companies that have a very strong open-source software focus, that provide paid time for their employees to contribute to, and lead their own OSS projects. It's a great environment for technology entrepreneurs to work in, especially with like minded people who're similarly focused on achieving their goals and improving the standards of tools.

It's a coin that flips both ways - an applicant should never be ruled out for their OSS contributions, but OSS contributions shouldn't be used purely as a resume.

5. Practice and train your brain, so that it's not a drain

Practice makes perfect. It takes roughly 10 thousand hours of practice before achieving mastery over your given field. After a couple hundred hours of React, you'll be able to make an decent app. Several thousand, you can improve and design your code. 10 thousand? Jedi level React developer. Even for the best of us, that's 4-5 years of 50-hour weeks developing React.

Even for the best of us out there, practice is important. Reassess the fundamentals, know the core parts of the technology you're interviewing for. Working with AWS? Go through all the tools you say you know, and re-do activities, and even re-read previously completed training on Udemy.

A common question I have for React developers is to ask where and why you would use Class Components or Functional Components, and why you would use a Class component instead. Asking specific questions about a library, technology or tool is a very quick and efficient way to understand a developer knowledge.

6. It's OK to say you don't remember, don't know, or don't have experience with

Let's face it, we've all been there. 20 minutes into the interview, 10 minutes of introductions, your 5-10 minute sales pitch about history and why you value this company is done, and then you're nailed with a corker, let's say it's JavaScript hoisting. You know what it is and how it works. You've educated your peers, even wrote a blog about it, but in that time your mind goes blank.

Two things will happen - an applicant will either freeze up on the spot and finally blurt out an answer, or go on a long winded speech where the word hoisting will be used a dozen times until their memory frees up.

There are other responses you can provide. Don't be afraid to ask to come back to that question, state that at this particular time you don't remember, or you simply don't know. When there's a long, rambling answer, interviewers can deduct two things very quickly - you either don't know and you're afraid to say so, which means you might not ask for help in your job, or you'll just talk until everyone forgets.

A lot of this comes down to nerves and as an interviewer, it's our job to put you on the edge, but only briefly before bringing you back, definitely not shoving you way over the edge. I've been there before, it's not pleasant - no, it's downright awful.

In cases where you might lack experience or exposure, don't lie, just be honest. If you're asked about React Hooks and you haven't used them, just say it. If your application is rejected based on that, trust me you're better off.

7. Don't lie on the resume

Is a little white lie ok? Well, that depends on what you define a little white lie! If a little white lie means you add a month or two to your experience in a company because you left after 6 weeks, sure, that's normally ok. No one is really going to care enough to fact check that.

How about a little white lie about experience and knowledge? This is dangerous ground. If you lie your way into a job and you're found out, a frog march awaits. People will know, they will find out and all trust will be eroded instantly. Once trust is gone, expect your tenure to be extremely short, measured in hours.

Conclusion

Interviews can be a tough, challenging experience, but armed with the right tools, and prepared for success, you can get that job. Some of the traditional advice, rooted in 1980s corporate world doesn't exist anymore. Dress in a suit, wear a tie, be confident, show you can lead, etc. is advice that's awfully specific to either certain industries, or specific roles.

Companies want people that fit right in, with a minimum of fuss, muss and friction. They're likely to pay more for people that culturally fit in the company and enhance their reputation as a respected and choice employer, than people that are technically strong but don't work well in a team environment.

That's not to say that chances won't be given - they can and will be, especially for technically gifted applicants. Just don't burn the bridge when you get it.

Less is more; simplify your React code to super power your applications - part 3

Justin Mitchell — Wed, 03 Mar 2021 07:10:53 +0000

This is the third article in a series covering different strategies to simplify your React applications.

Simplify a React component

There's a number of strategies that we can take to simplify our components, without drastically overhauling our code. Each strategy will be covered in a different post.

Separate state from display, this will help your application align with well established MVC rules
Defer processing to services and custom hooks
Avoid overloading useEffect and useState
Determine if redux & redux-saga are really needed
Create higher order components to join functionality between components
Shift computational logic out of components into helper functions, inject with custom hooks
Use lazy loading and lazy behaviour where possible

Avoid overloading `useEffect` and `useState`

useEffect and useState are powerful tools in the React functional arsenal. The useState hook supports binding persistent state to a component through multiple renders, while useEffect is similar to the componentDidMount and componentDidUpdate lifecycle methods of React class components, except that the function will execute once the render has been committed to the screen.

The `useState` hook, how and when to use it

The useState hook provides support for setting stateful data on a component, and when a new value is set, equates to a re-render of the component. This is especially valuable for components that need to maintain localised state, specific to the component, or to be passed to children components as a prop.

One particular usage of useState is to set transitional states for a component, that could be driven by the fetching and rendering of asynchronous data. When loading data, we should be presenting a temporary state to the user, and transitioning from that previously rendered state to the new state.

We can also capture user input within the component, and trigger re-renders of the component and not the parent, by avoiding prop drilling and using local state:

// Example from React
function Counter({initialCount}) {
  const [count, setCount] = useState(initialCount);
  return (
    <>
      Count: {count}
      <button onClick={() => setCount(initialCount)}>Reset</button>
      <button onClick={() => setCount(prevCount => prevCount - 1)}>-</button>
      <button onClick={() => setCount(prevCount => prevCount + 1)}>+</button>
    </>
  );
}

React's unidirectional update of changes means that we can avoid issues where prop changes are communicated from child to parent, like it was possible in earlier versions of AngularJS. While it's a good thing, maintaining state across multiple components in the same parent component, especially where transitional data and error messaging is relevant, can be a tricky situation.

One such example is the fetching of data from an API, the transformation of that data, and the handling of various error scenarios. Depending on the way that error handling is presented, especially when using static pages and static routes, it may not be possible to customise the data that's presented to the user.

const [loaded, setLoaded] = useState(false);
const [hasTransformError, setHasTransformError] = useState(false);
const [hasApiFetchError, setHasApiFetchError] = useState(false);
const [hasSomeOtherError, setHasSomeOtherError] = useState(false);

useEffect(async () => {
  try {
    const response = await fetch("/some/api");
    const json = await response.json();
    const transformed = transformer.transformJson(json);
  } catch (e) {
    if (e instanceof TransformerError) {
      setHasTransformError(true);
    } else if (e instanceof ApiError) {
      setHasApiFetchError(true);
    } else {
      setHasSomeOtherError(true);
    }
  }
});

if (hasTransformerError || hasApiFetchError || hasSomeOtherError)
  // Possibly render error to screen, or redirect to hard fail/static error screens

While the above pattern is an example, it's not a graceful nor elegant way of handling error scenarios, but for specific circumstances, such as the fetching data from one api endpoint on page load, fetching data from another api endpoint to verify, and posting data to another endpoint, the methods of handling various error scenarios can be limited when using React components.

Setting useState with initial data from callable function

You can initialise an instance of the useState hook with an object or primitive data, or a callable function that is executed by React, and the value is returned as the default value. This can be useful in circumstances where an initial value may need to be calculated from a data store, and it's cleaner than prop drilling.

It's worth keeping mind, that any value derived from a computationally intensive function, provided as the default callable to useState will block the UI from rendering, and this is why it's always advised to rely on useEffect to provide lazy loading of data. Unlike a callable function, useEffect will not block the UI after render.

Lazy loading state with `useEffect`

useEffect when combined with useState is a powerful asynchronous tool for loading, mutating and displaying data provided by an API. It's a very common strategy employed in many React applications, and is one of the common reasons for creating custom hooks.

With our previous example, we create a component called Todos, which fetches and displays content from the json placeholder API. This component is responsible for quite a lot - fetching data from an API, transformation, reconciling state and rendering the UI.

const Todos = () => {
  const [todos, setTodos] = useState();
  useEffect(async () => {
    const response = await fetch('https://jsonplaceholder.typicode.com/todos/');
    const todos = await response.json();
    setTodos(todos);
  }, []);

  // Render the content of the screen
}

We can shift a lot of the processing and state handling to a custom hook, and expose the values returned by the custom hook, such as todos:

const useTodos = () => {
  const [todos, setTodos] = React.useState([]);
  React.useEffect(async () => {
    const response = await fetch('https://jsonplaceholder.typicode.com/todos/');
    const todos = await response.json();
    setTimeout(() => {
      setTodos(todos);
    }, 2500);
  }, []);

  return { todos };
}

const Todos: React.FC = () => {
  const { todos } = useTodos();
  return todos.length > 0 ? <p>Hello, world! {todos.length} todos!</p> : <Spinner/>
}

Observable updates with `useState` and `useEffect`

useEffect can be initialised with an observable array of properties, causing the useEffect to be executed each time one of the properties is changed. This is especially useful when listening to UI events across the page, and rendering components as the user interacts with various elements on the screen.

A very common use case is pagination. Given a user interacts with a button, we want to show another set of records as we traverse the data set.

When we run thee codepen, we see three things:

We've used a custom hook useTodos to encapsulate our API fetching, data transformation and temporary caching of Todos
A useEffect hook call binds to page
We export two derived values and setPage

By exporting setPage, we can very easily trigger UI updates and additional data fetching by setting a new value with setPage:

const TodosPaginate = () => {
  const {todos, page, setPage} = useTodos();
  return (
    <div>
      <p>Page: {page}</p>
      { page > 1 ? <button onClick={() => setPage(page-1)}>Prev ({page-1})</button> : null }
      { page < 10 ? <button onClick={() => setPage(page+1)}>Next ({page+1})</button> : null }
    </div>
  );
}

Custom hooks

Custom hooks are great ways to encapsulate behaviour. The code can be trivial, or quite complex and intensive, but importantly it's encapsulated and removed away from the view layer of our components. This is a common design trait with MVC applications, in this case we're treating our custom hooks as models, defining logic and behaviours that directly affect the view. That model can also respond to user inputs, through exposed helper functions or setState calls.

It's important to remember though, that custom hooks should not maintain state that can be consumed across multiple components. This is so that the application behaves in a predictable and reliable fashion, and that hooks aren't abused and used in ways that they were never designed to.

In our example above, we've exposed the todos list, the page number and setPage, which will trigger the asynchronous loading and re-render of the page. In our codepen example, we've also attempted to load the same custom hook useTodos into both the Todos and TodosPaginate component.

const Todos = () => {
  const {todos, page} = useTodos();
  // ...
}

const TodosPaginate = () => {
  const {todos, page, setPage} = useTodos();
  // ...
}

An expected behaviour here might be to have the same hooks shared across multiple components. That would be handy and great, wouldn't it? But alas, the real behaviour here is that the hooks are merged with the component that's calling them. Given n number of components using useTodos, there will be n number of bindings of the same useState and useEffect calls. It's trivial to test this - add console.log or view the network tab in your console to try it out yourself.

The proper React way to expose data for use across multiple components and custom hooks is to use the Context API.

Context API

The context api provides a way to pass data through the React component tree without resorting to prop drilling. You can implement it as much as or little as you like, and you can implement it in specific locations.

The data contained in the Context API is considered to be global data, and can be used throughout your application. Data that is considered priviledged, such as authenticated user information, or a secure cookie perhaps, should not be stored in a context. The Context API is great for use with theme overrides, specific localised behaviour such as pagination, or controlling page layout.

We can take our simple Todos app and make it more responsive to page navigation, by declaring a Todos Context and providing it to our components. There is one caveat - a context will only publish changes when the source data changes. This ensures unidirectional communication and propagation. We can define a handler to update the state for us, and provide it through the context Provider.

It's worth noting that it's not required to provide a context Consumer in functional components, because we can use a custom hook instead. A Consumer and custom hook behave similarly - an object is provided and will listen to propagated updates. With the custom hook you can expose data from the useContext, while the Consumer requires a function to render something to screen with the variables provided by the context.

<TodosContext.Consumer>
  {todos => /* render something based on the context value */}
</TodosContext.Consumer>

// Behaves similarly to:
const useTodosContext = () => {
  return { page, todos } = React.useContext(TodosContext);
}

When to consume `useEffect` and when to consume `useLayoutEffect`

The useEffect hook is a powerful feature of React that allows functional components to behave in an asynchronous way. If you're not careful, there are traps that you need to avoid that are made as clear as they could possibly be. It is very easy to trigger multiple executions of a useEffect hook if you're not careful, and before you know it, your application will be grinding your browser to a halt.

It's not always necessary to execute useEffect after each re-render, and there are ways to mitigate against this, using useState, useRef, or observing values that don't change. The best way to apply these methods is to use a custom hook, but each of these strategies still execute useEffect multiple times.

// Using `useState` to maintain execution state for hook
const useCustomHook = (fn) => {
  const [state, setState] = useState({completed: false});
  useEffect(() => {
    // Only execute if state.completed has not been set yet
    if (!state.completed) {
      fn && fn();
      setState({...state, completed: true});
    }
  }, [state.completed]);
}

// Using `useRef` to maintain execution state for hook
const useCustomHook = (fn) => {
  const ref = useRef(false);
  useEffect(() => {
    // Only execute if ref.current is true
    if (!!ref.current) {
      fn && fn(); 
    } else {
      ref.current = true;
    }
  }, [ref.current]);
}

// Only execute this hook once, ever, but this _will_ throw an exhaustive deps warning with eslint!
const useCustomHook = (fn) => {
  useEffect(() => {
    fn && fn();
  }, []);
}

Having the ability to observe on a changing property is valuable for responding to specifically observable events, such as pagination as previously described, or incorporating RxJS into your application.

While you'll likely use useEffect in almost all occasions for loading data asynchronously and even mutating the DOM, useLayoutEffect is fired immediately after the DOM has been updated. This is before the browser "paints" the changes, providing an entry point to do additional mutations before the user can even see the changes. This is hugely beneficial when content needs to be dynamically resized, or external DOM documents are being loaded and need to be mutated, or styles need to be changed.

Because the hook fires synchronously, computationally intensive functions will block the render of the UI, resulting in an interface that may appear laggy or glitchy. You should use useLayoutEffect when you need to mutate the DOM and/or perform/calculate measurements, and useEffect when you don't need to directly interact with the DOM, or mutations are asynchronous/observable.

Stay tuned for the next article when we determine if redux and redux-saga are really needed, and what other options are available.

Less is more; simplify your React code to super power your applications - part 2

Justin Mitchell — Wed, 17 Feb 2021 07:09:33 +0000

This is the second article in a series covering different strategies to simplify your React applications.

Simplify a React component

There's a number of strategies that we can take to simplify our components without drastic overhauls of existing components. Each strategy will be covered in a different blog.

Separate state from display, this will help your application align with well established MVC rules
Defer processing to services and custom hooks
Avoid overloading useEffect and useState
Determine if redux & redux-saga are really needed
Create higher order components to join functionality between components
Shift computational logic out of components into helper functions, inject with custom hooks
Use lazy loading and lazy behaviour where possible

Defer processing to services and custom hooks

React lacks the concept of services, unlike Angular which has it baked into the framework, especially through injectable resources. As React developers, we need to bake this functionality into our projects. Services neatly encapsulate specific functionality, become an interchangeable resource through TypeScript casting, and is another step towards shifting logic away from the presentation layer.

Quite often, we'll see a component that might do fetching and presentation in the same component:

const myComponent: React.FC = () => {
  const [ todos, setTodos ] = useState<any>([]);
  useEffect(async () => {
    const result = await axios.get("https://jsonplaceholder.typicode.com/todos");
    const todos = res.data.filter(!!todos.completed));
    setTodos(todos);
  });

  return (
    <ul>
    { todos.map(item => (
      <li key={item.id}>
        <a href={`https://jsonplaceholder.typicode.com/todos/${item.id}`>{item.title}</a>
      </li>
    ))}
    </ul>
  )
}

Surface level it doesn't look like much is wrong with this component. But what if we need to start handling errors from the API, additional validations and data manipulations? Our useEffect hook suddenly becomes overloaded, bloated with behaviour that can and should be deferred to a service.

useEffect(async () => {
  try {
    const result = await axios.get("https://jsonplaceholder.typicode.com/todos");
    const todos = res.data.filter(!!todos.completed));
    setTodos(todos);
  } catch (e) {
    setLoaded(false);
    setErrorMessage("Could not load todos, please refresh your browser and make sure you're connected to the internet!");
  }
});

The more we add to our useEffect hook, the more complex the component becomes and the more difficult they become to test. Deferred/asynchronous rendering already makes testing difficult, with tools like jest and enzyme handling updates, but not easily.

We can simplify this code by shifting the API handling to a service, allowing us to make requests and handle errors consistently, and separating the useEffect code into a custom hook.

type Todo = { id: number, title: string };
type TodosService = {
  todos: async (completed?: boolean) => Promise<Array<Todo>>,
  todo: async (id: number) => Promise<Todo>
};

class TodosServiceImpl implements TodosService {
  async todos(completed?: boolean): Promise<Array<Todo>> {
    try {
      const result = await axios.get("https://jsonplaceholder.typicode.com/todos");
      if (completed !== undefined) {
        return res.data.filter(todo => todo.completed === completed));
      }
      return res.data;
    } catch (e) {
      throw "Could not load todos, please refresh your browser and make sure you're connected to the internet!";
    }
  }

  async todo(id: number): Promise<Todo> {
    try {
      const result = await axios.get(`https://jsonplaceholder.typicode.com/todos/${id}`);
      return res.data;
    } catch (e) {
      throw `Could not load todo ${id}, please refresh your browser and make sure you're connected to the internet!`;
    }
  }
}

In the case that we need an interchangeable service, we can provide a new service as long as it satisfied the contract of TodosService:

const todosService: TodosService = {
  todos: async (completed?: boolean): Promise<Array<Todo>>  => {...}
  todo: async (id: number): Promise<Todo> => {...}
}
// test of the implementation

Now that we have our service implementation, we can consume it in our components:

const todosService: TodosService = new TodosServiceImpl();

const useTodosLoader = (todosService: TodosService) => {
  const [ todos, setTodos ] = useState<Array<Todos>>([]);
  const [ hasError, setHasError ] = useState<boolean>(false);
  const [ loaded, setLoaded ] = useState<boolean>(false);

  useEffect(async () => {
    try {
      const list = await todosService.todos();
      setTodos(list);
      setLoaded(true);
    } catch (e) {
      setHasError(true);
    }
  }, []);

  return { todos, hasError, loaded };
}

const myComponent: React.FC<{ todosService: TodosService }> = ({ todosService }) => {
  const { todos, hasError, loaded } = useTodosLoaded(todosService);

  return (
    <ul>
    { todos.map(item => (
      <li key={item.id}>
        <a href={`https://jsonplaceholder.typicode.com/todos/${item.id}`>{item.title}</a>
      </li>
    ))}
    </ul>
  )
}

All aspects of the above code is testable - we can verify that the serice is called, we can also verify the API is called. We can verify the loading of MyComponent through the responses of useTodoLoader, and we can mock and stub the behaviour right the way through. While we've at least doubled the amount of code to simplify the component, the increase in code is directly proportional to the simplicity of the functional code and the test code.

Custom hooks allow us to logically group behaviours together, especially when we maniuplate state using useState hooks. We can expose outputs from the hook to be consumed in our component, allowing to be updated when the hooks change the state. This provides rich functionality to use cross components, especially when using useState to maintain state between components.

const useMyState = () => {
  const [ myState, setMyState ] = useState(true);
  return { myState, setMyState }
}

const myComponent = () => {
  const { myState } = useMyState();
  ...
}

const myOtherComponent = () => {
  const { myState, setMyState } = useMyState();
  useEffect(() => {
    setTimeout(() => {setMyState(false)});
  }, []);
  ...
}

We can also use hooks to subscribe to event streams. This allows mutliple non-connected components to update at the same time based on state changes, or driven by events.

const myEventStream = () => {
  const [ myState, setMyState ] = useState(null);
  useEffect(() => {
    const subscription = observable.subscribe();
    subscription.next(event => setMyState(event.data));
    return () => subscription.unsubscribe();
  })

}

const myComponent = () => {
  const { myState } = useMyState();
  ...
}

const myOtherComponent = () => {
  const { myState } = useMyState();
  ...
}

observable.next({data: { foo: "bar"}});
// Updates myComponent
// Updates myOtherComponent

Stay tuned for the next article when we'll look at avoid overloading useEffect and useState.

Less is more; simplify your React code to super power your applications - part 1

Justin Mitchell — Tue, 16 Feb 2021 13:23:43 +0000

When it comes to React development, there's a mantra that as developers we often forget, one that never, ever should be forgot: "less is more". It's much more than an expression, it's a way of thinking, a way of solving problems, and it should be an influence on your design. KISS has been around for more than 60 years, and it's still as prescient today as it was over half a century ago.

As developers, we should avoid over engineering and over developing, doing too much when a much less is required to achieve the same result. This can be a combination of refactoring our components into smaller components, reducing complexity of our component inputs/outputs, and avoiding too much processing and complex algorithms.

We should be aiming to make everything as simple as possible, without making it simpler. That is to us, working as efficiently as possible without cognitive overload, without reducing the work we do to the simplest possible level, often creating more work. This isn't an issue isolated to new programmers only; we've all taken a shorter route to achieve an objective or goal. Sometimes we have no choice, sometimes we do it because we might not know a better way, and other times because we just don't want to invest the time to do it properly.

Less is more is something that developers of all sorts of experience can engage in, and should. It will inevitably improve your application development, improve the applications you work on, and help you work more effectively. The ultimate goal of measurement of a developer shouldn't be lines of code; it should be in quality of code produced, error rate and rework required.

Simplify a React component

There's a number of strategies that we can take to simplify our components without drastic overhauls of existing components. Each strategy will be covered in a different blog.

Separate state from display, this will help your application align with well established MVC rules
Defer processing to services and custom hooks
Avoid overloading useEffect and useState
Determine if redux & redux-saga are really needed
Create higher order components to join functionality between components
Shift computational logic out of components into helper functions, inject with custom hooks
Use lazy loading and lazy behaviour where possible

1. Separate state from display, this will help your application align with well established MVC rules

Traditional application design following MVC principles, is to split application logic into three distinct components; model, view and controller. The controller is responsible for handling user entry and exit and user events. The model is responsible for responding to user data mutations, and the view should always reflect the model.

Let's look at an example of simplifying a common React component structure:

const globalState = someStateTool();
const myComponent: React.FC<> = () => {
  const [ myState, setMyState ] = useState<any>({});
  const [ loaded, setLoaded ] = useState<boolean>(false);

  useEffect(() => {
    setTimeout(() => { setLoaded(true); }, 2500);
    setTimeout(() => { globalState.set("foo", "bar")}, 5000);
  }, [])

  return loaded ? (<MySubComponent/>) : (<SpinnerComponent/>);
}

const mySubComponent: React.FC = () => {
  const [ someState, setSomeState ] = useState<any>(null);
  globalState.subscribeTo("someEvent", ev => setSomeState(ev.data));
  const handleClick = () => globalState.set("foo", "bar");

  return (
    <div>
      <button onClick={handleClick}>Some title</button>
    </div>
    <div>{someState.foo}</div>
  )
}

Each component includes isolated functionality, specific to that component. Thus, they are not pure, but they are independent and interchangeable. These type of components inherently respond to various user input behaviours and data driven events. That often comes hand-in-hand with increased complexity, and increased coupling, if not directly on parent components, but on streams, event subscriptions and other sources of data and events.

There's also a significant testing effort involved in each component, as both will need to mock various services and providers and handle behaviours and interactions.

// Create a contract for the sub component
type SubComponentType = { foo: string, handleClick: () => void };

const globalState = someStateTool();
const myComponent: React.FC<> = () => {
  const [ myState, setMyState ] = useState<any>({});
  const [ loaded, setLoaded ] = useState<boolean>(false);
  globalState.subscribeTo("someEvent", ev => setMyState(ev.data));
  const handleClick = () => globalState.set("foo", "bar");

  useEffect(() => {
    setTimeout(() => { setLoaded(true); }, 2500);
    setTimeout(() => { globalState.set("foo", "bar")}, 5000);
  }, [])

  return loaded ? (<MySubComponent foo={myState.foo} handleClick={handleClick}/>) : (<SpinnerComponent/>);
}

// Make sure our component adheres to the type contract
const mySubComponent: React.FC<SubComponentType> = ({ foo, handleClick }) => {
  return (
    <div>
      <button onClick={handleClick}>Some title</button>
    </div>
    <div>{foo}</div>
  )
};

We can even take this one step further and separate the transition component into a higher order component, or a wrapping component that renders different components based on state.

type SubComponentType = { foo: string, handleClick: () => void };

const globalState = someStateTool();

const myComponentLoader: React.FC = () => {
  const [ loaded, setLoaded ] = useState<boolean>(false);

  useEffect(() => {
    setTimeout(() => { setLoaded(true); }, 2500);
  }, [])

  return loaded ? (<MyComponent/>) : (<SpinnerComponent/>);
}

const myComponent: React.FC<> = () => {
  const [ myState, setMyState ] = useState<any>({foo: globalState.get("foo")});
  globalState.subscribeTo("someEvent", ev => setMyState(ev.data));
  const handleClick = () => globalState.set("foo", "bar");

  return <MySubComponent foo={myState.foo} handleClick={handleClick}/>;
}

const mySubComponent: React.FC<SubComponentType> = ({ foo, handleClick }) => {
  return (
    <div>
      <button onClick={handleClick}>Some title</button>
    </div>
    <div>{foo}</div>
  )
};

We've created more lines of code to represent the same component structure, but we've:

Separated the model logic from the view logic
MySubComponent is a pure component; given the same inputs, it should always produce the same output
MyComponent is easily testable with a tool like Enzyme - just need to verify the sub-component is loaded
All loading logic is handled through a top-level component. The components that can be loaded can be swapped when required.

Stay tuned for part 2 where I'll cover deferring processing to services and custom hooks.

It's time to let go of lodash

Justin Mitchell — Tue, 16 Feb 2021 01:14:48 +0000

In today's world of JavaScript, there's a huge number of tools that solve the same problem in slightly differing ways. Some of the tools are driven by simplicity, some driven by configurability, and others by extensibility. Lodash is one of those handful of libraries, that were created to solve a growing problem, that fortunately due to Microsoft's foresight, no longer exists.

I'm talking of course about Internet Explorer 11.

At the time lodash was created, ES6 was just a glimmer in the eye of web developers, an idea and a desire for most front end developers. In the world of Bootstrap, jQuery, underscore, prototype and a huge number of other tools, lodash provided a consistent and clear interface. Classes, functional programming, and all the goodness and richness that we take for granted was years away.

Let's jump forward to today; we're living in the days of ES11. Browsers are no longer competing on the same standard. The three most used browsers in the world use Webkit or Chromium, standards are consistent and there's very little difference in adoption and behaviour across most browsers. We don't have to tailor our JavaScript or CSS to the version of IE, or Safari, or Firefox, or even OS, because it's all a little difference.

We're now able to just do once, and it do it well. Efficiency has never been better. But that IE11 troll still lives in the cave over there, and we need to find a way to feed it, and avoid it. Fortunately, we can rely on core js and babel, transpilers that spit out ES5 compatible JavaScript that IE11 through to IE Edge 18 can support.

Which brings us neatly to the topic of the blog - do we need lodash anymore?

Do we need lodash?

Transpilers, compilers and build tools try to solve the file size bundling issue in different ways, such as webpack using tree shaking to identify code that isn't used. But lodash is stubborn, it's a painful library to reduce in file size. Even using something as simple as .get imports a significant amount of code. Why? It depends on itself, tools within its own library. cloneDeep is another utility that adds a significant amount of code.

There are more than 100 utility helpers and the majority of them aren't required anymore. Babel is the industry standard for cross-compiling ES6+ code into ES5 compatible code for older browsers. In time, that won't be required with, once users on legacy browsers have been migrated off.

Tuning your build to reduce lodash bloat

There's few options that developers have to reduce the bloat that lodash brings into your compiled build. But there are several strong options:

Import only the functions you need through lodash/* or lodash.*:

const _ = require("lodash"); // typical library import that will bring in the lodash base
const get = require("lodash.get"); // import the specific tool you need, needs to be imported through package.json
const get = require("lodash/get"); // import the specific tool from the lodash base library

Replace lodash Array/Object helpers with native functions:

const myArray = [];

// Lodash array fill 10 elements
const fill = require("lodash/fill");
fill(myArray, {foo: "bar"}, 0, 10);

// Native array fill 10 elements
myArray.fill({foo: "bar"}, 0, 10);

Assess if you really need some of those handy utility functions - do you really need a cloneDeep or merge? Object spread operator can do something very similar with minimal code to merge objects. You don't even have to do Object.assign anymore.

// Merging objects
const myArray = [...[1, 2]]; // [1, 2]
const myFoo = { ...{foo: "bar"}, bar: "foo"}; // {foo: "bar", bar: "foo"}
const myFoo = { foo: "bar", ...{foo: "qwerty"}}; // {foo: "qwerty"}

Array functions are supported across all browsers and replicate a lot of lodash's functionality

const myArray = [1, 2, 3];
// Map
console.log(myArray.map(val => val * 2)); // [2, 4, 6]

// Reduce
console.log(myArray.reduce((acc, val) => acc + val)); // 6

// Entries
const it = myArray.entries();
for (const entry of it) {
    console.log(entry);
    // [0, 1]
    // [1, 2]
    // [2, 3]
}

// Find
console.log(myArray.find(val => val === 3)); // 3

// Filter
console.log(myArray.filter(val => val > 1)); // [2, 3]

// Includes
console.log(myArray.includes(3)); // true

// Cast array
console.log([1]); // [1]

// Unique
console.log([...new Set([1,1,2,3])]); // [1,2,3]

Use babel or core js to compile ES6+ code into ES5 compatible code for older browsers
Make use of JavaScript core functionality to do type inference and checking:

_.isArray([]); //true
Array.isArray([]); //true

_.isNull(null); //true
null === null; //true

_.isObject({}); //true
{} !== null && typeof {} === "object" && Object({}) === {}; //true

_.isBoolean(true); //true
Boolean(true); //true

Use JavaScript functions for Math and Date:

_.now(); //1613434837495
Date.now(); //1613434837495

_.add(6, 4); //10
6 + 4; //10

_.ceil(4.1); //5
Math.ceil(4.1); //5

_.max([1,2,3]); //3
Math.max(...[1,2,3]); //3

Use JavaScript object functions:

_.assign({a: 0}, {a: 1}, {b: 2}); //{a: 1, b: 2}
{a: 0, ...{a: 1}, ...{b: 2}}; //{a: 1, b: 2}

_.omit({a: 0, b: 1}, ["a"]); //{b: 1}
const {a, ...obj} = {a: 0, b: 1}; //a=0, {b: 1}

_.pick({a: 0, b: 1, c: 2}, ["a", "c"]); //{a: 0, c: 2}
const {b, ...obj} = {a: 0, b: 1, c: 2}; //b=1, {a: 0, c: 2}

Use JavaScript collection commands:

_.forEach([1, 2], val => {});
[1,2].forEach(val => {});

_.find([1, 2], val => {});
[1,2].find(val => {});

_.filter([1,2], val => {});
[1,2].filter(val => {});

// Partition
_.partition([{foo: "bar", active: true},{foo: "foo", active: false}], val => val.active); 
// objects for [["bar"],["foo"]]

const partition = [];
[{foo: "bar", active: true},{foo: "foo", active: false}]
    .forEach(val => {
        if (!Array.isArray(partition[Number(!!val.active)])) partition[Number(!!val.active)] = [];
        partition[Number(!!val.active)].push(val);
    });
// objects for [["bar"],["foo]]

Summary

Do we need lodash today? Not really, no. Core JS and Babel do a fantastic job in compiling ES6+ code to ES5 compatible code. A lot of the cross-browser compatible functionality that lodash offers is now easily replicatable in the browser natively. There are lightweight options for merge and cloneDeep, and even native ways of doing cloneDeep, as long as the structure doesn't include functions, such as using JSON.parse(JSON.stringify(original)).

Specific functionality can be brought in on a needs-basis, but other functionality, such as get can easily be created to be project and application specific.

While lodash offeres a tremendous library of functionality, much of it is no longer required, and the cost of importing lodash into your application can be huge, well over 600kb if your compiler doesn't shake the unrequired code, or you use lodash throughout your application.

Pre ES6, lodash was an absolute gem, just like jQuery was back in its day, providing rich cross-browser functionality. These days, all the browsers treat JavaScript standards fundamentally the same, with very little difference.

The days of JScript, Trident and Chakra are long gone, let's not continue to use tools from those days, go native!

Code coverage testing, when enough is enough

Justin Mitchell — Sun, 14 Feb 2021 05:52:44 +0000

Coverage testing in application development is often a tough, challenging, hugely complex and often thankless task, and just one of a myriad of testing tools available to developers.

Designing your application architecture in advance, providing the right tools, knowledge, training and education to your team of developers, and following the best programming principles helps developers achieve what is the ultimate goal in code testing - 100% coverage.

For the majority of projects that developers work on, code coverage is one of those increasingly difficult and time consuming daily tasks. There are many ways to cheat 100% coverage testing, such as using Snapshot testing in React, but it doesn't really get you there, nor does it achieve what code coverage is meant to achieve. Let's dig into that shall we!

What's the difference between white box and black box testing?

White box testing is a technique that is used to validate the internal structure of the code, the design, input-output flow, decisions, error handling and more. This is otherwise known as open box testing; the code is open, transparent and accessible. Parts or all of the application can be tested, with resources, classes and functions stubbed and mocked.

This is typically comprised of unit tests, and can be created using a mix of test drive development (TDD) or business driven development (BDD) tools, or plain old writing tests as you go.

Black box testing on the other hand is testing the application as unit. Unlike white box testing where the source code is accessible and transparent, in black box testing, you are testing the inputs and outputs against the entire application. This is what E2E, user story and automated environment integration tests normally focus on; testing all of the application at once.

Unit tests and code coverage

Code coverage is a manner by evaluating the source code execution against a suite of tests. This is typically extrapolated by unit test libraries with inbuilt code scanning tools, but can also be extracted with black box testing (eg. Istanbul). For the sake of simplicity, we'll refer to coverage testing as the side effect of unit testing - this is the most common testing tool used to generate code coverage.

When a test is executed, tools scan the output of the test, the code itself and other software registers that tracks application logic flow. The coverage report that is generated, indicates what part of the source code has been executed and what has not been executed. The report that is generated can indicate flow issues and decision issues that the code has, and how frequently a sequence of code, function or conditional block was executed.

Limitations on code coverage

The purpose of software testing is to validate the software and provide information about the quality of the software. What sort of tests, how tests should be created, and what they should test, is a never ending discussion between testers. Some believe that you should test the source code itself, others believe that you should only test for user behaviours. But what if the source code you write doesn't match either scenario?

Ideally tests should reflect application flow, logic and where possible, behaviours. This leaves us in a bind if our logic is inherently complex, or a considerable amount of logic is abstracted with reduced application visibility.

How exactly do we test protected and private methods - should we even attempt to do that? How do we validate user input changes in JavaScript in an Angular or React application, should we load the entire eco system and validate the HTML? But wait, isn't that something we can and should be validating with Cypress as a white box test, or even a black box test?

This is the how, what, where and why of testing. If your test cases follow your code, you're likely to run into this issue. If your test cases precede your code, you're more than likely writing tests to validate behaviour, rather than logic. It's a delicate balancing act, and quite difficult to solve, and will require a lot of trial and error.

Ok, so what's wrong about coverage testing?

Which brings us neatly to coverage testing. Rigorous discipline is often required with testing to extract the best possible result from testing itself, especially measuring coverage. The only problem is that test code is as likely to be as buggy as the software code itself.

Given a boolean for example, to ensure coverage for both states of the property - true and false - at least two different tests are required. This is a combinatorial problem; for each decision that is required, at least 3-5 lines of code are required to write and validate the test. This takes time to validate just one property.

// Code
let counter = 1;
function foo(state: boolean): void {
    if (state) {
        counter++;
    } else {
        counter--;
    }
}
// 8 lines

// Test
// 8-10 lines bootstrap
it("should increment counter by 1 when state is true", () => {
    expect(counter).toBe(1);
    foo(true);
    expect(counter).toBe(2);
});

it("should decrement counter by 1 when state is false", () => {
    expect(counter).toBe(1);
    foo(false);
    expect(counter).toBe(0);
})
// 10 lines of test code

What about validating conditional statements and branches? The same holds true, for each possible decision, a test is required. The complexity and amount of code required is an exponential growth for each additional decision branch, especially if ternary operators are used, or in the case of Javascript, null-coalesce and optional chaining.

const state: {string: any} = {};
function foo(state?: boolean): undefined | string {
    let bar = state ? "bar" : "foo";
    if (state) {
        state.foo = 1;
    }

    return state?.bar?.foo;
}

it("should return undefined for foo with false", () => {
    expect(foo(false)).toBeUndefined();
})

it("should return undefined for foo with false if state.bar has data", () => {
    state.bar = {};
    expect(foo(false)).toBeUndefined();
})

it("should return string for foo with false when state.bar.foo has value", () => {
    state.bar.foo = "somestring";
    expect(foo(false)).toBe("somestring");
})
// etc

Our example above is not an uncommon example of combining conditional statements with ternary operators and optional chaining in the same function. It's so common in fact, that you'll see a combination of all three in the majority of React tutorials, especially ternary operators for conditional rendering. All that our three tests have validated is that the optional chain can be executed with three different states.

Ways to improve code coverage

What should we do when our code makes use of the latest and greatest in Javascript browser functionality? Should we ditch ternary operators, null coalesce and optional chaining? Not exactly. It's not uncommon to see an optional chain that looks like the following, and there are strategies to mitigate the impact this has, not just on code coverage, but testing in general.

const something: string | undefined = myvar?.has?.a?.very?.deep?.nested?.structure;

Optional chaining

What strategy can we use for testing the above example? while it looks like it might return either string or undefined, there are 8 possible values that can be assigned to something: 7 undefined and 1 string value. Do we test every branch of the statement, or can we test the assignment as a whole? The answer is yes, we can reduce our testing effort by extrapolating the lookup and assignment into a single function call.

const get = <T>(key: string, val: any, default?: undefined): T {
    // Get is a recursive lookup function, split the key into tokens, take the first token
    // look up val object for key, return get(keys.join("."), val[key]);
    // This code is incomplete and an example only - do not copy & paste
    const keys = key.contains(".") ? key.split(".") : [ key ];
    const tKey = keys[0];
    if (tKey in val) {
        return get(keys.join("."), val[tKey], default)
    } else {
        return default;
    }
}

const something: string | undefined = get("has.a.very.deep.nested.structure", myvar);

Our tests have been greatly simplified to testing the assignment, no longer validating the various branches of assignment based on the existence of a complete structure.

const myvar = {};
const something: string | undefined = get("has.a.very.deep.nested.structure", myvar);

it("should return value if structure exists in nested", () => {
    myvar.has.a.very.deep.nested = { structure: "foo" }
    expect(something).toBe("foo");
});

it("should return undefined if cannot find value", () => {
    expect(something).toBeUndefined();
})

Under the hood, the optional chaining is comparatively the same as looking up a deeply-nested sub-property using conditional assignment with double ampersands &&:

const foo = { bar: "bar" }
const bar = foo && foo.bar;
// bar is "bar";
const buzz = foo && foo.buzz;
// buzz is undefined

// Is the same as:
const foo = foo?.bar;
const buzz = foo?.buzz;

Nested ternary operators

This can be a tough one, especially when nested ternary operators are used to simplify conditional logic, shorten code and remove nested if-else blocks and switch statements. With the reduction in code comes the increase in complexity and vast increase in testing effort. With a single ternary operator, there are two possible outcomes. Each nested ternary operator adds an additional outcome. These are all registered as branches and must be validated through unit tests.

For something that saves lines of code, the testing effort is disproportionally huge.

function foo(foo): string {
    return foo
    ? bar
    : (somethingElse ? bizz : fuzz)
}
// 5 lines

it("should return bar", () => {
    expect(foo(foo)).toBe(bar);
});

it("should return bizz", () => {
    expect(foo(bizz)).toBe(fizz);
});

it("should return fuzz", () => {
    expect(foo(buzz)).toBe(buzz);
});
// 9 lines + bootstrap of test

This doesn't even account for using ternary operators to set values, that are then used in conditional logic in the same block of code.

Testing private/protected methods

Depending on the philosophy of testing that you, or your team or project is following, private and protected methods may not just be off limits, but sacrosanct and completely off limits for testing. There are ways around this, such as fudging or brute forcing variables (eg. myvar: any), using code introspection to know more about what you're testing, then reflection to modify the visible of certain functions, classes and methods.

If this is what you have to do to pass a test, then it's what you have to do, but you are breaking fundamental testing principles to measure the immeasurable code of your application. It often does lead to breaking tests as soon as there's a refactor, which may or may not be acceptable.

Take for example the following class, what should we test, and how do we validate our non-visible properties and methods? How do we get 100% test coverage?

class Foo {

    protected state?: string;

    public doSomethingFn(foo: boolean): void {
        this.someFn(foo);
    }

    protected someFn(foo: boolean): void {
        if (foo) {
            someFn2(foo);
        }
    }

    protected someFn2(foo: boolean): void {
        this.state = !!existingState
            ? "Oranges"
            : foo ? "Apples" : "Bananas";
    }
}

100% test coverage for Foo is going to be very difficult to test - why?

We can't validate state - ever, unless we manipulate the class and expose state.
someFn and someFn2 are protected methods, that can only be validated by calling the public doSomethingFn
The assignment of this.state includes conditional logic

Without manipulating the class and using reflection to change visibility, we can only execute these tests:

const foo = new Foo();

it("should accept true for doSomethingFn", () => {
    expect(foo.doSomethingFn(true)).not.toThrowException(Exception.any());
});

it("should accept false for doSomethingFn", () => {
    expect(foo.doSomethingFn(false)).not.toThrowException(Exception.any());
})

// Let's get to fudging/brute forcing!
// This test is worthless, what is it telling us?
it ("should call someFn", () => {
  const localFoo: any = new Foo();
  spyOn(localFoo, "someFn");
  localFoo.doSomethingFn(true);
  expect(localFoo.someFn).toHaveBeenCalledTimes(1);
})

These tests are fundamentally worthless; they tell us nothing of the inner working of the class, they only validate the input of a single function, don't indicate the altered state, nor any mutating logic being applied to the state. The next developer will likely look at that in a confused state and wonder why those tests exist.

Refactoring

When you're stuck writing tests like those above, it's time to look at the code in a new light and consider refactoring as a solution. As was discussed earlier, unit tests ensure that the section of the application under test meets its design and functions as expected. We're unable to identify the design, purpose or function of class Foo, so lets redesign it so that it makes more sense, and we can test the "units" (the section of application) in isolation.

interface Store {
    get: (key: string) => any;
    set: (key: string, value: any) => void;
    emit: (key: string, value: any) => void;
    subscribe: (event: any) => any;
}

class Foo {

    protected store: Store;

    constructor(store: Store) {
        this.store = store;
    }

    public doSomethingFn(foo: boolean): void {
        this.someFn(foo);
    }

    protected someFn(foo: boolean): void {
        if (foo) {
            someFn2(foo);
        }
    }

    protected someFn2(foo: boolean): void {
        const existingState = this.state.get("foo");
        const state = !!existingState
            ? "Oranges"
            : foo ? "Apples" : "Bananas";

        this.store.set("foo", state);
    }
}

We've separated state object from the class Foo, creating it as an independent container that can be validated and tested in isolation. We can also mock it and spy on specific function calls. We can also validate end-to-end that calling doSomethingFn that state will definitely be set, by reading the code. We can now validate the functionality of the code with the following tests:

let state: State;
let foo: Foo;

beforeEach(() => {
    state = new State();
    foo = new Foo();
});

// Every single one of these tests have meaning and we can infer execution
// of internal logic without directly validating them through hacky methods

it("should call state.get when doSomethingFn is called with true", () => {
    spyOn(state, "get").and.returnValue(undefined);
    foo.doSomethingFn(true);
    expect(state.get).toHaveBeenCalledTimes(1);
})

it("should call state.set when doSomethingFn is called with true", () => {
    spyOn(state, "set");
    foo.doSomethingFn(true);
    expect(state.set).toHaveBeenLastCalledWith("Apples");
})

it("should not call state.get or state.set when doSomethingFn is called with false", () => {
    spyOn(state, "get");
    spyOn(state, "set");
    foo.doSomethingFn(false);
    expect(state.get).not.toHaveBeenCalled();
    expect(state.set).not.toHaveBeenCalled();
})

it("should set state as Apples when doSomethingFn is called with true", () => {
    spyOn(state, "set");

    foo.doSomethingFn(true);
    expect(state.set).toHaveBeenLastCalledWith(["foo", "Apples"]);
})

it("should set state as Oranges when doSomethingFn is called with true twice", () => {
    spyOn(state, "set");

    foo.doSomethingFn(true);
    foo.doSomethingFn(false);
    foo.doSomethingFn(true);
    expect(state.set).toHaveBeenLastCalledWith(["foo", "Oranges"]);
})

Conclusion

Coverage testing is a powerful tool that should be used to indicate strengths, weaknesses, overuse, under use and complexity of your code. Just like any tool, it can only go far and has significant limitations, especially when it can be impossible to evaluate every path, function, and property.

While it may not be possible to reduce or remove all branches from your code, there are strategies to mitigate the impact they have, especially when using syntactic sugar like null-coalesce, ternary operators and optional chaining.

Code coverage shouldn't be used as the ultimate tool; it should be used as a reflection of the testing effort and how well validated the application code is. As we've seen from our examples above, there can be as much as 2x-to-3x code to validate functionality with tests, than writing it. When aiming for 100% code coverage on poorly designed or implemented code - that is application logic riddled with branches and paths, it may prove to be impossible, or at least require something closer to 10x code to validate.

Unit tests aren't perfect, they've been written by humans, and are as strong as the developer who wrote them. They often break, can be a nightmare to fix, and are often discarded when newer code is created. Stick to the testing plan, be disciplined and set the expectations for the code coverage report.

Managing your ReactJS application state with RxJS

Justin Mitchell — Sun, 04 Oct 2020 07:28:48 +0000

First published on js.dev → https://thejs.dev/jmitchell/managing-your-reactjs-application-state-with-rxjs-2hq

Do we need state management libraries?

Managing application state is one of the hardest parts of writing an application. It's often the first created component of any application, but tends to suffer from application growth. How exactly do you plan for managing application state in a huge code base, when you made decisions early on.

When it comes to state manage in React applications, there's a seemingly never ending discussion on the right approach. Do we go with Redux, work with the boilerplate code and embrace the additional complexity, consider MobX but shift to an imperative approach using an object-oriented pattern. Or do we stick with React and use the in-built functions, like hooks and Context API to manage our state.

Both approaches suffer when your application grows, and neither are interchangeable, given their contrasting approaches. This is when React state hooks and the Context API are introduced, and as advocates will tell you, it's just easier to handle state using React.

There are plenty of alternatives to using redux, but none really address the core issue of state management; how do you manage application state as the application grows? One of the reasons why Redux has been so popular, is because it solves the problem of prop drilling, that intricately links components through dependencies of data.

The issue with redux-like libraries is that components and data are inexorably linked; components are dependent on redux and cannot take updates from the redux stores, without being redux components. This tight coupling is a choice that has to be made at the start of the project. Libraries like MobX are more flexible in their approach, but you still have to issue of state-to-component coupling, it's unavoidable.

What about using React to manage our state?

Utilising the Context API allows us to pull in state as we need it, perform necessary operations and then commit our changes. Any components that depend on that context, with that data scope, will automatically receive the updates. Sounds great right? Well, here's the kicker. Context API can be used to manage application state, but how do you manage the scope? It typically ends up being prop-drilling shifted elsewhere, more often than not, in the Contexts.

That's not to say you shouldn't use the Context API to manage application state, quite the opposite. You should use it to help manage application state, but in the means to inject application state where it's required. Using Context API to specifically manage your application state, is marginally better than prop drilling. At some point, somewhere in your application, contexts can, and often do, get linked.

We can combine useState with the Context API, use deferred actions like useEffect, useMemo and other hook functions, or the equivalent functions with class components, to achieve a very-React way of doing things. But, how do we know what the state of our Context APIs are, or which ones we need to import, or which ones we need to update? How about asynchronous actions, race conditions, immutability?

Context API and React hooks don't solve this issue, which is what libraries like Redux attempted to solve in the first place. Which brings us full circle: React prop drilling (React) → Redux/MobX (Lib) → Context APIs and hooks (React).

Why use Redux or MobX?

One of the benefits that Redux brings is the approach to decouple of the state from the component. The side effect of that effort, is that state management is far more abstract than providing a simple API, or even using dereferencing (MobX) to directly update state.

How often have you heard a developer say they would rather work with Redux, sagas, epics, middlewares and actions, over a direct approach like MobX or the Context API? Dereferencing is the far more understandable approach, certainly for developers learning how to manage application state. You lose a lot of what Redux provides you, but you also do away with an extraordinary amount of boiler plate code, just to get redux started.

Let's create our context first, this is the same for all approaches except Redux which bundles its own Context provider:

// Context API
const { createContext, useContext } = require("react");

const StateContext = createContext({});
const useStateContext = () => useContext(StateContext);
const StateProvider = StateContext.Provider;

Let's use the Context API:

const Foo = () => {
  const { foo } = useStateContext();
  return <div>Foo: {foo}</div>;
}

ReactDOM.render(
  <StateProvider value={{foo: "bar"}}>
    <Foo />
  </StateProvider>
  , document.getElementById("main")
)

Let's take a look at the approach with MobX:

// MobX
import { observer } from "mobx-react";
import { observable } from "mobx"

const Foo = observer(() => {
  const { foo } = useStateContext();
  return <div>Foo: {foo}</div>;
});

const data = observable({
  foo: "bar"
});

ReactDOM.render(
  <StateProvider value={data}>
    <Foo />
  </StateProvider>
  , document.getElementById("main")
)

Now let's look at Redux (notice how we don't use the Context that we've created, follow the guide here):

import { Provider, connect } from "react-redux";
import { createStore, combineReducers } from "redux";

const initialState = {
  foo: "bar"
};

const store = createStore(
  combineReducers(
    (state = initialState, action) => {
      switch(action.type) {
        case "SET_FOO": {
          const { foo } = action.payload;
          return {
            ...state,
            foo: foo
          }
        }
        default:
          return state;
      }
    }
  )
);

const Foo = ({foo}) => <div>Foo: {foo}</div>;

const mapStateToProps = state => {
  const { foo } = state;
  return { foo };
}

const ConnectedFoo = connect(mapStateToProps)(Foo);

ReactDOM.render(
  <Provider store={store}>
    <ConnectedFoo />
  </Provider>
  , document.getElementById("main")
)

Is RxJS a viable option?

For anyone familiar with Angular development, RxJS drives state management. User driven events, such as input value changes, button clicks, checkbox toggles and more, are fired by observables. Managing state in an Angular application is an asynchronous task; you fire the event, your UI will respond with the updated data. You can still add libraries like MobX and Redux to Angular, and many have done that, but there is a significant complexity penalty with taking that approach. Compared to Angular, React is as simple as it gets.

But let's not take it easy breezy and be unabashed with our approach to state management. It still needs to be carefully considered, thought out and well designed. After all, there's likely to be nothing more important in your application, than managing its state.

Which brings us to RxJS, and using the asynchronous tools to manage state.

I'm not going to tell you that it's easy, or that it's a simpler approach to state management in React, because it isn't. But what complexity it does add, certainly with boiler plate code, the benefits you get are far more advantageous than some of the options available.

Let's have a look at the example application that I've created on GitHub and discuss some of the approaches taken towards managing state.

The state management is influenced by Redux and the ideas of stores; data is logically stored in data blocks, prefixed with a store name, eg. "TODOS". You can fetch the state management object data at any time that you need through the Context API, and query the data in stores through the method getStore().

The API function getStore takes two inputs - the store name and the query path, a period-concatenated string of object literals, as well as an array filter function:

// Object querying
getStore("TODOS", "items");

// Array filtering
getStore("TODOS", "items.completed#1"); // returns [{}, ...]

// completed#1 is transformed to: field[completed], value[1]

If no value is present on the query path, undefined is returned. If an array filter is passed, and no array exists, undefined is also returned. When you filter on an array, if the value is an object, it will attempt to match the key/value against the field/value pair for each entry, or if the array value is not an object, it will attempt to match the entry value against the query value.

const items = [
  { completed: true },
  { completed: 1 },
  { completed: "1"}
  "1",
  1
];

getStore("TODO", "items.completed#1");

// Process:
items.filter(val => {
  if (val is object) {
    return val[field] === value;
  }

  return val === value
});

// Expected items: 5

Unlike MobX where dereferencing data in an observing object provides obserable behaviour on mutation or assignment, like Redux, the user needs to fire off an update event. You create a reducer that responds to update events, and then update the state dependent on that call. Where RxJS shines is that an event is an arbitraty event, you can opt to send data with the event, so that observers can instantly consume the new state without querying the store:

const [ item, setItem ] = useState(undefined);
// Register
registerStoreReducer("TODOS", event => {
  if (event.action === "SET.ITEM") {
    // Code to update store
    notifyObservers(event.store, "UPDATE", state.getStore("TODOS"));
  }
})

// Consume
subscribeOnStore("TODOS", "SET.ITEM")
  .subscribe(event => {
    setItem(event.data);
    console.log("Set data!");
  })

// Update
if (!item) {
  notifyObservers("TODOS", "SET.ITEM", { completed: false, id: 1 });
}

To load this approach into our application, we need to:

Initialise our RxJS state container
Create a store
Register reducers

const state = initialiseState();
registerReducers(state);
state.setState("TODOS.items", []);

ReactDOM.render(
  <StateProvider value={state}>
    <TodoList />
  </StateProvider>
  , document.getElementById("main")
)

The benefit of this approach over Redux is that we leverage the Context API, adding rich functionality on top of it, and leveraging the flexibility of the Context API to inject different streams of data whever we need it.

Let's say you have a user management state object on top of your todos. This isn't something you want to risk leaking into your wider application, so you would want to separate the state. Using the RxJS approach above, you would initialise a new state container and provide that through the ContextAPI.

Conclusion

Like Redux, there is boilerplate code to get going, but the one thing we're not doing with our code, is creating higher-order components to inject store data as props into our components. That approach would be handy, it would be great, but that should be a separate, opt-in approach.

The benefit that you do get with RxJS is simplicity over complexity. It's not as easy to use as the Context API or MobX, but you know through the naming conventions of the state utility functions, what happens where. Combining the observers with useEffect would be ideal, so that you can subscribe/unsubscribe as the data changes, but more importantly, unsubscribe from all store subscriptions when the component unloads.

This sample application is not intended for production use; it's a proof of concept to prove that an observable approach is possible, accessible and should be considered a viable alternative.

How to get started writing unit tests for React with jest and enzyme

Justin Mitchell — Fri, 02 Oct 2020 22:56:23 +0000

First published on js.dev → https://thejs.dev/jmitchell/how-to-get-started-writing-unit-tests-for-react-with-enzyme-and-jest-mfw

Testing in React can often be a challenge for developers. There are plenty of options and libraries to choose from, some more difficult to use than others. Some of that is down to the complexity or syntax of the testing frameworks, while React introduces plenty of its own issues that can be difficult to deal with, such as testing hooks and deferred actions.

This tutorial article assumes that you have basic knowledge of testing methodologies, either using jest, jasmine or other libraries, and you are familiar with the describe, it, before*, after* syntax.

React and jest

Jest with snapshops is the React recommended way of working, but they also suggest that you look at trying out React testing library. There's the old-school way of testing, pre-jest, which is to invoke events on elements wrapped in act() and then asserting changes to the dom. We won't be advocating that approach in this post.

JavaScript testing libraries jasmine, chai, sinon and mocha have shaped the way that developers write their tests, with simple to understand syntax, assertable states, mocks, spies and more. Jest and Enzyme are relative newcomers to the testing world, but bring along the same ideas that have worked so well in the past, while introducing a few new ideas of their own.

Jest is a JavaScript testing utility built for JavaScript by Facebook, primarily to support the testing effort in their React framework. It uses the concepts introduced from chai, sinon, mocha, jasmine and other libraries, even using them underneath to drive assertions, mocks and spies, to create a developer-friendly testing environment. With its simplistic approach to testing and very easy integration into React, it has become the preferred testing library for React applications.

Where enzyme fits in

Not every testing library is created equally though, and there is significant complexity within React applications that are just too difficult to test easily with jest. This is where Enzyme bridges the gap, as an alternative JavaScript testing utility for React, developed by Airbnb. The library aims to make testing your components easier, by allowing the developer to manipulate, traverse and simulate runtime events, and work with the results. In practice, it works better than it does on paper.

Enzyme currently (at the time of writing this article) has adapters that will work with React versions 16.x, 15.x, 0.14.x and 0.13.x. The only thing the user needs to do is install the plugin using their preferred package manager, and configure the adapter in the Enzyme runtime environment.

The difference between react-testing-library and enzyme is that enzyme isn't designed to override the testing environment, it's a tool that you can use alongside jest. React testing library can serve the same purpose, but it also provides functionality to fundamentally alter the testing runtime environment.

Getting started

Code: Step 1 - Adding jest.

For this tutorial, we'll be using a repository that I have created, with a basic component input form element and a rendered element for the output. As we progress through this post, I will share links with more completed code. So let's check out the code and get cracking!

This is our basic form that we will be testing:

Installing enzyme

Code: Step 2 - Installing and configuring enzyme.

The process of installing enzyme is straight forward and has the following steps:

Install the library through your preferred package manager.
Configure an enzyme adapter
Configure jest to use enzyme
Test!

This is the current adapter to react version mapping. Depending on the version of React that your project uses, you will need to install one of these adapters (full list of adapters and compatibility).

Adapter package	React semver version
`enzyme-adapter-react-16`	`^16.4.0-0`
`enzyme-adapter-react-16.3`	`~16.3.0-0`
`enzyme-adapter-react-16.2`	`~16.2`

To get started with enzyme, we simply install it into our project, along with the required adapter:

npm i --save-dev enzyme enzyme-adapter-react-16

Configuring the adapter

Once enzyme has been installed, we need to configure enzyme to use the adapter you want to use for the version of React that you have. To do this, you can use the top-level Enzyme.Configure() API:

// enzyme.setup.js
import Enzyme from 'enzyme';
import Adapter from 'enzyme-adapter-react-16';

Enzyme.configure({ adapter: new Adapter() });

Adding to jest

To be able to use enzyme tests with jest, we need to do an additional installation and configuration step, adding jest-enzyme and configuring it with jest.

npm i --save-dev jest-enzyme

If you don't already have a jest.config.js file, create it by copying the jest.config.js in the repository.

We need to add the enzyme configuration script to the jest.config.js file:

module.exports = {
  ...
  setupFiles: [ "<rootDir>/enzyme.setup.js" ]
}

Now that we've got enzyme added, let's get cracking with tests!

Crash course on enzyme

The one major benefit that enzyme has over jest and react-testing-library is the way that you can test the rendering and interactivity of components, through the use of helper methods shallow, mount and render.

Shallow rendering with `shallow()`

Shallow rendering is an extremely useful tool, as it constrains you to testing the component as a unit, without worrying about inadvertently testing and asserting the behaviour of child elements, hooks and other functionality.

The shallow API does call React lifecycle methods such as componentDidMount and componentDidUpdate.

Full DOM rendering with `mount()`

Mounting a component is equivalent to render() in react-testing-library; it performs a full dom render. This is ideal for use cases where you have components that may interact with an API, have deferred actions, interact with hooks, or are wrapped in higher order components.

Unlike shallow or static rendering, mount actually mounts the component in the DOM, which means tests can affect each other if they're using the same DOM.

Static rendering a component with `render()`

Static rendering utilises the render() function to generate HTML from your React tree, to compare and analyze the results. The wrapper returned is similar to mount and shallow, however render uses the thirdparty lib cheerio to do the traversing and parsing.

React hooks support

Enzyme supports React hooks with some limitations in shallow, due to the React renderer. The following hooks do not behave as expected when using shallow:

useEffect() and useLayoutEffect() doesn't get called
useCallback() doesn't memoize callback

Writing enzyme tests

Code: Step 3 - Writing enzyme tests.

Our app structure is made up of a single component Name, with a test file name.test.js. The first test that we're going to write will make use of enzym's shallow() renderer, which can work with hooks like useReducer() and useState(), which are vital for functional components.

Writing our first test

In this test, we're going to confirm that the component renders with an empty name by adding tests to the Name test suite file: <root>/src/components/name/name.test.js.

Tests already exist in this file, so we can go ahead and delete those, leaving us with a single describe:

describe("Component: Name", () => {
});

We need to set up the fixtures in our new test suite first, so that we write less boiler plate for each test. Add the following inside the Component: Name test suite:

let component = null;

beforeEach(() => {
  component = shallow(<Name />);
})

afterEach(() => {
  component = null;
});

Now that we've got our fixture set up, let's assert that the component shallow renders correctly using the exists() utility function:

it("should render component", () => {
  expect(component.exists("form")).toBe(true);
})

The shallow api provides us with useful helper functions that allow us to query the rendered DOM in a jQuery-like way. We can query on direct references of the component, an id, a class, an element, and even more complex query strings.

shallow also provides additional functionality in the ShallowWrapper API to check elements at node positions, if they exist, if they're visible and more.

Asserting default states

It's always prudent to assert the default rendered state of a component, given certain inputs. There are times when a component can be in a state of flux, given asynchronous and deferred actions, such as with the useEffect hook, but we still need to test those initial, indeterminate and final states.

Let's add an additional test and validate that our Name component renders as expected without state with the text() utility function.

it("should render default state", () => {
  expect(component.exists("#output")).toBe(true);
  expect(component.find("#output").text()).toBe("Hello, ");
});

Asserting name is displayed after entry

Now it's time to simulate user interactions and the reflection of those interactions on our UI. Enzyme provides a useful utility function with the shallow renderer to achieve that, by using simulate().

Simulate allows the user to trigger an event on the current node. Let's add our test to make sure our name is displayed when we enter it.

it("should display name when user types into input field", () => {
  component.find("input#name").simulate("change", { target: { value: "Charles" } });
  expect(component.find("#output").text()).toBe("Hello, Charles");
});

Shallow rendering with children components

Code: Stage 4 - Shallow rendering with child nodes

The idea of shallow rendering is the render only the component you need, but there are times when that's just not possible, such as when components have dependencies on shared libraries or shared resources. Other times, you may need to verify how a component behaves when a different theme or language is applied, and these changes are typically applied with the Context API.

In the next test, we're going to test rendering child nodes within the parent node.

First of all, let's create a new render component NameRenderer:

//<root>/src/components/name/nameRenderer.js
import React from "react";

export const NameRenderer = ({ name }) => <div role="output" id="output">Hello, {name}</div>;

Running our test suite should result in two failures:

✓ should render component
✕ should render default state
✕ should display name when user types into input field

This is because we are asserting on the element <div#output> which no longer exists in this component, but is rendered in another component. This is the side effect of using shallow - it only renders the nodes within the current component.

Using the extremely helpful .debug() utility function (also available with mount), we can see that the <div> has been replaced with the NameRenderer component:

<Fragment>
  <form autoComplete="off">
    <input type="hidden" autoComplete="false" />
    <label htmlFor="name">
      Name:
    </label>
    <input aria-label="name-input" type="text" id="name" name="name" value="" onChange={[Function: handleChange]} />
  </form>
  <NameRenderer name="" />
</Fragment>

Enzyme provides us with the dive() utility on the ShallowWrapper API, which allows us to render child nodes one at a time. Be careful though, because this can, and does trigger effects, lifecycle events and other deferred and asynchronous actions contained within that component. By using dive, you're also expanding the boundary of what a component unit test is as well.

Let's update our first broken test, should render default state, by implementing the dive() function.

//<root>/src/components/name/name.test.js
it("should render default state", () => {
  expect(component.exists(NameRenderer)).toBe(true);
  expect(component.find(NameRenderer).dive().find("#output").text()).toBe("Hello, ");
});

Running our test suite, we get:

✓ should render component
✓ should render default state
✕ should display name when user types into input field

Success! Let's update the last test case, which checks that the output is rendered:

//<root>/src/components/name/name.test.js
it("should display name when user types into input field", () => {
  component.find("input#name").simulate("change", { target: { value: "Charles" } });
  expect(component.find(NameRenderer).dive().find("#output").text()).toBe("Hello, Charles");
});

Let's check again with npm t...

✓ should render component
✓ should render default state
✓ should display name when user types into input field

Great, success! In this limited case, we have introduced a new component and tested that props are successfully passed to the component and rendered on the virtual dom.

Testing nested nodes in shallow should be avoided

Code: Stage 5 - Updating the enzyme tests.

We have a fundamental issue with our tests at this point, which breaks the concept of unit testing. Unit tests are intended to test indivdual units of source code with minimal integration where possible. In our example, we're testing our Name component, but also the integration to NameRenderer and that NameRenderer renders correctly!

Let's fix up that up, by creating a a test suite for NameRenderer and adjusting the unit tests in Name.

Let's create our nameRenderer.test.js file, with our fixtures set up:

// <root>/src/components/name/nameRenderer.test.js
import { NameRenderer } from "./nameRenderer";
import React from "react";
import { shallow } from "enzyme";

describe("Component: NameRenderer", () => {

  let component = null;

  beforeEach(() => {
    component = shallow(<NameRenderer />);
  })

  afterEach(() => {
    component = null;
  });

});

Even though our NameRenderer components takes a { name: string } prop, we haven't defined it here, because we can use the .setProps() utility function to update the value, and simulate the input value changing.

First, we'll remove the default value assertion from the name.test.js test suite, and create a new default value assertion in nameRenderer.test.js test suite, querying the element with the id #output:

// <root>/src/components/name/nameRenderer.test.js
it("should not render name", () => {
  expect(component.find("#output").text()).toBe("Hello, ");
});

To simulate input props on a component changing, we can use the setProps function, and pass through a new value for name. Let's add that to our test and validate the state of the component changes with the new value:

// <root>/src/components/name/nameRenderer.test.js
it("should render name from prop", () => {
  component.setProps({ name: "Charles" });
  expect(component.find("#output").text()).toBe("Hello, Charles");
});

Running our tests with npm t should give us 4 passing tests:

PASS  src/components/name/nameRenderer.test.js
  Component: NameRenderer
    ✓ should not render name
    ✓ should render name from prop

 PASS  src/components/name/name.test.js
  Component: Name
    ✓ should render component
    ✓ should display name when user types into input field

Great success, but we still have the lingering issue of testing the NameRenderer component in the name.test.js test suite. Lets update that now. We don't need to validate the text changing in the component, we just need to validate that the properties on the child component change.

We can do that by using the .props() utility function and validating the value of the props. When we use .props(), it returns an object key/value map of all the properties passed to the component. Thus, in our test, it returns { name: 'Charles' };

Lets update our test and assert with props:

// <root>/src/components/name/name.test.js
it("should display name when user types into input field", () => {
  component.find("input#name").simulate("change", { target: { value: "Charles" } });
  expect(component.find(NameRenderer).props()).toStrictEqual({name: "Charles"});
});

We've updated our test suites to remove duplicated test efforts, and we've create tests against our renderer component. Let's look at using mount to work with React hooks.

Testing hooks with `mount`

Code: Stage 6 - Testing hooks with mount.

Testing hooks in React can be done in multiple ways; using act() to perform synchronous updates to the dom for rendered elements with ReactDOM, use the hook testing functions from react-testing-library, or use mount() with enzyme. Let's look at how we do it with enzyme.

While there are limitations for what we can achieve for hook testing with shallow, those limitations don't exist with mount. But be aware that deferred and asynchronous actions do update the dom, and can report errors, and while you don't necessarily have to deal with asynchronous errors, you should handle them, as jest does not report failed async promises as errors, if you don't handle it correctly.

Let's create our component that will talk to the json placeholder api, and update the component when the asynchronous request from the useEffect hook is successful.

// <root>/src/components/todo/todo.js
import React, { useEffect, useState } from "react";

export const Todo = () => {
  const [todo, setTodo] = useState(undefined);
  useEffect(() => {
    fetch(`https://jsonplaceholder.typicode.com/todos/1`)
      .then(response => response.json())
      .then(json => setTodo(json));
  }, []);

  return todo 
    ? <div id="todo">{todo.id}: {todo.title}{todo.completed ? " [completed]" : null}</div>
    : <div id="todo">Loading...</div>;
}

Because we're using the browser built in fetch library, we're going to have to mock it. We won't initialise the component in our beforeEach because we need to wrap the asynchronous calls in act to ensure that the react lifecycle events and hooks are correctly called.

// <root>/src/components/todo/todo.test.js
let data = {
  "userId": 1,
  "id": 1,
  "title": "delectus aut autem",
  "completed": false
};

beforeEach(() => {
  global.fetch = jest.fn(() => Promise.resolve({
    status: 200,
    data,
    json: () => data
  }));
});

Whenever we test a mounted component, especially one with deferred and asynchronous actions that can update the UI, we need to wrap the test in act:

// <root>/src/components/todo/todo.test.js
import { act } from 'react-dom/test-utils';
...
await act(async () => {
  component = await mount(<Todo />);
});

Deferred actions within the act will be executed, and the UI will be updated, but there may be times when additional deferred and asynchronous actions are executed, and the component may need to be 'refreshed'. We can update the component using the .update() utility function.

// <root>/src/components/todo/todo.test.js
await act(async () => {
  component = await mount(<Todo />);
  component.update();
});

Let's put it all together now, adding tests to ensure the element exists, the element renders, and fetch is called with the todo api - you don't need to be connected to the internet for the tests to pass. As you can see below, our assertions are the same between shallow and mount, with the primary difference being that deferred and asynchronous actions are automatically called, along with other components rendering.

it("should render element 'todo'", async () => {
  await act(async () => {
    component = await mount(<Todo />);
  });
  expect(component.exists("#todo")).toBe(true);
});

it("should show todo once async resolves", async () => {
  await act(async () => {
    component = await mount(<Todo />);
    component.update();
  });
  expect(component.find("#todo").text()).toBe("1: delectus aut autem");
})

it("should call fetch", async () => {
  await act(async () => {
    component = await mount(<Todo />);
    component.update();
  });

  expect(global.fetch).toHaveBeenLastCalledWith("https://jsonplaceholder.typicode.com/todos/1");
})

When we run our npm t we should see green across the board:

 PASS  src/components/name/nameRenderer.test.js
  Component: NameRenderer
    ✓ should not render name
    ✓ should render name from prop

 PASS  src/components/name/name.test.js
  Component: Name
    ✓ should render component
    ✓ should display name when user types into input field

 PASS  src/components/todo/todo.test.js
  Component: Todo
    ✓ should render element 'todo'
    ✓ should show todo once async resolves
    ✓ should call fetch

Great success!

Summary

We've looked at use cases for shadow and mount, covered the differences between the two testing methods, and demonstrated the ability for mount to execute useEffect hooks, that update the UI.

Enzyme can do more a heck of a lot more than what we've covered. Its rich querying syntax allows for deep component comparison and testing, which far and away exceeds the what the next best tools can offer.

When used alongside jest, enzyme is a terrific tool that makes testing components a breeze, and takes the genuine pain out of the equation. When testing React-specific functionality (did useEffect get called? 🤔), just remember to test the outcome, not the React action itself.

What are side effects, and what you can do about them

Justin Mitchell — Fri, 25 Sep 2020 18:45:01 +0000

First published on thejs.dev → https://thejs.dev/jmitchell/what-are-side-effects-and-what-you-can-do-about-them-jws

What are side effects? It's one of those questions that gets frequently asked on Stack Overflow, around the
water cooler and in interviews, but what does it mean? How do you know if your code or function has a side effect?

You may have even come across the functional programming aficionado, who has claimed that no side effect code will
save the day, and it's what functional programming is the bees knees for. I'll let you in on a little known secret -
object-oriented programming can also be developed without side effects; the side effects advice applies equally to both
paradigms.

Functional programming has become hot topic in the JavaScript world, with large code bases making heavy use of
declarative paradigm ideas, while practitioners have campaigned for wider adoption.

Functional programming is the process of building applications, composing it primarily of pure functions, avoiding
shared state, mutations on data and side effects. It is declarative rather than
imperative, and application state flows from one function to the next.

tl;dr

Functional programming goes someway towards reducing the impact of side effects in code that follows an imperative
paradigm. Side effects are not only limited to state manipulation, interacting with the I/O, database, log system,
APIs and anything else that can be controlled, has a side effect.

Some side effects are beneficial, and desired, such as the setTimeout() function, equivalent to sleep() and wait()
in multi-threaded applications. Side effects aren't a bad thing, but when hidden, or not otherwise obvious what's
happening, they can be dangerous.

Functional programming is not the panacea, but it is a good option, and should be combined with good application design
and development practices.

Breaking it down

A side effect is the modification of state through the invocation of a function or expression. In order for a
function or expression to have a side effect, the state it modifies should be out of its local scope. Such as
passing an object by reference through functions to be mutated and performing I/O operations.

The presence of side effects in code is neither a good or bad thing. They are inevitable in some cases, such as when
working with languages that follow the imperative programming paradigm, or when mutating state through necessity.

In functional programming, functions are often designed to avoid side effects, with the result of most function calls
being a derived value from the input parameters. The lack of side effects makes it easier to do formal verifications,
and tends to lean towards an easier method of testing.

Shared state

A shared state is any kind of shared state, an object, variable or memory space, that exists in a shared scope, such
as closures, classes, functions and even global scopes, or as the input property being passed through functions.

The problem with shared state is by virtue its shared nature; you need to know the history of the object, shared
events and other potential points of mutation and interaction.

A common side effect of shared state are race conditions. For example, imagine you have a User object, with a
function saveUser(), which makes a request to an API. While that process is happening, the user modifies their
profile and saves their data again, thus calling saveUser() a second time. Unfortunately for the user, the second
request was received, processed, and their record updated before the first one completed.

When working with shared state, there are strategies to mitigate collisions, races and deadlocks.

Another problem with shared state is the cascading function problem, in which the order and even timing of function
calls has to be changed as the state changes. This is typically a side effect of changing the order of functions
calls, which causes a cascade of errors.

const state = {
  myVal: 1
};

const doSomething = () => state.myVal += 1;
const handleSomeEvent = () => state.myVal +=2;

doSomething(); // state.myVal = 2;
switch (state.myVal) {
  case 2:
    handleSomeEvent(); // state.myVal = 4;
    break;
}

console.log(state) // { myVal: 4 }

If we don't call doSomehing() before our switch statement, handleSomeEvent() doesn't even get called, and the
same thing happens when the invocation of doSomething() is shifted after the switch statement.

const state = {
  myVal: 1
};

const doSomething = () => state.myVal += 1;
const handleSomeEvent = () => state.myVal +=2;

switch (state.myVal) {
  case 2:
    handleSomeEvent(); // never gets called
    break;
}

doSomething(); // state.myVal = 2;

console.log(state) // { myVal: 2 }

Introducing pure functions following the functional programming paradigm helps us avoid shared state, thus avoiding
issues such as cascading function errors, potential race conditions, and situations where state is stale.

const state = {
  myVal: 1
}

const f = (state) => ({ ...state, ...{ myVal: state.myVal + 1}});
const g = (state) => ({ ...state, ...{ myVal: state.myVal + 2}});

const newState = f(state);
console.log(state); // { myVal: 1 }
console.log(newState); // { myVal: 2}

const finalState = g(f(state));
console.log(state); // { myVal: 1 }
console.log(finalState); // { myVal: 4 }

Check it out on codepen.

In the example above, using the object spread, we're able to copy the values of the input onto our output state,
while performing the mutations to the new object that we need, rather than mutating the values of state directly.
This is a common pattern in JavaScript for copying values in one object into another, such as setting default values.

The order of function calls still matter, as the result can change depending in which order you call the functions in.
The function composition (taking two functions to produce a single function) of f and g → f(g(x)) does not
always equal to composition of g(f(x)). In our example above it does, but what if g performs a multiplication
rather than an addition? f(g(x)) ≠ g(f(x)).

Immutability

An immutable object is an object that can't be modified after creation, through manipulation of a property, or
through assignment. A mutable object is an object which can be modified.

Immutability and data flow is a central concept in functional programming. In JavaScript, it's important not to
confuse the keyword const with immutability; const declares a variable that cannot be reassigned after it has
been created.

You can't create immutable objects in JavaScript by default. While const prevents value reassignments, you can
still change the properties and values of objects and arrays, assigned to const, let and var.

However, immutable objects can still be achieved in JavaScript by using the Object.freeze, which
prevents the modification of the object one-level deep, thus making it partially immutable.

const state = Object.freeze({
  myVal: 1
});

state.myVal = 2;
console.log(state.myVal); // 1

const myObj = Object.freeze({
  nested: { myVal: 1}
});

myObj.nested.myVal = 2;
console.log(myObj.nested.myVal); // 2

Frozen objects are only superficially frozen; to achieve immutable objects, you will need to deep-freeze the object,
by recursively calling Object.freeze over all properties in the object, from the deepest child and work your way up.

Thera are several libraries in JavaScript that provide trie data structure-like behaviour with immutable
stores, such as immutable.js and mori.

Idempotency - lets get mathematic!

Contrary to what some may suggest, a side effect isn't a bad thing. It does not have to be hidden or unexpected
behaviour. It also has nothing to do with idempotency in computer science - an idempotent function
can have side effects, while a non-idempotent function may have no side effects.

A function (or subroutine) is considered idempotent in computer science when:

In imperative programming, the system state remains the same after one or more invocations of a function (or subroutine) with side effects,
A pure function in functional programming,
A function is idempotent in the mathematical sense

A function f() with side effects is idempotent under sequential composition f; f if, when called n-times with the
same list of arguments, the nth call has no side effects, and returns the same value as the first invocation,
assuming no other procedures were called.

// Idempotent function
var x = 0;
function f(n) {
  x = n;
}

f(5); // x = 5
f(5); // x = 5
f(5); // x = 5

A typical example of an idempotent function, is a function that queries a database for a customer's name and address.

The influence of functional programming

There is a growing ground swell from functional programming enthusiasts, that advocate for less side effect
driven code. There could also be confusion between side effects and pure functions - a function that is
(a) idempotent, (b) has no side effects, and (c) will return the same output for the same parameters, every time.

// pure function
function f() {
  let x = 0;
  return ++x;
}

Although the code sample above does not look like it is pure, it actually is. The value of x can only be observed
in other invocations of f(), and f() does not communicate or cache the value of x to its environment.

A function is not pure and has no side effects, if the result of the invocation of the function is different
each time without modifying state.

// non-pure function  
function z() {
  let x = Math.random() * 100;
  return ++x;
}

A function is both not pure and has side effects if during the invocation, it modifies state. This can be state that
is passed to it as an input parameter, or state that it can access through its closure scope.

let counter = 1;
function increment() {
  ++counter;
}
increment(); // counter is now 2

let val = 2;
function square(x) {
  return x *= x;
}
square(2); // val = 4

While classes colocate functionality and bound together under the namespace of the object class, functional programming
tends to reuse a collection of functional utilities to process data.

Typically in functional programming, any type of data is fair game. For example, being able to use the map utility
function to map over objects, strings, arrays and other data types. This is achieved by using higher-order
functions, which is a function that takes a function as an argument, returns a function, or both.

JavaScript has first class functions, which allows us to treat functions as data and assign them to variables,
pass them as arguments, return them from other function calls, etc.

So it's not all bad?

So far we've covered what happens when a function assigns a new value to a variable, or looks like a pure function,
but may not be one. Other side effects can happen when a function call invokes another function.

In multi-threaded applications, pausing a thread is a side effect. The state of the application has been modified in
some way, and in some cases functions like sleep() or wait() are only useful for their side effects.

The term side effect may sound negative, but normally effect of calling a function is the very purpose of the
function itself. In some way there is a side effect, be it memory or cpu utilisation, storing data to a database,
creating a system log, communicating with a message bus server, etc.

In mathematics, the function is a mapping from a tuple of values (input) to a single value (output). So, given
function f and a value x, f(x) will always yield the same result y. This is the basis of the pure function,
but is often different to what the concept of a function (procedure) is in many programming languages, which is more
of a construct.

Given the mathematical nature of what a function is, and how that differs in programming languages, there's bound to
be side effects in the invocation of any function, just that most of those are abstracted away from us, so that we
don't know about it.

Conclusion

There are instances though when following the declarative programming paradigm, that creating pure functions is a
cleaner, safer and an easier way to develop. JavaScript has made great strides towards incorporating functional
programming ideas into many of its languages features since ES2015, such as with the Array.* functions.

The negative aspect of side effects normally comes from cases where side effects are hidden or unknown. This is bad
programming in the first place and should be avoided at all costs. Any code that produces a side effect should make
it clear that it is doing so. Even Haskell, one of the most popular functional programming languages, still allowed
I/O operations.

Statelessness is one approach to avoiding side effects, but that only takes into considering that state is cached and
stored inside the application. Often this isn't the case, such as with RESTful APIs, or Web UIs that don't cache data
locally.

In general, most applications will combined the declarative and imperative programming paradigms. There's a fine
balancing act between the declarative (what do to) and imperative (how to do) paradigms, with more a shift in the
community towards declarative programming.

Practicing good software design principles, adopting declarative coding paradigm where necessary, and utilising
immutable objects is a solid step in the right direction.

What is hoisting and how it works in JavaScript

Justin Mitchell — Fri, 25 Sep 2020 09:51:42 +0000

First published on thejs.dev → https://thejs.dev/jmitchell/what-is-hoisting-and-how-it-works-in-javascript-e1e

The famed and often confusing term, certainly for any JavaScript developer, and it leaves many scratching their heads; what exactly is hoisting?

Hoisting is a term that describes a mechanism in JavaScript to provide early-access to declarations.

Hoisting is a JavaScript mechanism where variables and function declarations are moved to the top of their scope before code execution.

Ever wondered why in JavaScript you can interact with your variables and functions before they've been declared? Then read on!

tl;dr

Conceptually speaking, hoisting is the movement of declaractions - variables and functions - to the top of their scope, while assignments are left in place. What really happens, is that during compile time, the declarations are put into memory first, but physically remain in place in your code.

The benefit of doing this is that you get access to functions and variables before they're declared in code. This only applies to declarations, not to expressions, and not to initializing an undeclared variable.

foo("bar");
function foo(bar) {
  // do something
}

It's important to remember that only declarations are hoisted into memory during compile time, not assignments.

Only declarations are hoisted

JavaScript only hoists the declarations of functions and variables into memory during compile time, not the assignments. This means that if a variable is declared and initialized after using it, the value will be undefined.

console.log(foo) // prints 'undefined' as only the _declaration_ was hoisted
var foo; // declaration
foo = "bar"; // initialization

The following is an example of initialization returning a ReferenceError. In this case, a variable is only initialized, not declared; in order to declare something to be hoisted in JavaScript, it must either be explicitly declared as a var or function, as implicit declaractions (initialization only) wont be hoisted.

console.log(foo); // prints 'ReferenceError: foo is not defined'
foo = "bar"; // only initialization, no declaration, value did not follow var

It's important to remember that only the declaration is hoisted, even if a value is assigned.

console.log(foo); // prints 'undefined'
var foo = "bar";

Hoisting variables

JavaScript allows us to declare and initialize our variables simultaneously. However, the engine separates the declaration and initialization of variables, and executes it as separate steps, thus allowing the engine to hoist declarations above initializations.

All function and variable declarations are hoisted to the top of their scope, while variable declarations are processed ahead of function declarations; which is why you can call functions with yet-to-be-declared variables, and get an undefined error.

However, there is a caveat. When initializing a variable, that hasn't yet been declared yet, the variable is hoisted to the global scope when it is executed, rather than hoisted to its scope, like the function it's being initialized in. This only happens on execution, not at compile time.

function doSomething() {
  doing = "something";
}

console.log(doing); // ReferenceError: doing is not defined
doSomething();
console.log(doing); // something

This is distinctly different to scoped variable declarations, which only exist within their scope.

function doSomething() {
  var doing = "something";
}

console.log(doing); // ReferenceError: doing is not defined
doSomething();
console.log(doing); // ReferenceError: doing is not defined

The take-away is, that declared variables are hoisted to the top of their scope at compiled time, while undeclared variables are hoised to the global scope during execution.

Declarations using `let` and `const` are not hoisted to global space

let and const were introduced in ES6 for scope-based operations, but unlike var, do not get hoisted to global space during compile time. Variables declared with let are block scoped and not function scoped. This is significant, because unlike var, there's no risk of variable leakage outside of the scope of execution.

The downside is that const and let do not get hoisted, in local or global scope. Read more about var, const and let.

console.log(foo); // prints 'ReferenceError: foo is not defined'
const foo = "bar";

console.log(bar); // prints 'ReferenceError: bar is not defined'
let bar = "bar";

Strict mode prevents sloppy hoisting

Introduced as a utility in ES5, strict-mode is a way to opt in to a restricted variant of JavaScript, implicitly opting-out of sloppy mode. It introduces different semantics, such as eliminating some silent errors, improves some optimizations and prohibits some syntax, such as accessing variables before they've been declared.

You can opt-in to strict-mode by pre-facing your file, or function with use strict at the top of the scope, before any code is declared:

'use strict';
// or
"use strict";

We can test if we can access initializations ahead of time with strict-mode enabled:

"use strict";
function doSomething() {
  foo = 20;
}
doSomething();
console.log(foo); // prints 'ReferenceError: foo is not defined'

Not all functions are hoisted alike

Function are classified as either function declarations, or function expressions. The important difference between the two, when discussing hoisting, is declaration. A declared function will be hoisted, while a function created through an expression will not be hoisted.

console.log(typeof hoistedFunction); // prints 'function'
console.log(typeof unhoistedFunction); // prints 'undefined'

function hoistedFunction() {
  // This function _will_ hoisted, because it is *declared* as a function
}

var unhoistedFunction = function() {
  // This function _will not_ be hoisted because it is declared through an expression of a variable, and therefore will be undefined 
}

Order or hoisting precedence

There are two rules you have to keep in mind when working with hoisted functions and variables:

Function declaration takes precedence over variable declarations
Variable assignment takes precedence over expression function

console.log(typeof myVar); // prints 'undefined'
console.log(typeof myFunc); // prints 'function'
var myVar = "foo"; // declaration and initialization
function myFunc(){} // declaration
console.log(typeof myVar); // prints 'string'

We can take a deeper look at the steps during the compilation and execution cycle to see what's happening with our declaration and initializations:

function myFunc(){...}
var myVar;
console.log(typeof myVar);
console.log(typeof myFunc);
myVar = "foo";
console.log(typeof myVar);

Classes are not hoisted

Classes in JavaScript are in fact special functions, and just as you can define functions with declaration and expression, the class syntax has the same two components: class expressions and class declarations.

Unlike functions and variables, classes do not get hoisted, either through declaration or expression. You need to declare your class before you can use it.

const p = new Rectangle(); // ReferenceError
console.log(typeof Rectangle); // ReferenceError

class Rectangle {}

Conclusion

Let's summarise what we've learned:

Hoisting is a mechanism that inserts variable and function declaractions into memory ahead of assignment and initialization within the given scope of execution
const, let, function expressions and classes do not get hoisted, and cannot be read or accessed before their declaration
safe-mode prevents sloppy hoisting of initialized undeclared variables onto the global scope

To avoid hoisting confusion and issues in the longterm, it's better to declare your variables and functions ahead of initialization and access. You'll avoid a whole set of potentially nasty bugs and undefined warnings polluting your console.

const, let, var; JavaScript variables and immutability

Justin Mitchell — Sat, 01 Aug 2020 08:28:22 +0000

Originally published → https://thejs.dev/jmitchell/const-let-var-javascript-variables-and-immutability-a6c

The release of ES2015 in 2015 introduced two new keywords, let and const, which are important block-scoped variables in JavaScript. Until that point, for close to two decades, a variable was declared in JavaScript by using the var keyword.

var message = "Hello, world!"

So, what's the difference?

The three keywords together provide the same fundamental functionality, but differ in the way that they provide it. var and let are reassignable values, while const has limited mutability.

var and let can be reassigned - which is the act of setting a value at one point in time, and then using the same variable reference and giving it a new value.

var fruit = "Apple";
// ... do something
if (foo === 1) {
  fruit = "Orange";
}

The same can be achieved with let:

let fruit = "Apple";
// ... do something
if (foo === 1) {
  fruit = "Orange";
}

However, const does not allow reassignment of the reference, nor does it allow the mutation of a primitive. A primitive is a one of six types; a string, boolean, number, bigint, undefined and symbol, while null is a special type of object.

All primitives are immutable, meaning that their values cannot be changed, but they can be assigned a new value. This is different to stricter and strongly typed languages, where a primitive can mutable because of the way the language works.

Variable mutation through reassignment:

const foo = "Bar";
foo = "something else";

You can however, mutate an object that declared as a const:

const foo = [];
foo.push("Apple");
foo.push("Orange");
// Foo is now [ "Apple", "Orange" ]

What you can't do, is set a new value on a previously declared const by reassignment:

const foo = [];
const bar = {};
foo = bar;
// Uncaught TypeError: Assignment to constant variable.

Why you shouldn't use `var`

let, var and const behave in the same way in scope, other than the limited mutability for const. It is recommended however, to make it clear as to behaviour and treatment of a given property and its value, that you declare mutable variables as let and immutable variables as const.

var can still be used, but the treatment around var is far more flexible than let. For example, using a var, you can do this:

var x = "1";
var x = "2";
// x will have value of "2"

Doing the same with let will throw an error, indicating the the variable has already been declared within the scope of execution

var x = "1";
var x = "2";
// Uncaught SyntaxError: Identifier 'x' has already been declared

What's the difference with variable scope?

var is a tricky one to deal with, because even with block-scoped execution, that is an if-else statement, a while loop, or anything executed between curly braces {}, var doesn't adhere to expected declaration rules, which is that anything declared in a scope, lives in that scope.

For example, this is possible, because when a var is declared outside of a function scope, it will mutate the parent scope, which in a lot of cases, is the window:

if (true) {
  var t = "foo";
}

console.log(window.t);
// Prints "foo" to the console

By using var inside of a function, the declaration is block limited:

function foo() {
  var fooT = "foo";
}

foo();
console.log(window.fooT);
// prints "undefined" to the console

This is where let and const come in, because they are correctly block scoped, thereby adhering to the rules of declaration within a function scope, conditional block scope or loop scope.

Importantly, they also don't modify the parent scope:

let fooBar = "foo";
console.log(window.fooBar);
// prints "undefined" to the console

What about using `var` or `let` in a for loop?

There are multiple ways to iterate through a collection of objects in JavaScript, with while and for being to primary ways.

Below are several ways to iterate through an array collection using for

// for: i is the index
for (let i = 0; i < collection.length; i++) { collection[i] }
// for...in: x is the index
for (let x in collection) { collection[x] }
// for...of: x is the value
for (let x of collection) { x }

The benefit of using let in a loop, is that let is block-scoped to the loop itself. That is to say, that you cannot consume the declaration of let outside of the block that it is declared in.

// Using let
const collection = [ "apple", "orange" ];
for (let fruit of collection) {
  console.log("I like to eat 1 " + fruit);
}
console.log(fruit);
// Uncaught ReferenceError: fruit is not defined

However, when using var, you can still access the fruit variable:

// Using let
const collection = [ "apple", "orange" ];
for (var fruit of collection) {
  console.log("I like to eat 1 " + fruit);
}
console.log(fruit);
// prints "orange" to the console

There are ways around this, such as dropping the declaration of var inside block scopes, but this opens up another entire can of worms with readability, consistency and correct block scoping.

The bigger issue at hand, is that even when dropping var, let or const in a loop, the variable is automatically declared as a var:

const collection = [ "apple", "orange" ];
for (var fruit of collection) {
  console.log("I like to eat 1 " + fruit);
}
console.log(fruit);
// prints "orange" to the console

I sort of understood some of those words...

To clarify the meaning of some of the words and terms used:

mutate is to change, or modify a variable or property of an object, eg let foo = 1; foo = 2;
assignment is to set a value to a variable eg let foo = 1;
iterate is to traverse, or navigate from top-to-bottom (left to right) of an array or collection, starting with the first element and ending in the last element
collection is a structured object that has n elements, eg 1 or more elements, eg. const foo = [ "apple", "orange" ];

The five expertise levels of a software developer; the road to zen master

Justin Mitchell — Sat, 01 Aug 2020 03:38:17 +0000

Originally published → https://thejs.dev/jmitchell/the-file-expertise-levels-of-a-software-developer-the-road-to-zen-master-9e7

Software development is a career path that many of us take. We've all had to start somewhere, and for the vast majority of us, it's at the bottom. A few have lucked out, started their own businesses and careers, completely avoiding the need to grind away from day one.

It's rare though, that even for the lucky few, that a software developer will skip through the five major milestones of personal and career development, as they grind day-to-day towards the highest level they can achieve.

For those of you wondering where you stand, or even at the start of the road and you want to understand your career path, these are the five levels of expertise and seniority in software development.

The five levels of expertise

A software developers career ladder typically consists of three rungs; junior, mid-level and senior. The industry applies this scale for a number of reasons - to better understand and assign a degree of qualification, remuneration, expected expertise, as well as responsibilities.

As you move through the levels from junior to senior, an employers' expectations of your skill, expertise, problem solving ability, research and responsibilities, including leadership and mentorship will increase, and thus your remuneration to reflect your status.

While these levels are typically used by recruiters and companies to assign you to a bracket from which to ascertain your suitability for a given role, it is restrictive in the way that it can describe your relevant experience.

That brings us to the two missing levels - trainee and leader. Both levels fit in the existing seniority paradigm, trainee to junior, and leader to senior.

Source: altexsoft.com

Trainee developer

The trainee is an individual who's often learning about their role, and gaining practical experience in a workplace. A trainee is someone that's discovering what it means to practice software development for the first time in an industry environment, as part of their studies, or as pathway into the company of their choice.

A lot of large employers offer traineeships, in-business learning (IBL) opportunities and graduate pathways, IBM notably as an international employer.

The expectations for a trainee differ depending on the employer, but typically they will be looking for someone with some knowledge of software development, or a passion and desire to learn.

It's this formative stage where you decide if software development is for you, and if you have the passion and skill to make it your career.

Initially, trainees will have little to no exposure to real development, but will make steps towards coding in a professional way, eventually having the minimal level of skill and knowledge to tackle a real project.

Junior developer

Junior developers and trainees are often interchangeable, and in a lot of cases, blended into the same role. It can be difficult getting a job as a junior, because they often come and go, and employers tend to hire juniors as contractors, with an eye to cut long-term costs.

Nevertheless, a good junior is worth their weight in gold, because it's often at this stage, once you've had your first real taste of working on project, that you bring vigor, passion, motivation and energy. These are a junior's real strengths.

However, juniors are often impatient and want immediate results for their efforts, often lacking consideration of context, or taking shortcuts to achieve results. This often leads to junior burnout, where a junior places a much higher expectation on themselves, and an employer reciprocating.

It's important that a junior is closely supervised, because they need their passion and energy properly channeled, and they should be exposed to as much technology, practices and ideas as possible, to help build their career.

At this level, you're not expected to be an expert in a domain, or know a lot of different technologies, ideas, or approaches. You've typically come from further education, such as college or university, and you may have some practical experience working in a real-world environment, through placement, work experience, or traineeships.

It's vitally important to remember that this is the level where you will be learning a lot more than practicing.

Mid-level developer

Typically junior developers with 2-3 years can leverage their skills and experience and become the mid-level specialist, often referred to as the "workhorses of the programming world".

The mid-level stage is reached when you have the experience, knowledge and skill to execute projects on your own, but should still be done under limited supervision. This is also a stage when you can start to assume leadership responsibilities, typically through mentoring junior developers.

Competent developers are highly resourceful and display initiative in spades, but often need guidance to properly focus and channel their energy, as they often lack the experience to do so themselves, and struggle to reflect on their own mistakes.

At this point, it's expected that you know one programming language very well, while not quite fluent, you can certainly start your own project. However, competent developers often want to prove their worth and this is often where teamwork and focus can lag.

It's important that a mid-level developer's focus is guided. If you can harness the passion, drive and motivation of a mid-level developer, they'll fast become one of the most important resources in your team.

Source: altexsoft.com

A lot of mid-level developers fall under the Dunning-Kruger effect, which hampers further career growth. It's a phenomenon that describes how dangerous a little knowledge can be. Being self-assured, developers at this level can often overestimate their skills which hampers their development, and impedes their development.

This cognitive bias is not just limited to mid-level developers, all seniority levels experience it, it's just that mid-level developers are more susceptible to it.

It's only once you realize that there's still so much more to learn that you can transition to the next level. Proving that you're beyond this bias is as simple as broadening your knowledge, by proving that you can not only acquire new knowledge, but put it to practice as well.

Senior developer

Senior developers are often referred to as problem solvers, because of their deep, specialized knowledge and exhaustive experience. They're often knowledgeable in the business domain that they support, which that allows them effectively transition between projects and products.

A senior will always consider what they're doing in the context of their domain, and what benefits or gains it can bring to the business. The real benefit of a senior is their ability to foresee issues ahead of time, design around them, or resolve it before it happens.

This is often from a combination of experience, intuition, deep domain understanding and leveraging the knowledge and experience of their team and other domain experts.

When leading a project, a senior will often make decisions based on best standards and practices in their field, as well as what is acceptable and likely to produce the best outcome for their team, and their teams' relative skill level.

There are several levels of seniority for senior developers. Those that transition from mid-level to seniors are junior seniors, those with significant experience and expertise are known as the expert, and then there's the leader.

A junior senior is a proficient and highly skilled developer, who made a major breakthrough; they are able to reflect on their work performance, analyze mistakes and learn from them. Their ability to reflect, learn and adjust is an approach at the core of agile project management, and vitally important on career development.

It's at this point that one should seek out opportunities for leadership, to hone their soft skills and develop skills for the next stage of their career that they may not have yet learned.

The expert is a level of seniority that is achieved through roughly 10 years of hard, determined practice. They will often draw on their vast experience and knowledge across a number (often all) domains, technologies and experiences.

It's at this point that their intuition is often their best asset, alongside their ability to problem solve and foresee issues. They are an adept practitioner and a good instructor, that has a profound methodological foundation.

Leader

The senior level is often the final rung on the ladder for a lot of developers, but is also the first rung for a whole slew of opportunities in the business world. It's a great point to jump off and start something else, that focuses more on the soft skills, than being focused almost purely on technical work.

While leadership should normally be reached from a senior level, because it provides the foundations of the necessary soft skills that are required, it can be shortcut from lower levels on the seniority ladder.

It's important that a leader should still be involved in the tools of their own trade, while focusing on the soft-skills that they have acquired, or are acquiring at this level.

Example roles:

DEV Community: Justin Mitchell

The keys to interview success - landing that dream job

1. Dress for success, but let's not get stuffy about it!

2. Your resume must make a statement

3. Soft skills are more important than technical skills

4. Open source is great, but not it's not the silver bullet

5. Practice and train your brain, so that it's not a drain

6. It's OK to say you don't remember, don't know, or don't have experience with

7. Don't lie on the resume

Conclusion

Less is more; simplify your React code to super power your applications - part 3

Simplify a React component

Avoid overloading useEffect and useState

The useState hook, how and when to use it

Setting useState with initial data from callable function

Lazy loading state with useEffect

Observable updates with useState and useEffect

Custom hooks

Context API

When to consume useEffect and when to consume useLayoutEffect

Less is more; simplify your React code to super power your applications - part 2

Simplify a React component

Defer processing to services and custom hooks

Less is more; simplify your React code to super power your applications - part 1

Simplify a React component

1. Separate state from display, this will help your application align with well established MVC rules

It's time to let go of lodash

Do we need lodash?

Tuning your build to reduce lodash bloat

Summary

Code coverage testing, when enough is enough

What's the difference between white box and black box testing?

Unit tests and code coverage

Limitations on code coverage

Ok, so what's wrong about coverage testing?

Ways to improve code coverage

Optional chaining

Nested ternary operators

Testing private/protected methods

Refactoring

Conclusion

Managing your ReactJS application state with RxJS

What about using React to manage our state?

Why use Redux or MobX?

Is RxJS a viable option?

Conclusion

How to get started writing unit tests for React with jest and enzyme

React and jest

Where enzyme fits in

Getting started

Installing enzyme

Configuring the adapter

Adding to jest

Crash course on enzyme

Shallow rendering with shallow()

Full DOM rendering with mount()

Static rendering a component with render()

React hooks support

Writing enzyme tests

Writing our first test

Asserting default states

Asserting name is displayed after entry

Shallow rendering with children components

Testing nested nodes in shallow should be avoided

Testing hooks with mount

Summary

What are side effects, and what you can do about them

tl;dr

Breaking it down

Shared state

Immutability

Idempotency - lets get mathematic!

The influence of functional programming

So it's not all bad?

Conclusion

What is hoisting and how it works in JavaScript

tl;dr

Only declarations are hoisted

Hoisting variables

Declarations using let and const are not hoisted to global space

Avoid overloading `useEffect` and `useState`

The `useState` hook, how and when to use it

Lazy loading state with `useEffect`

Observable updates with `useState` and `useEffect`

When to consume `useEffect` and when to consume `useLayoutEffect`

Shallow rendering with `shallow()`

Full DOM rendering with `mount()`

Static rendering a component with `render()`

Testing hooks with `mount`

Declarations using `let` and `const` are not hoisted to global space

Why you shouldn't use `var`

What about using `var` or `let` in a for loop?