DEV Community: Milosz Piechocki

12 Tips on Becoming a Senior Frontend Engineer

Milosz Piechocki — Sat, 29 Jan 2022 18:08:19 +0000

Have you ever wondered why the market for software engineers is so hot despite the increasing number of people learning how to code and increasing the pool of available engineers? The answer lies in the fact that while the number of engineers increases, the number of truly senior engineers is rather small. There is much more to being senior than just writing great code. Read this article to learn about things that you can start doing to grow into seniority.

The advice in this article is mostly applicable to tech companies (especially Sillicon Valley-like companies) but some of the ideas might also work in more traditional companies.

Career Path of a Frontend Engineer

The career path of a Frontend Engineer is not very different from one of a backend engineer. It usually starts with the (Junior) Software Engineer level, followed by Senior Software Engineer. At this point, you decide whether you prefer to stay on the Individual Contributor path and become a Staff or Principal Engineer or switch to engineering management.

Overall, the more senior you are, the more you are expected to solve problems beyond writing code. What's more, you should also be able to identify problems, propose solutions, and make sure they're solved. Another crucial aspect of seniority is visibility - in order to get promoted, you should make sure that people are familiar with and value your work. You won't accomplish this just by solving the tasks that your manager assigns to you.

The subsequent paragraphs list a few ideas on improving your visibility and demonstrating seniority. I divided them into three areas: technical expertise, product/UX, and leadership. You should pick one of these areas and specialize in it. However, it usually makes sense to invest a bit in the remaining two areas as well.

Technical Expertise

Idea #1: Volunteer as a Technical Lead for a new Feature/Project

Technical Lead is not just an excellent programmer but can also lead a project end-to-end. That involves smooth communication with the stakeholders (including the Product Manager) to gather the requirements, breaking down the work into smaller tasks, proposing architecture design and discussing it with the team, coordinating the implementation (if more devs are involved), and finally, rolling out the new feature/project.

Idea #2: Improve Developer Experience

Who's the best person to improve Developer Experience if not the developers themselves? Being challenged by problems such as long builds or unstable tests every day, you know exactly how great an impact they have on developer productivity. It may sometimes be tricky to get your manager to prioritize such work. When selling your ideas to the leadership, try to quantify the productivity loss (e.g., days of developer's time lost on waiting for the build to finish per month) and mention specific metrics that you want to improve (e.g., average build time).

Idea #3: Start Monitoring UI Performance

Nowadays, UI performance is crucial to a great user experience. In some business domains, metrics such as page load time can have a direct impact on the sales of your company's product. If your company is not doing it yet, championing UI performance monitoring is a great way to increase your impact on the whole organization.

Identify the key metrics that you want to track (e.g., FCP, TTI, or long tasks during interactions), start measuring them, and set up notifications for them. Present the monitoring framework to the leadership and explain how these metrics affect your company's business. An example of 3rd part software that can help you achieve that is Sumo Logic's Real User Monitoring (disclaimer: I work at Sumo Logic).

Idea #4: Remove Some Legacy Code

While the JavaScript framework landscape is becoming increasingly stable, many codebases went through one or two transitions in the past and still contain some traces of legacy frameworks (such as AngularJS). Such code is often a ticking bomb that nobody wants to approach. Coming up with a vision and strategy for the gradual removal of legacy code and selling the idea to the leadership is another great way of making a huge impact.

Influencing Product and User Experience

Idea #5: Brainstorm some Product Ideas and Discuss with a PM

Working on the frontend brings you very close to the product. As a by-product of developing the UI, you're constantly interacting with the product. It makes you a great source of ideas. Maintain a backlog of ideas and periodically discuss them with your PM. Focus on low-effort ideas instead of grand multiquarter projects - it would be much easier to convince your PM to put them on the roadmap. Bring some data points to back your ideas - user requests, usage statistics, etc.

Idea #6: Brainstorm some Usability Quick Wins and Discuss with a UX Designer

If you feel strongly about a good User Experience, you may be better equipped to focus on usability improvements instead of new features. Feel free to interview a few users of your company's software - it's especially relevant when the company has a strong dogfooding culture. Create a list of UX improvements that would address the biggest pain points and partner up with a UX Designer to propose solutions for them.

Idea #7: Instrument the code and provide your PM with some business metrics

Having a good understanding of how your product is being used is critical to making good product decisions. You can greatly help your PM by gathering and presenting such data. Similar to how you can use Real User Monitoring to measure UI performance, you can leverage it to collect user behavior metrics. Examples of such metrics include: the number of visits to a specific route, time spent on a specific route, number of clicks on a specific button, etc. With tools such us Sumo Logic you can later create dashboards and reports with the data you collected.

Leadership

Idea #8: Lead (one of the) Team Meetings

This is a no-brainer. By volunteering to lead team meetings, you showcase and develop skills such as organization, mediation, and keeping everyone engaged. Don't hesitate to ask your Engineering Manager to lead one of the meetings - they'd gladly shed the responsibility. Be sure to prepare for the meeting in advance. Create an agenda and share it with everyone beforehand. Make sure that you stick to the schedule and cut lengthy discussions short. Collect notes and action items and send out the note after the meeting.

Idea #9: Triage Incoming Bugs

One of the areas that often consume a lot of the Engineering Manager's time and attention is handling all the incoming bugs and urgent requests. By taking over this responsibility, you will get better at managing chaos. You'll learn how to better assess the real priority of an ask and to push back on the ones that are not urgent. Start small - talk to your Engineering Manager and ask for a trial period where he'd review your choices on a daily basis. Gradually, you'll both realize that less and less supervision is needed.

Idea #10: Identify and Follow-up and Project Dependencies

Another part of the Engineering Manager's job that you can greatly help with is nudging the owners of the dependencies of the projects your team is working on. The dependencies can include UX designs, new API (or modifications to an existing API), security review, or gathering requirements from all stakeholders. Firstly, it's important to identify the dependencies early so that other teams can plan the work in advance. Secondly, you should actively monitor progress to make sure that when you start working on the implementation, you won't get blocked on some missing pieces.

Idea #11: Propose a Process Improvement

While process may sound scary to you, it's just a name for a set of instructions that will tell everyone how to behave in a certain situation. It's like programming, but with people instead of code :) Processes make the team better organized, help build good practices and reduce ambiguity. You can propose a process for virtually anything: adding a new code dependency to the repository, handling customer escalations, onboarding a new team member, adding a new module in the repository. Create a document with a process description and share it with your colleagues so that they can provide their inputs. Design the process in a way in which it is easily enforceable. Once introduced, monitor whether the process is working as designed and search for a room for improvement.

Idea #12: Mentor a Junior Team Member

One of the most obvious responsibilities of a Senior Engineer is being able to grow the ones that you're working with. Set up a 1-1 with another team member. Discuss their current challenges and where they'd like to be in a year from now. Brainstorm together on how they can get there. Make sure that the work they're doing is visible to your Engineering Manager.

Non-tech Companies

As mentioned in the beginning, these ideas assume that you are working at a tech company. At such companies, developers usually have a lot of autonomy and are expected to make impact beyond writing code. You may encounter pushback when trying to implement some of these ideas in a traditional company where structures are more hierarchical and responsibilities are assigned to specific roles in a stricter way. However, don't be discouraged. I managed to do a lot of these things as an Architect in a traditional company. Sometimes, it just takes a bit of convincing.

Summary

In this article, we discussed what it means to be a Senior Frontend Engineer. I mentioned three different areas where you can demonstrate your seniority and listed a few ideas in each category. Hopefully, you'll find them useful! Importantly, most of these ideas will not only increase your chances of promotion but will also help you develop new skills. Let me know if you tried any of them and how they worked.

TypeScript - Engineering Manager's perspective

Milosz Piechocki — Wed, 04 Nov 2020 21:48:07 +0000

As a Software Engineer I used to put a lot of focus on making sure that my TypeScript code is typed correctly. Actually, I deemed it to be the key code quality metric. I trusted static typing a lot, believing that the effort invested in figuring out the types pays off many times over. Now that I'm an Engineering Manager, has my perspective changed? Do I still find static typing so important?

It's been a long time since I wrote on this blog. One of the reasons is my transition to an Engineering Manager role which happened about half a year ago. It's been an interesting time, which certainly changed a lot in how I approach software development. In this article, I'd like to focus on how my approach to TypeScript changed during that time.

