butaud

How to think about nullability in Typescript

A lot of time people approach Typescript with the mindset that it's halfway between an untyped language like Javascript and a traditional statically typed language. That might be true in some ways, but when it comes to nullability, Typescript (the way it's typically used) is actually much more strict/expressive than traditional languages like C, Java, and C#, and you might be led astray if you don't take that into account.

Javascript vs C# vs Typescript

In Javascript, values are completely untyped and you can of course assign any value to any variable or parameter, including null and undefined. There is no compiler, and if you want your code to be protected against invalid values you will have to write your own runtime checks.

In C# (and other traditional statically typed languages), at least before recent null-checking contexts, any reference type accepts null. This goes back to C where a reference type value is represented with a pointer, and `null

butaud

useQuery semantics

On my team, we've had some confusion lately about the behavior of useQuery and how the fetchPolicy parameter influences it. Looking back through the Apollo documentation, I think it just doesn't do a very good job of explaining some of these subtleties, but the behavior itself is logical once you have the right mental model of what the hook is supposed to do.

useQuery is a description, not an operation

Some of the confusion around useQuery's behavior comes from thinking of it as an operation, something that you call to execute a specific query. But this isn't the right way to think about it - instead, you should think of it as a way to tell Apollo that a particular instance of a component is associated with a particular query. Apollo will, of course, fetch the query data and provide the results to the component, but the timing and frequency of the actual fetch depends on the lifecycle of the component, not on the number of times useQuery is called during render passes.

If this se

butaud

Sandbox with examples for mount/unmount and memoization

My team was having some discussions internally around the different patterns and anti-patterns and how they affect component re-renders, memoization, and unmounting/remounting. I wanted to look at some really simple live examples to make sure I understood things correctly, so I put together this sandbox here: https://codesandbox.io/s/cool-grass-wjxvz8

You can choose either the set of mount/unmount examples or memoization examples from the dropdown at the top, then click the button to trigger re-rendering the top level component, and use the automatically included react-render-tracker to observe how each child component updates from there. Look in MemoizationExampleApp.js and MountUnmountExampleApp.js to see how each example component is defined.

Please let me know if you have questions about how the code works, or suggestions for other examples that should be added. Also note that you can

butaud

Against unnecessary boolean casting

tl;dr: Don't use !! in Javascript for conditions - instead, embrace "truthiness".

When is casting to boolean unnecessary?

Everyone knows that you can use !! to convert a value in Javascript to a Boolean based on the "truthiness" of the value. This is often necessary in Typescript when you need to set something typed as boolean based on whether some other value is defined. Here's a typical example:

But casting in this way is unnecessary when the purpose is to use the value in a conditional, like in this example:

butaud

Controlled/uncontrolled state in React components

I wanted to share some things that I've learned recently about the "controlled/uncontrolled state" patterns in React components, especially Fluent components. Not having a clear understanding of these things up front caused us some confusion in some recent work items for left rail and grid view.

Definition

I'm just taking the terminology that the React documentation uses to talk about form controls (controlled vs uncontrolled). Suppose you have a component that has multiple visual states. For simplicity, say it renders a checkbox that is either checked or unchecked. The checked state is uncontrolled if the component manages it internally. The checked state is controlled if it is passed in by a prop. Since a component can't change its own props, that means that the state then needs to be managed by a parent component.

Usage

S