Being an Engineering Manager at the company I work in encompasses multiple responsibilities such as planning, coordinating with Product Manager and User Experience folks, taking major technical decisions, helping a Team member grow, etc. It's a breadth-first role, as opposed to Software Engineer, which is a depth-first role. The natural consequence of this is that I have less time to focus on the technical aspects, such as static typing.

What's more, as an EM I have to constantly balance how much effort is spent on the product backlog versus technical debt. I realized that even in a company with a strong engineering culture, prioritizing the tech debt is tricky. There is always a lot of things to fix: increasing test coverage, fixing performance, refactoring the code after bad design choices. Improving static typing competes with a lot of other items and sometimes compromises have to be made. As a result, I'm now definitely more cautious when evaluating when it's worth spending a lot of time on improving typing in an area of code.

On the other hand, as an EM I get more visibility into how static typing affects the Team's performance. And I can confirm that the majority of my SWE-era hypothesis about static typing was correct. My Team works with different parts of the product and we have to deal with noticeably more bugs in the areas that are poorly typed. What's more, poorly typed code is far less readable and more error-prone. I get regular complaints from the Team when they have to deal with such code. Also, onboarding new Team members is far easier when the code is typed correctly.

One immensely helpful thing is building a Team culture that values static typing. Folks on my Team put a lot of focus on this when reviewing the code, always asking why someone typed some variable as any (and they better had a really good reason) and suggesting more precise types whenever possible. This allows the team to minimize the tech debt created around static typing so that there's less to clean up later.

Wrapping up, my perspective on static typing has certainly changed. I became more pragmatic about it, always evaluating the effort vs the benefit of complex type refactorings. However, fundamentally, I still believe in the importance of static typing and I would never encourage poor typing. Being an Engineering Manager allowed me to see the benefits of static typing at scale.

The ultimate explanation of TypeScript generics: functions

Milosz Piechocki — Tue, 22 Oct 2019 20:02:55 +0000

Originally posted on codewithstyle.info.

Recently I surveyed the readers of this blog to find out what TypeScript features people find difficult to understand. Generics were mentioned quite often. In this article, I'm going to equip you with a mental model that will let you understand generic functions properly (I'll focus on generic types in another article).

The concept of generics is not a very new one - it has been present in different programming languages (such as Java, C# or C++) for a long time. However, for folks without background in a statically typed language, generics might appear complicated. Therefore, I'm not going to make any assumptions and will explain generics completely from scratch.

Motivation

Let's say you are adding types to some JavaScript codebase and you encounter this function:

function getNames(persons) {
  const results = [];
  for (let person of persons) {
    results.push(person.name);
  }
  return results;
}

Typing this function is straightforward. It accepts an array of person objects as a parameter and returns an array of names (strings). For the person object, you can either create a Person interface or use one that you've already created.

interface Person {
  name: string;
  age: number;
}

function getNames(persons: Person[]): string[] {
  /* ... */
}

Next, you notice that you don't actually need this function. Instead, you can use the built-in Array.map method.

const persons: Person[] = [
  /* ... */
];
const names = persons.map(person => person.name);

Hmm, but what about types? You check the type of names and realize that it has been correctly inferred to string[]! How does TypeScript achieve such an effect?

To properly understand this, let's try to type the following implementation of map function.

function map(items, mappingFunction) {
  const results = [];
  for (let item of items) {
    results.push(mappingFunction(item));
  }
  return results;
}

const names = map(persons, person => person.name);

The main issue with typing map is that you don't know anything about the type of the elements of the array it will be called with. What makes map so cool is that it works with any kind of array!

// Works with array of Persons
const names = map(persons, person => person.name);
// Works with array of names too
const uppercaseNames = map(names, name => name.toUpperCase());
// Works even with an array of numbers!
const evenNumbers = map([1, 2, 3, 4, 5], n => n * 2);

Let's use `any`!

As a first step, let's try using any type to map this function.

function map(items: any[], mappingFunction: (item: any) => any): any[] {
  /* ... */
}

Let's break this down. map has two parameters. The type of the first one (items) is any[]. We tell the type system that we want items to be an array, but we don't care about the type of those items. The type of the second parameter (mappingFunction) is a function that takes any and returns any. Finally, the return type is again any[] - an array of anything.

Did we gain anything by doing this? Sure! TypeScript now won't allow us to call map with some nonsensical arguments:

// 🔴 Error: 'hello' is not an array
map("hello", (person: Person) => person.name);
// 🔴 Error: 1000 is not a function
map(persons, 1000);

Unfortunately, the types we provided are not precise enough. The purpose of TypeScript is to catch possible runtime errors earlier, at compile-time. However, the following calls won't give any compile errors.

// The second argument is a function that only works on numbers, not on `Person` objects.
// This would result in a runtime error.
map(persons, n => n + 5);
// We tell TypeScript that `numbers` is an array of strings while in fact it will be an array of numbers.
// The second line results in a runtime error.
const names: string[] = map(persons, person => person.age);
names[0].toLowerCase();

How can we improve the typing of map so that above examples would result in a compile-time error? Enter generics.

Generic functions

Generic function is (in this case) a way of saying "this function works with any kind of array" and maintaining type safety at the same time.

function map<TElement, TResult>(
  items: TElement[],
  mappingFunction: (item: TElement) => TResult
): TResult[] {
  /* ... */
}

We replaced any with TElement and TResult type parameters. Type parameters are like named anys. Typing items as TElement[] still means that it is an array of anything. However, because it's named, it lets us establish relationships between types of function parameters and the return type.

Here, we've just expressed the following relationships:

mappingFunction takes anything as a parameter, but it must be the same type of "anything" as the type of elements of items array
mappingFunction can return anything, but whatever type it returns, it will be used as the type of elements of the array returned by map function

The picture below demonstrates these relationships. Shapes of the same color have to be of the same type.

You might have noticed the <TElement, TResult> thing that we added next to map. Type parameters have to be declared explicitly using this notation. Otherwise, TypeScript wouldn't know if TElement is a type argument or an actual type.

BTW, for some reason, it is a common convention to use single-character names for type parameters (with a strong preference for T). I'd strongly recommend using full names, especially when you are not that experienced with generics. On the other hand, it's a good idea to prefix type arguments with T, so that they're easily distinguishable from regular types.

Calling generic functions

How to call a generic function? As we saw, generic functions have type parameters. These parameters are replaced with actual types "when" the function is called (technically, it's all happening at compile-time). You can provide the actual types using angle brackets notation.

map<Person, string>(persons, person => person.name);

Imagine that by providing type arguments TElement and TResult become replaced with Person and string.

function map<TElement, TResult>(
  items: TElement[],
  mappingFunction: (item: TElement) => TResult
): TResult[] {
  /* ... */
}

// ...becomes...

function map(
  items: Person[],
  mappingFunction: (item: Person) => string
): string[] {
  /* ... */
}

Having to provide type arguments, when calling generic functions would be cumbersome. Fortunately, TypeScript can infer them by looking at the types of the arguments passed to the function. Therefore, we end up with the following code.

const names = map(persons, person => person.name);

Whoohoo! It looks exactly as the JavaScript version, except it's type-safe! Contrary to the first version of map, the type of names is string[] instead of any[]. What's more, TypeScript is now capable of throwing a compile error for the following call.

// 🔴 Error! Operator '+' cannot be applied to Person and 5.
map(persons, n => n + 5);

Here is a very simplified sequence of steps that leads the compiler to throw an error.

Compiler looks at the type of persons. It sees Person[].
According to the definition of map, the type of the first parameter is TElement[]. Compiler deduces that TElement is Person.
Compiler looks at the second parameter. It should be a function from Person to TResult. It doesn't know what TResult is yet.
It checks the body of the function provided as the second argument. It infers that the type of n is Person.
It sees that you're trying to add 5 to n, which is of type Person. This doesn't make sense, so it throws an error.

When to use generic functions?

The good news is that, most likely, you will not be creating generic functions very often. It's much more common to call generic functions then to define them. However, it's still very useful to know how generic functions work, as it can help you better understand compiler errors.

As exemplified by map, functions that take arrays as parameters are often generic functions. If you look at the typings for lodash library, you will see that nearly all of them are typed as generic functions. Such functions are only interested in the fact that the argument is an array, they don't care about the type of its elements.

In React framework, Higher Order Components are generic functions, as they only care about the argument being a component. The type of the component's properties is not important.

In RxJs, most operators are generic functions. They care about the input being and Observable, but they're not interested in the type of values being emitted by the observable.

Summary

Wrapping up:

generic functions let you achieve type safety for functions that work with many different types of inputs;
type arguments are very much like any type, except they can be used to express relationships between function parameters and the return type;
calling a generic function is very straightforward thanks to type inference.

I hope this article helped you finally understand generic functions. If not, please let me know!

Want to learn more?

Did you like this TypeScript article? I bet you'll also like my book!

⭐️ Advanced TypeScript ⭐️

Two cool features coming soon to JavaScript

Milosz Piechocki — Tue, 10 Sep 2019 18:19:43 +0000

Originally published on codewithstyle.info

Recently two TC39 proposals have advanced to Stage 3.

Daniel Rosenwasser

@drosenwasser

WE JUST MOVED OPTIONAL CHAINING IN JS TO STAGE 3 🎉🎉🎉🎉🎉🎉🎉

18:21 PM - 25 Jul 2019

Daniel Rosenwasser

@drosenwasser

Today I got to present nullish coalescing at TC39 and it progressed to stage 3! The cherry on top? @rkirsling already has a patch out for it in JavaScriptCore! bugs.webkit.org/show_bug.cgi?i…

05:53 AM - 24 Jul 2019

What it means to us, developers, is that two new exciting language features will soon become part of the ECMAScript standard.

Let's have a quick look at these additions and see how to take advantage of them.

What's the deal with TC39 proposals?

TC39 is a group of people that drives the development of the ECMAScript (the standard of which JavaScript language is an implementation). They meet regularly to discuss proposals of new language features. Every proposal goes through a number of stages. Once it reaches Stage 4, it is ready to be included in the next version of the ECMAScript standard.

When a proposal reaches Stage 3, it is already quite mature. The specification has been approved and is unlikely to change. There might already be some browsers implementing the new feature. While Stage 3 proposal is not guaranteed to become part of the standard, it's very likely to.

The two proposals we're looking at are:

Optional chaining

Optional chaining aims to provide nice and short syntax for a very common pattern: accessing a nested property of an object in a safe way.

const customers = [
  {
    name: "John",
    company: {
      name: "Acme",
      address: "London"
    }
  },
  {
    name: "Jane",
    company: {
      address: "New York"
    }
  },
  {
    name: "Judith"
  }
];

This array contains objects representing customers. They all follow a similar structure, but some of the properties are optional. Let's say we'd like to iterate over the array and print the company name in upper case for each customer.

for (let customer of customers) {
  console.log(customer.company.name.toUpperCase());
}

As you might have guessed, the above code is not safe. It will result in runtime errors for the second and the third array elements. We can fix it by using the following popular pattern.

console.log(
  customer &&
    customer.company &&
    customer.company.name &&
    customer.company.name.toUpperCase()
);

Logical and operator (&&) in JavaScript behaves differently from most programming languages. It works on any value type, not only booleans. a && b translates to: if a is falsy (can be converted to false), return a. Otherwise, return b.

Unfortunately, this solution is rather verbose. There is a lot of repetition and it gets worse the deeper the objects are nested. What's more, it checks for a value to be falsy, not null or undefined. Therefore, it would return 0 for the following object, while it might be preferable to return undefined instead.

{
  name: "John",
  company: {
    name: 0,
  }
}

Optional chaining comes to the rescue! With this new feature, we can shorten the above piece to a single line.

customer?.company?.name?.toUpperCase();

The customer?.company expression will check whether customer is null or undefined. If this is the case, it will evaluate to undefined. Otherwise, it will return company. In other words, customer?.company is equivalent to customer != null ? customer : undefined. The new ?. operator is particularly useful when chained, hence the name (optional chaining).

Be careful when replacing existing && chains with ?. operator! Bear in mind the subtle difference it treatment of falsy values.

Nullish coalescing

The second proposal introduces ?? operator which you can use to provide a default value when accessing a property/variable that you expect can be null or undefined.

But hey, why not simply use || for this? Similarly to &&, logical or can operator on non-boolean values as well. a || b returns a if it's truthy, or b otherwise.

However, it comes with the same problem as && - it checks for a truthy value. For example, an empty string ('') will not be treated as a valid value and the default value would be returned instead.

const customer = {
  name: "John",
  company: {
    name: ""
  }
};
customer.company.name || "no company"; // === 'no company'

Nullish coalescing operator can be nicely combined with optional chaining.

(customer?.company?.name ?? "no company").toUpperCase();

While the benefit of optional chaining is clear (less verbose code), nullish coalescing is a little bit more subtle. We've all been using || for providing a default value for a long time. However, this pattern can potentially be a source of nasty bugs, when a falsy value is skipped in favour of the default value. In most cases, the semantics of ?? is what you're actually looking for.

How can I use it?

Since those proposals have not reached Stage 4 yet, you need transpile the code that uses them (for example with Babel). You can play with Babel's on-line REPL to see what do they get compiled to.

At the moment of writing, optional chaining is available in Chrome behind a feature flag.

Optional chaining will also be available in the upcoming TypeScript 3.7 release!

Summary

Recent ECMAScript versions didn't bring many syntactical additions to the language. It's likely to change with the next edition. Some people say that JavaScript is getting bloated. I personally think that these two pieces of syntactic sugar are long overdue, as they've been available in many modern programming languages and they address real-life, common development scenarios.

What do you think? 😉

Want to learn more?

Did you like this TypeScript article? I bet you'll also like my book!

⭐️ Advanced TypeScript ⭐️

Using React useState hook with TypeScript

Milosz Piechocki — Thu, 22 Aug 2019 20:51:18 +0000

React hooks are a recent addition to React that make function components have almost the same capabilities as class components. Most of the time, using React hooks in TypeScript is straightforward.

However, there are some situations when deeper understanding of hooks' types might prove very useful. In this article, we're going to focus on the useState hook.

I'm going to assume that you have a basic understanding of this hook. If this is not the case, please read this first.

Reading the types

First of all, let's take a look at the type signature of useState. You'll see how much information you can extract solely from types, without looking at the docs (or the implementation).

If you're only interested in practical examples, skip to the next section.

Overloads

function useState<S = undefined>(): [S | undefined, Dispatch<SetStateAction<S | undefined>>];
function useState<S>(initialState: S | (() => S)): [S, Dispatch<SetStateAction<S>>];

As you can see, there are two versions of useState function. TypeScript lets you define multiple type signatures for a function as it is often the case in JavaScript that a function supports different types of parameters. Multiple type signatures for a single function are called overloads.

Both overloads are generic functions. The type parameter S represents the type of the piece of state stored by the hook. The type argument in the second overload can be inferred from initialState. However, in the first overload, it defaults to undefined unless the type argument is explicitly provided. If you don't pass initial state to useState, you should provide the type argument explicitly.

`useState` parameters

The first overload doesn't take any parameters - it's used when you call useState without providing any initial state.

The second overload accepts initialState as parameter. It's type is a union of S and () => S. Why would you pass a function that returns initial state instead of passing the initial state directly? Computing initial state can be expensive. It's only needed during when the component is mounted. However, in a function component, it would be calculated on every render. Therefore, you have an option to pass a function that calculates initial state - expensive computation will only be executed once, not on every render.

`useState` return type

Let's move to the return type. It's a tuple in both cases. Tuple is like an array that has a specific length and contains elements with specific types.

For the second overload, the return type is [S, Dispatch<SetStateAction<S>>]. The first element of the tuple has type S - the type of the piece of state. It will contain the value retrieved from the component's state.

The second element's type is Dispatch<SetStateAction<S>>. Dispatch<A> is simply defined as (value: A) => void - a function that takes a value and doesn't return anything. SetStateAction<S> is defined as S | ((prevState: S) => S). Therefore, the type of Dispatch<SetStateAction<S>> is actually (value: S | ((prevState: S) => S)) => void. It is a function that takes either an updated version of the piece of state OR a function that produces the updated version based on the previous version. In both cases, we can deduce that the second element of the tuple returned by setState is a function that we can call to update the component's state.

The return type of the first overload is the same, but here instead of S, S | undefined is used anywhere. If we don't provide initial state it will store undefined initially. It means that undefined has to be included in the type of the piece of state stored by the hook.

Usage examples

Most of the time you don't need to bother with providing type arguments to useState - the compiler will infer the correct type for you. However, in some situations type inference might not be enough.

Empty initial state

The first type of situation is when you don't want to provide initial state to useState.

As we saw in the type definition, the type argument S for the parameterless defaults to undefined. Therefore, the type of pill should be inferred to undefined. However, due to a design limitation in TypeScript, it's actually inferred to any.

Similarly, setPill's type is inferred to React.Dispatch<any>. It's really bad, as nothing would stop us from calling it with invalid argument: setPill({ hello: 5 }).

export const PillSelector: React.FunctionComponent = () => {
    const [pill, setPill] = useState();
    return (
        <div>
            <button onClick={() => setPill('red')}>Red pill</button>
            <button onClick={() => setPill('blue')}>Blue pill</button>
            <span>You chose {pill} pill!</span>
        </div>
    );
}

In order to fix this issue, we need to pass a type argument to setState. We treat pill as text in JSX, so our fist bet could be string. However, let's be more precise and limit the type to only allow values that we expect.

const [pill, setPill] = useState<'red' | 'blue'>();

Note that the inferred type of pill is now "red" | "blue" | undefined (because this piece of state is initially empty). With strictNullChecks enabled TypeScript wouldn't let us call anything on pill:

// 🛑 Object is possibly 'undefined'.ts(2532)
<span>You chose {pill.toUpperCase()} pill!</span>

...unless we check the value first:

// ✅ No errors!
{pill && <span>You chose {pill.toUpperCase()} pill!</span>}

Clearable state

Another kind of situation when you would provide a type argument to useState is when initial state is defined, but you want to be able to clear the state later.

export const PillSelector: React.FunctionComponent = () => {
    const [pill, setPill] = useState('blue');
    return (<div>
        <button onClick={() => setPill('red')}>Red pill</button>
        <button onClick={() => setPill('blue')}>Blue pill</button>
        // 🛑 Argument of type 'undefined' is not assignable 
        // to parameter of type 'SetStateAction<string>'.
        <button onClick={() => setPill(undefined)}>Reset</button>
        {pill && <span>You chose {pill.toUpperCase()} pill!</span>}
    </div>);
}

Since initial state is passed to useState, the type of pill gets inferred to string. Therefore, when you try to pass undefined to it, TypeScript will error.

You can fix the problem by providing the type argument.

const [pill, setPill] = useState<'blue' | 'red' | undefined>('blue');

Summary

Wrapping up, we've analysed the type definitions of useState function thoroughly. Based on this information, we saw when providing the type argument to useState might be necessary and when the inferred type is sufficient.

I like how hooks are great example of how much information can be read from type definitions. They really show off the power of static typing!

Want to learn more?

Did you like this TypeScript article? I bet you'll also like my book!

⭐️ Advanced TypeScript ⭐️

Typing Higher Order Components in React

Milosz Piechocki — Thu, 15 Aug 2019 21:25:45 +0000

Some time ago I wrote about generic type arguments propagation feature added in TypeScript version 3.4. I explained how this improvement makes point-free style programming possible in TypeScript.

As it turns out, there are more cases in which propagation of generic type arguments is desirable. One of them is passing a generic component to a Higher Order Component in React.

// Detect dark theme var iframe = document.getElementById('tweet-1154542230641623040-162'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1154542230641623040&theme=dark" }

The post is inspired by the problem Frederic Barthelemy tweeted about and asked me to have a look at.

Higher Order Components

I'm not going to give a detailed explanation, as there are already plenty to be found on the internet. Higher Order Component (HOC) is a concept of the React framework that lets you abstract cross-cutting functionality and provide it to multiple components.

Technically, HOC is a function that takes a component and returns another component. It usually augments the source component with some behavior or provides some properties required by the source component.

Here is an example of a HOC in TypeScript:

const withLoadingIndicator = 
    <P extends {}>(Component: ComponentType<P>): ComponentType<P & { isLoading: boolean }> => 
        ({ isLoading, ...props }) =>
            isLoading 
                ? <span>Loading...</span> 
                : <Component {...props as P} />;

As you can deduce from the type signature, withLoadingIndicator is a function that accepts a component with P-shaped properties and returns a component that additionally has isLoading property. It adds the behavior of displaying loading indicator based on isLoading property.

Problem: passing a generic component to a HOC

So far so good. However, let's imagine that we have a generic component Header:

class Header<TContent> extends React.Component<HeaderProps<TContent>> { }

...where HeaderProps is a generic type that represents Header's props given the type of associated content (TContent):

type HeaderProps<TContent> = {
    content: TContent;
    title: string;
}

Next, let's use withLoadingIndicator with this Header component.

const HeaderWithLoader = withLoadingIndicator(Header);

The question is, what is the inferred type of HeaderWithLoader? Unfortunately, it's React.ComponentType<HeaderProps<unknown> & { isLoading: boolean; }> in TypeScript 3.4 and later or React.ComponentType<HeaderProps<{}> & { isLoading: boolean; }> in previous versions.

As you can see, HeaderWithLoader is not a generic component. In other words, generic type argument of Header was not propagated. Wait... doesn't TypeScript 3.4 introduce generic type argument propagation?

Solution: use function components!

Actually, it does. However, it only works for functions. Header is a generic class, not a generic function. Therefore, the improvement introduced in TypeScript 3.4 doesn't apply here ☹️

Fortunately, we have function components in React. We can make type argument propagation work if we limit withLoadingIndicator to only work with function components.

Unfortunately, we cannot use FunctionComponent type since it is defined as an interface, not a function type. However, a function component is nothing else but a generic function that takes props and returns React.ReactElement. Let's define our own type representing function components.

type SimpleFunctionComponent<P> = (props: P) => React.ReactElement;

declare const withLoadingIndicator: 
    <P>(Component: SimpleFunctionComponent<P>) => 
        (SimpleFunctionComponent<P & { isLoading: boolean }>);

By using SimpleFunctionComponent instead of FunctionComponent we loose access to properties such as defaultProps, propTypes, etc., which we don't need anyway.

Obviously, we need to change Header to be a function component, not a class component:

declare const Header: <TContent>(props: HeaderProps<TContent>) => React.ReactElement;

We wouldn't be able to use FunctionComponent here anyway, since Header is a generic component.

Let's now take a look at the inferred type of HeaderWithLoader. It's...

<TContent>(props: HeaderProps<TContent> & { isLoading: boolean }) => React.ReactElement

...which looks very much like a generic function component!

Indeed, we can use Header as a regular component in JSX:

class Foo extends React.Component {
    render() {
        return (
            <HeaderWithLoader 
                title="Hello" 
                content={12345} 
                isLoading={false} />
        );
    }
}

Most importantly, HeaderWithLoader is typed correctly!

Summary

As you can see, typing HOCs in React can get tricky. The proposed solution is really a workaround - ideally, TypeScript should be able to propagate generic type arguments for all generic types (not only functions).

Anyway, this example demonstrates how important it is to stay on top of the features introduced in new TypeScript releases. Before version 3.4, it wouldn't be even possible to get this HOC typed correctly.

Want to learn more?

Did you like this TypeScript article? I bet you'll also like my book!

⭐️ Advanced TypeScript ⭐️

Strict function types in TypeScript: covariance, contravariance and bivariance

Milosz Piechocki — Mon, 29 Jul 2019 20:29:24 +0000

Let's talk about one of the less well known strict type checking options - strictFunctionTypes. It helps you avoid another class of bugs, and it's also an excellent opportunity to learn about some fundamental computer science concepts: covariance, contravariance, and bivariance.

Strict function type checking was introduced in TypeScript 2.6. Its definition in TypeScript documentation refers to an enigmatic term: bivariance.

Disable bivariant parameter checking for function types.

What bugs can `strictFunctionTypes` catch?

First of all, let's see an example of a bug that can be caught by enabling this flag.

In the following example, fetchArticle is a function that accepts a callback to be executed after an article is fetched from some backend service.

interface Article {
    title: string;
}

function fetchArticle(onSuccess: (article: Article) => void) {
    // ...
}

Interestingly, TypeScript with default settings compiles the following code without errors.

interface ArticleWithContent extends Article {
    content: string;
}

fetchArticle((r: ArticleWithContent) => {
    console.log(r.content.toLowerCase());
});

Unfortunately, this code can result in a runtime error. The function passed as a callback to fetchArticle only knows how to deal with with a specific subset of Article objects - those that also have content property.

However, fetchArticle can fetch all kinds of articles - including those that only have title defined. In such case, r.content is undefined, and runtime exception is thrown.

TypeError: undefined is not an object (evaluating 'r.content.toLowerCase')

Fortunately, enabling strictFunctionTypes results in a compile-time error. A compile-time error is always better than a runtime error, as it surfaces before users run your code.

Argument of type '(r: ArticleWithContent) => void' is not assignable to parameter of type '(article: Article) => void'.

Covariance, contravariance, and bivariance

If you just wanted to learn what strictFunctionTypes does, you can stop reading right now. However, I encourage you to follow along and learn some background behind this check.

First, let's introduce a type to represent generic single-argument callbacks.

type Callback<T> = (value: T) => void;

function fetchArticle(onSuccess: Callback<Article>) {
    // ...
}

declare const callback: Callback<ArticleWithContent>;
fetchArticle(callback);

The reason fetchArticle shouldn't accept callback is that the callback is too specific. It only works on a subset of things that can be fed into it.

The type of callback should not be assignable to the type of onSuccess parameter.

In other words, the fact that ArticleWithContent is assignable to Article does not imply that
Callback<ArticleWithContent> is assignable to Callback<Article>. If such implication were true, Callback type would be covariant.

In our case, the opposite is true - Callback<Article> is assignable to Callback<ArticleWithContent>. That's because a callback that can handle all articles is also able to handle ArticleWithContent. Therefore, Callback is contravariant.

If both implications were true at the same time, then Callback would be bivariant.

Let's now revisit the definition of strictFunctionTypes.

Disable bivariant parameter checking for function types.

Does it make sense now? With the check enabled, function type parameter positions are checked contravariantly instead of bivariantly.

On a side note, some function types are excluded from strict function type checks - e.g., function arguments to methods and constructors are still checked bivariantly.

Summary

Wrapping up, strictFunctionTypes is a useful compiler flag that helps you catch a class of bugs related to passing function arguments, such as callbacks.

The concept behind this flag is contravariance, which is a property of a type (type constructor, strictly speaking) that describes its assignability with respect to its type argument.

Want to learn more?

Did you like this TypeScript article? I bet you'll also like my course!

⭐️ Advanced TypeScript Masterclass ⭐️

5 Commandments for TypeScript programmers

Milosz Piechocki — Wed, 17 Jul 2019 15:54:12 +0000

More and more projects and teams are adopting TypeScript. However, there is a massive difference between just using TypeScript and taking the most out of it.

I present to you this list of high-level TypeScript best practices that will help you take advantage of TypeScript to the fullest possible extent.

This article is also available in Russian: 5 заповедей TypeScript-разработчика (by Vadim Belorussov).

Do not lie

Types are a contract. What does it mean? When you implement a function, its type is a promise to other developers (or to your future self!) that when they call it, it will return a specific kind of value.

In the following example, the type of getUser promises that it will return an object that will always have two properties: name and age.

interface User {
  name: string;
  age: number;
}

function getUser(id: number): User { /* ... */ }

TypeScript is a very flexible language. It's full of compromises made in order to make its adoption easier. For example, it allows you to implement getUser like this:

function getUser(id: number): User {
  return { age: 12 } as User;
}

Don't do this! It's a LIE. By doing this, you LIE to other developers (who will use this function in their functions). They expect the object returned by getUser to always have some name. But it doesn't! Then, what happens when your teammate writes getUser(1).name.toString()? You know it well...

Of course, this lie seems very obvious. However, when working with a huge codebase, you will often find yourself in a situation when a value you want to return (or pass) almost matches the expected type. Figuring out the reason for type mismatch takes time and effort and you are in a hurry... so you decide to cast.

However, by doing this, you violate the holy contract. It's ALWAYS better to take time to figure out why types do not match than to do the cast. It's very likely that some runtime bug is lurking under the surface.

Don't lie. Respect your contracts.

Be precise

Types are documentation. When you document a function, don't you want to convey as much information as possible?

// Returns an object
function getUser(id) { /* ... */ }

// Returns an object with two properies: name and age
function getUser(id) { /* ... */ }

// If id is a number and a user with given id exists,
// returns an object with two properies: name and age.
// Otherwise, returns undefined.
function getUser(id) { /* ... */ }

Which comment for getUser would you prefer? The more you know about what it returns, the better. For example, knowing that it could return undefined, you can write an if statement to check if the value it returned is defined before accessing its properties.

It's exactly the same with types. The more precise a type is, the more information it conveys.

function getUserType(id: number): string { /* ... */ }

function getUserType(id: number): 'standard' | 'premium' | 'admin' { /* ... */ }

The second version of getUserType is much more informative, and hence it puts the caller in a much better situation. It's easier to handle a value if you know that it is for sure (contracts, remember?) one of the three strings than if it can be any string. For starters, you know for sure that the value is not an empty string.

Let's see a more realistic example. State type represents the state of a component that fetches some data from the backend. Is this type precise?

interface State {
  isLoading: boolean;
  data?: string[];
  errorMessage?: string;
}

The consumer of this type must handle some unlikely combinations of property values. For example, it's not possible that both data and errorMessage will be defined (data fetching can either be successful or result in an error).

We can make the type much more precise with the help of discriminated union types:

type State =
   | { status: 'loading' }
   | { status: 'successful', data: string[] }
   | { status: 'failed', errorMessage: string };

Now, the consumer of this type has much more information. They don't need to handle illegal combinations of property values.

Be precise. Convey as much information as possible in your types.

Start with types

Since types are both contract and documentation, they're great for designing your functions (or methods).

There are many articles around in the internet that advise software engineers to think before they write code. I totally agree with this approach. It's tempting to jump straight into code, but it often leads to some bad decisions. Spending some time thinking about the implementation always pays off.

Types are super helpful in this process. Thinking can result in writing down the type signatures of functions involved in your solution. It's awesome because it lets you focus on what your functions do instead of how they achive it.

React JS has a concept of Higher Order Components. They are functions that augment given component in some way. For example, you could create a withLoadingIndicator Higher Order Component that adds a loading indicator to an existing component.

Let's write the type signature for this function. It takes a component and returns a component. We can use React's ComponentType to indicate a component.

ComponentType is a generic type parameterized by the type of properties of the component. withLoadingIndicator takes a component and returns a new component that either shows the original component or shows a loading indicator. The decision is made based on the value of a new boolean property isLoading. Therefore, the resulting component should require the same properties as the original component plus the new property.

Let's finalize the type. withLoadingIndicator takes a component of type ComponentType<P> where P denotes the type of the properties. It returns a component with augmented properties of type P & { isLoading: boolean }.

const withLoadingIndicator = <P>(Component: ComponentType<P>) 
    : ComponentType<P & { isLoading: boolean }> =>
        ({ isLoading, ...props }) => { /* ... */ }

Figuring out the type of this function forced us to think about its input and its output. In other words, it made us design it. Writing the implementation is a piece of cake now.

Start with types. Let types force you to design before implementing.

Embrace strictness

The first three points require you to pay a lot of attention to types. Fortunately, you are not alone in the task - TypeScript compiler will often let you know when your types lie or when they're not precise enough.

You can make the compiler even more helpful by enabling --strict compiler flag. It is a meta flag that enables all strict type checking options: --noImplicitAny, --noImplicitThis, --alwaysStrict, --strictBindCallApply, --strictNullChecks, --strictFunctionTypes and --strictPropertyInitialization.

What do they do? In general, enabling them results in more TypeScript compiler errors. This is good! More compiler errors mean more help from the compiler.

Let's see how enabling --strictNullChecks helps you identify a lie.

function getUser(id: number): User {
    if (id >= 0) {
        return { name: 'John', age: 12 };
    } else {
        return undefined;
    }
}

The type of getUser promises that it will always return a User. However, as you can see in the implementation, it can also return an undefined value!

Fortunately, enabling --strictNullChecks results in a compiler error:

Type 'undefined' is not assignable to type 'User'.

TypeScript compiler detected the lie. You can get rid of the error by telling the truth:

function getUser(id: number): User | undefined { /* ... */ }

Embrace type checking strictness. Let the compiler watch your steps.

Stay up to date

TypeScript language is being developed at a very fast pace. There is a new release every two months. Each release brings in significant language improvements and new features.

It is often the case that new language features allow for more precise types and stricter type checking.

For example, version 2.0 introduced Discriminated Union Types (which I mentioned in Be precise).

Version 3.2 introduced --strictBindCallApply compiler option which enables correct typing of bind, call and apply functions.

Version 3.4 improved type inference in higher order functions, making it easier to use precise type when writing code in functional style.

My point here is that it really pays off to be familiar with language features introduced in the latest releases of TypeScript. They can often help you adhere to the other four commandments from this list.

A good starting point is the official TypeScript roadmap. It's also a good idea to check out TypeScript section of the Microsoft Devblog regularly as all release announcements are made there.

Stay up to date with new language features and make the work for you.

Summary

I hope you find the list useful. Like anything in life, these commandments shouldn't be followed blindly. However, I firmly believe those rules will make you a better TypeScript programmer.

I'd love to hear your thoughts about it in the comments section.

Want to learn more?

Did you like this TypeScript article? I bet you'll also like my course!

⭐️ Advanced TypeScript Masterclass ⭐️

The meaning of union and intersection types

Milosz Piechocki — Tue, 09 Jul 2019 19:17:23 +0000

Union types are fairly popular in TypeScript. You might have already used them multiple times. Intersection types are slightly less common. They seem to cause a little bit more confusion.

Did you ever wonder where do those names come from? While you might have some intuition about what a union of two types is, the intersection is usually not understood well.

After reading this article, you will have a better understanding of those types which will make you more confident when using them in your codebases.

Simple union types

Union type is very often used with either null or undefined.

const sayHello = (name: string | undefined) => { /* ... */ };

For example, the type of name here is string | undefined which means that either a string OR an undefined value can be passed to sayHello.

sayHello("milosz");
sayHello(undefined);

Looking at the example, you can intuit that a union of types A and B is a type that accepts both A and B values.

Union and intersection of object types

This intuition also works for complex types.

interface Foo {
    foo: string;
    xyz: string;
}

interface Bar {
    bar: string;
    xyz: string;
}

const sayHello = (obj: Foo | Bar) => { /* ... */ };

sayHello({ foo: "foo", xyz: "xyz" });
sayHello({ bar: "bar", xyz: "xyz" });

Foo | Bar is a type that has either all required properties of Foo OR all required properties of Bar. Inside sayHello it's only possible to access obj.xyz because it's the only property that is included in both types.

What about the intersection of Foo and Bar, though?

const sayHello = (obj: Foo & Bar) => { /* ... */ };

sayHello({ foo: "foo", bar: "bar", xyz: "xyz" });

Now sayHello requires the argument to have both foo AND bar properties. Inside sayHello it's possible to access both obj.foo, obj.bar and obj.xyz.

Hmm, but what does it have to intersection? One could argue that since obj has properties of both Foo and Bar, it sounds more like a union of properties, not intersection. Similarly, a union of two object types gives you a type that only has the intersection of properties of constituent types.

It sounds confusing. I even stumbled upon a GitHub issue in TypeScript repository ranting about naming of these types. To understand the naming better we need to look at types from a different perspective.

Set theory

Do you remember a concept called sets from math classes? In mathematics, a set is a collection of objects (for example numbers). For example, {1, 2, 7} is a set. All positive numbers can also form a set (an infinite one).

Sets can be added together (a union). A union of {1, 2} and {4, 5} is {1, 2, 4, 5}.

Sets can also be intersected. Intersection of two sets is a set that only contains those numbers that are present in both sets. So, an intersection of {1, 2, 3} and {3, 4, 5} is {3}.

Let's imagine two sets: Squares and RedThings.

The union of Squares and RedThings is a set that contains both squares and red things.

However, the intersection of Squares and RedThings is a set that only contains red squares.

Relationship between types and sets

Computer science and mathematics overlap in many places. One of such places is type systems.

A type, when looked at from a mathematical perspective, is a set of all possible values of that type. For example the string type is a set of all possible strings: {'a', 'b', 'ab', ...}. Of course, it's an infinite set.

Similarly, number type is a set of all possible numbers: {1, 2, 3, 4, ...}.

Type undefined is a set that only contains a single value: { undefined }.

What about object types (such as interfaces)? Type Foo is a set of all object that contain foo and xyz properties.

Understanding union and intersection types

Armed with this knowledge, you're now ready to understand the meaning of union and intersection types.

Union type A | B represents a set that is a union of the set of values associated with type A and the set of values associated with type B.

Intersection type A & B represents a set that is an intersection of the set of values associated with type A and the set of values associated with type B.

Therefore, Foo | Bar represents a union of the set of objects having foo and xyz properties and the set of objects having bar and xyz. Objects belonging to such set all have xyz property. Some of them have foo property and the others have bar property.

Foo & Bar represents an intersection of the set of objects having foo and xyz properties and the set of objects having bar and xyz. In other words, the set contains objects that belong to sets represented by both Foo and Bar. Only objects that have all three properties (foo, bar and xyz) belong to the intersection.

Real-world example of intersection type

Union types are quite widespread so let's focus on an example of an intersection type.

In React, when you declare a class component, you can parameterise it with thy type of its properties:

class Counter extends Component<CounterProps> { /* ... */ }

Inside the class, you can access the properies via this.props. However, the type of this.props is not simply CounterProps, but:

Readonly<CounterProps> & Readonly<{ children?: ReactNode; }>

The reason for this is that React components can accept children elements:

<Counter><span>Hello</span></Counter>

The children element tree is accessible to the component via children prop. The type of this.props reflects that. It's an intersection of (readonly) CounterProps and a (readonly) object type with an optional children property.

In terms of sets, it's an intersecion of the set of objects that have properties as defined in CounterProps and the set of objects that have optional children property. The result is a set of objects that have both all properties of CounterProps and the optional children property.

Summary

That's it! I hope this article helps you wrap your head around union and intersection types. As it's often the case in computer science, understanding the fundamentals makes you better at grasping programming concepts.

Want to learn more?

Did you like this TypeScript article? I bet you'll also like my course!

Want to learn more?

Did you like this TypeScript article? I bet you'll also like my book!

⭐️ Advanced TypeScript ⭐️

Comprehensive list of built-in utility types in TypeScript

Milosz Piechocki — Sun, 30 Jun 2019 10:05:47 +0000

Advanced types section of TypeScript docs mentions some very useful built-in types as examples of conditional types and mapped types.

I was surprised to learn that there are more such types and some of them seem to be undocumented. This article contains a list of all such types.

The list is based on what I could find in es5.d.ts on github.

List of types

`Partial`

Partial<T> returns a type that has the same properties as T but all of them are optional. This is mostly useful when strictNullChecks flag is enabled.

Partial works on a single level - it doesn't affect nested objects.

A common use case for Partial is when you need to type a function that lets you override default values of properties of some object.

const defaultSettings: Settings = { /* ... */ };

function getSettings(custom: Partial<Settings>): Settings {
  return { ...defaultSettings, ...custom };
}

Update:

However, this technique is not 100% type-safe. As pointed out by AngularBeginner, if custom has a property that has been explicitly set to undefined, the result will end up having this property undefined as well. Therefore, its type (Settings) will be a lie.

A more type-safe version of getSettings would look like this:

function getSettings(custom: Partial<Settings>): Partial<Settings> {
  return { ...defaultSettings, ...custom };
}

See implementation.

`Required`

Required<T> removes optionality from T's properties. Again, you'll most likely need it if you have strictNullChecks enabled (which you should 😉).

Similarly to Required, Partial works on the top level only.

The example is somehow symmetrical to the previous one. Here, we accept an object that has some optional properties. Then, we apply default values when a property is not present. The result is an object with no optional properties - Required<Settings>.

function applySettings(settings: Settings) {
  const actualSettings: Required<Settings> = {
    width: settings.width || 100,
    height: settings.height || 200,
    title: settings.title || '',
  }
  // do something...
}

See implementation.

`Readonly`

This one you probably have heard of. Readonly<T> returns a type that has the same properties as T but they are all readonly. It is extremally useful for functional programming because it lets you ensure immutability at compile time. An obvious example would be to use it for Redux state.

Once again, Readonly doesn't affect nested objects.

See implementation.

`Pick`

Pick lets you create a type that only has selected properties of another type.

An example would be letting the caller override only a specific subset of some default properties.

function updateSize(overrides: Pick<Settings, 'width' | 'height'>) {
  return { ...defaultSettings, ...overrides};
}

See implementation.

`Record`

Record lets you define a dictionary with keys belonging to a specific type.

JavaScript objects can be very naturally used as dictionaries. However, in TypeScript you usually work with objects using interfaces where the set of keys is predefined. You can work this around by writing something like:

interface Options {
  [key: string]: string;
}

Record lets you do this in a more concise way: type Options = Record<string, string>.

See implementation.

`Exclude`

Exclude makes a lot of sense when you look at types in terms of sets of possible values. For example, number type can be looked at as a set containing all numerical numbers. A | B is called a union because its set of possible values is a sum of possible values of A and possible values of B.

Exclude<T, U> returns a type whose set of values is the same as the set of values of type T but with all U values removed. It is a bit like substruction, but defined on sets.

A good example of using Exclude is to define Omit. Omit takes a type and its key and returns a type without this key.

interface Settings {
  width: number;
  height: number;
  title: string;
}

type SizeSettings = Omit<Settings, 'title'>;

// type SizeSettings = {
//   width: number;
//   height: number;
// }

Omit<T, K> can be defined by picking all keys from T except K. First, we'll Exclude K from the set of keys of T. Next, we will use this set of keys to Pick from T.

type Omit<T, K extends keyof T> = Pick<T, Exclude<keyof T, K>>;

See implementation.

`Extract`

Extract<T, U> return those types included in T that are assignable to U. You can say that it returns a common part of T and U. However, the types don't have to be exactly the same - it suffices that a type from T is assignable to U.

For example, you can use Extract to filter out function types from a union type:

type Functions = Extract<string | number | (() => void), Function>;  // () => void

See implementation.

`NonNullable`

NonNullable<T> removes null and undefined from the set of possible values of T.

It is mostly useful when working with strictNullChecks and optional properties and arguments. It has no effect on a type that is already not nullable.

type Foo = NonNullable<string | null | undefined>; // string

You can find a good usage example of NonNullable in my previous article.

See implementation.

`Parameters`

This useful type returns a tuple of types of parameters of given function.

function fetchData(id: number, filter: string) {
}

type FetchDataParams = Parameters<typeof fetchData>; // [number, string]

type IdType = FetchDataParams[0]; // number

One interesting usage is typing wrapper functions without having to repeat the parameter list.

function fetchDataLogged(...params: Parameters<typeof fetchData>) {
  console.log('calling fetchData');
  fetchData(...params);
}

See implementation.

`ConstructorParameters`

ConstructorParameters is exactly the same as Parameters but works with constructor functions.

class Foo {
  constructor(a: string, b: number) {}
}

type FooConstructorParams = ConstructorParameters<typeof Foo>;

One caveat is that you have to remember about typeof in front of the class name.

See implementation.

`ReturnType`

The name is pretty self-explanatory - it returns a type returned by given function. I found this type really useful.

One example is in Redux where you define action creators and reducers. A reducer accepts a state object and an action object. You can use ReturnType of the action creator to type the action object.

function fetchDataSuccess(data: string[]) {
  return {
    type: 'fetchDataSuccess',
    payload: data
  }
}

function reduceFetchDataSuccess(state: State, { payload }: ReturnType<typeof fetchDataSuccess>) {
}

See implementation.

`InstanceType`

InstanceType is an interesting one. You can say that it is complimentary to typeof operator.

It accepts a type of a constructor function and returns an instance type of this function.

In TypeScript, class C defines two things:

a constructor function C for creating new instances of class C
an interface for objects of class C - the instance type

typeof C returns the type of the constructor function.

InstanceType<typeof C> takes the constructor function and returns type of the instances produced by this function: C.

class C {
}

type CInstance = InstanceType<typeof C>;  // C

See implementation.

Want to learn more?

Did you like this TypeScript article? I bet you'll also like my course!

⭐️ Advanced TypeScript Masterclass ⭐️

Precise domain modeling with discriminated unions in TypeScript

Milosz Piechocki — Tue, 27 Nov 2018 20:41:00 +0000

In this post, we're going to look into an interesting feature of the TypeScript language. It's called discriminated unions and is also known as algebraic data types. The latter name comes from Functional Programming paradigm where such types are used very heavily.

Issues with enum types

Let me start by showing you an example of a problem that can be solved with discriminated unions.

You're working on an application which deals with the management of customers. There are two kinds of customers: individual and institutional. For each customer kind, you store different details: individual customers have a first and last name and a social security number. Companies have a company name and a tax identifier.

You could model the above situation with the following types:

enum CustomerType {
    Individual,
    Institution
}

interface Customer {
    acquisitionDate: Date;
    type: CustomerType;
    firstName?: string;
    lastName?: string;
    socialSecurityNumber?: string;
    companyName?: string;
    companyTaxId?: number;
}

Unfortunately, you have to make most of the fields optional. If you didn't, you would have to fill in all of the fields when creating an instance of Customer. However, you don't want to fill companyTaxId when creating an Individual customer.

The problem with this solution is that it's now possible to create instances that don't make any sense in terms of business domain. For example, you can create an object with too little info:

const customer1: Customer = { 
    acquisitionDate: new Date(2016, 1, 1),
    type: CustomerType.Individual
};

...or one that has too much data provided:

const customer2: Customer = { 
    acquisitionDate: new Date(2016, 1, 1),
    type: CustomerType.Individual,
    firstName: "John",
    lastName: "Green",
    companyName: "Acme",
    companyTaxId: 9243546
};

Wouldn't it be nice if the type system could help us prevent such situations? Actually, this is what TypeScript is supposed to do, right?

Discriminated unions to the rescue

With discriminated unions, you can model your domain with more precision. They are kind of like enum types but can hold additional data as well. Therefore, you can enforce that a specific customer type must have an exact set of fields. Let's see it in action.

interface IndividualCustomerType {
    kind: "individual";
    firstName: string;
    lastName: string;
    socialSecurityNumber: number;
}

interface InstitutionCustomerType {
    kind: "institutional";
    companyName: string;
    companyTaxId: number;
}

type CustomerType = IndividualCustomerType | InstitutionCustomerType;

interface Customer {
    acquisitionDate: Date;
    type: CustomerType;
}

We've defined two interfaces. Both of them have a kind property which is a literal type. Variable of literal type can only hold a single, specific value. Each interface contains only fields that are relevant to the given type of customer.

Finally, we've defined CustomerType as a union of these two interfaces. Because they both have the kind field TypeScript recognizes them as discriminated union types and makes working with them easier.

The biggest gain is that it's now impossible to create illegal instances of Customer. For example, both of the following objects are fine:

const customer1: Customer = { 
    acquisitionDate: new Date(2016, 1, 1),
    type: {
        kind: "individual",
        firstName: "John",
        lastName: "Green",
        socialSecurityNumber: 423435
    }
};

const customer2: Customer = { 
    acquisitionDate: new Date(2016, 1, 1),
    type: {
        kind: "institutional",
        companyName: "Acme",
        companyTaxId: 124345454
    }
};

...but TypeScript would fail to compile this one:

// fails to compile
const customer3: Customer = { 
    acquisitionDate: new Date(2016, 1, 1),
    type: {
        kind: "institutional",
        companyName: "Acme",
        companyTaxId: 124345454,
        firstName: "John"
    }
};

Working with discriminated unions

Let's now see how to implement a function that takes a Customer object and prints the customer's name based on their type.

function printName(customer: Customer) {
    switch (customer.type.kind) {
        case "individual": return `${customer.type.firstName} ${customer.type.lastName}`;
        case "institutional": return customer.type.companyName;
    }
}

As we can see, TypeScript is clever enough to know that inside case "individual" branch of the switch statement customer.type is actually an instance of IndividualCustomerType. For example, trying to access companyName field inside this branch would result in a compilation error. We would get the same behaviour inside an if statement branch.

There is one more interesting mechanism called exhaustiveness checking. TypeScript is able to figure out that we have not covered all of the possible customer types! Of course, it would seem much more useful if we had tens of them and not just two.

// fails to compile
function printName(customer: Customer) {
    switch (customer.type.kind) {
        case "individual": return `${customer.type.firstName} ${customer.type.lastName}`;
        // case "institutional": return customer.type.companyName;
        default: const exhaustiveCheck: never = customer.type;
    }
}

This solution makes use of the never type. Since case "institutional" is not defined, control falls through to the default branch in which customer.type is inferred to be of type InstitutionCustomerType while being assigned to never type which of course results in an error.

Conclusion

Discriminated union types are pretty cool. As I mentioned, the whole point of TypeScript is to help us catch mistakes that we would make without having type checking. Discriminated unions help us model the domain in more detail, therefore making illegal instances impossible to create.

Disclaimer

One could argue that the same thing could be achieved with inheritance (or interface extension in this case). And that's true. Solving this with inheritance would be an Object Oriented Programming approach while discriminated unions are specific to Functional Programming. I think this approach makes more sense in the context of web applications where we often fetch data from some REST API which doesn't support object inheritance. What's more, exhaustiveness checking is not possible to achieve with object inheritance.

It's an example of the classical composition versus inheritance dilemma.

Want to learn more?

Did you like this TypeScript article? I bet you'll also like my book!

⭐️ Advanced TypeScript ⭐️

Becoming a tech public speaker: lessons learned

Milosz Piechocki — Sun, 25 Nov 2018 09:38:04 +0000

This post has been originally published on my blog.

The year is nearing its end, so I'd like to share some things I've learned on my speaker's journey.

I've already written one article on this topic. Read it if you would like to know how (and why) to get into tech public speaking. This post will focus on advice for speakers who already have a little bit of experience.

I made the decision to start speaking publicly almost two years ago - in February 2017. I began with meetups and slowly progressed towards my goal - an international conference - which I managed to achieve in September 2018. During these two years, I gave 11 talks in total.

You can find the full list of my talks here.

Call For Papers

Most importantly, you need to submit a lot. Of course, there are conferences where talks are chosen purely based on the abstract you provide. However, the majority will look at your speaking history, your presence in the web, etc.

So unless you are a core contributor to a popular library or a published author, your chances of getting selected are relatively low (PaperCall.io mentions 1 in 10 on average). Therefore, you need to apply to a lot of conferences hoping to get selected for at least one.

This takes time and effort, but it pays off. In 2018, I applied to almost 30 conferences and got selected to 5 of them.

Topic and abstract

Adjust the topic of your talk to the audience. It's a cliche, but it has some important consequences.

Your topic doesn't have to be super advanced. When applying to general-purpose, multi-track conferences which don't focus on a specific technology, it's perfectly ok to submit an introductory level topic. One of my best-rated talks was an introduction to functional programming in JavaScript at a frontend track of 4 Developers 2018 - a large, multi-tech conference. I think it's generally a good idea to begin with a less advanced topic as such presentation will be easier to deliver.

Conversely, your talk should be a bit more in-depth if you are going to present it at a specialist conference dedicated to a specific tech.

At the conference: before the talk

Your day will be split into two parts: before and after your talk. The shorter the first part, the better - but it's usually something you don't have influence on. Anyway, I used to stress a lot before a talk, which made the first part of the day really unpleasant. However, with time and experience, the time before the talk becomes much less stressful.

I know it's hard, but try not to give up to the stress. Talk to other speakers - those more experienced are usually very friendly. The inexperienced are in the same situation as you, so sharing your anxiety will make it easier to bear. There is a chance that fellow speakers will be sitting in the audience during your talk. You will feel better knowing there is at least one friendly person in the audience. Shout out to Assim Hussain who was really supportive and gave my talk a lot of visibility by twitting it live at Refresh Conference 2018!

Don't rehearse too much on the conference day. One run before leaving the hotel in the morning is enough. By this time, you should already have rehearsed enough.

At the conference: after the talk

Now you can enjoy the rest of the conference! Have some rest and relax a bit. If you still have some energy left, it's a good idea to approach some attendees and talk to them. Ask them how do they like the conference in general. You don't have to directly ask about feedback regarding your talk. Most of the time, the topic will come up anyway. If it doesn't, it's still a great chance to learn the attendee's perspective and see what kind of talks do they like.

BTW, I don't feel comfortable approaching strangers at all. However, it seems to be a learnable skill (same as not getting freaked out before your talk is). I find this guide very helpful in dealing with this.

After the conference

Wait a few days and send an email to the organizers asking about feedback with regards to your talk. Most conferences provide some way of rating talks to the attendees.

The feedback can be a great way to tell what needs improvement and how well did the topic match your audience. However, don't worry too much if you receive some negative, non-constructive remarks. There will always be some haters and it really doesn't mean anything when 2 out of 200 people didn't like your talk.

Now you can decide whether you want to reuse your topic or come up with a new one. I think reusing the topic a few times is perfectly alright. However, I adjust and polish my talk before each conference - based on the feedback, target audience and desired talk duration.

Is it worth it?

Totally! I've already mentioned some benefits of public speaking in the previous article on the topic.

It gets even better when you start going to conferences instead of meetups. When traveling abroad, you will often be reimbursed for the flight and a hotel. You get to meet some seriously experienced speakers and can get a lot of inspiration and advice from them. Most importantly, it's really rewarding and gives you a sense of achievement.

So, if you're wondering whether you're ready for a conference talk - don't hesitate and start applying!

DEV Community: Milosz Piechocki

12 Tips on Becoming a Senior Frontend Engineer

Career Path of a Frontend Engineer

Technical Expertise

Idea #1: Volunteer as a Technical Lead for a new Feature/Project

Idea #2: Improve Developer Experience

Idea #3: Start Monitoring UI Performance

Idea #4: Remove Some Legacy Code

Influencing Product and User Experience

Idea #5: Brainstorm some Product Ideas and Discuss with a PM

Idea #6: Brainstorm some Usability Quick Wins and Discuss with a UX Designer

Idea #7: Instrument the code and provide your PM with some business metrics

Leadership

Idea #8: Lead (one of the) Team Meetings

Idea #9: Triage Incoming Bugs

Idea #10: Identify and Follow-up and Project Dependencies

Idea #11: Propose a Process Improvement

Idea #12: Mentor a Junior Team Member

Non-tech Companies

Summary

TypeScript - Engineering Manager's perspective

The ultimate explanation of TypeScript generics: functions

Motivation

Let's use any!

Generic functions

Calling generic functions

When to use generic functions?

Summary

Want to learn more?

Two cool features coming soon to JavaScript

What's the deal with TC39 proposals?

Optional chaining

Nullish coalescing

How can I use it?

Summary

Want to learn more?

Using React useState hook with TypeScript

Reading the types

Overloads

useState parameters

useState return type

Usage examples

Empty initial state

Clearable state

Summary

Want to learn more?

Typing Higher Order Components in React

Higher Order Components

Problem: passing a generic component to a HOC

Solution: use function components!

Summary

Want to learn more?

Strict function types in TypeScript: covariance, contravariance and bivariance

What bugs can strictFunctionTypes catch?

Covariance, contravariance, and bivariance

Summary

Want to learn more?

5 Commandments for TypeScript programmers

Do not lie

Be precise

Start with types

Embrace strictness

Stay up to date

Summary

Want to learn more?

The meaning of union and intersection types

Simple union types

Union and intersection of object types

Set theory

Relationship between types and sets

Understanding union and intersection types

Real-world example of intersection type

Summary

Want to learn more?

Want to learn more?

Comprehensive list of built-in utility types in TypeScript

List of types

Partial

Required

Readonly

Let's use `any`!

`useState` parameters

`useState` return type

What bugs can `strictFunctionTypes` catch?

`Partial`

`Required`

`Readonly`

`Pick`

`Record`

`Exclude`

`Extract`

`NonNullable`

`Parameters`

`ConstructorParameters`

`ReturnType`

`InstanceType`