A generic hook for useState and Immer

While prospecting the use of useState with the great Immer, I ended up finding the small use-immer package, which unifies both things. However, it doesn’t have proper TypeScript typings.

So I wrote my own hook to perform this task: just like useState, it returns a value and a setter, but the setter’s argument is a mutable state, automatically wired to produce, and all that using a generic argument for proper typing:

import {useCallback, useState} from 'react';
import {Draft, produce} from 'immer';

export function useStateImmer<T>(initialState: T | (() => T)): [
	T,
	(updater: (draft: Draft<T>) => void) => void,
] {
	const [obj, setObj] = useState(initialState);
	const setObjProduce = useCallback((updater: (draft: Draft<T>) => void): void => {
		setObj(curState => {
			return produce(curState, draft => {
				updater(draft);
			});
		});
	}, [setObj]);
	return [obj, setObjProduce];
}

Note that the returned setter function is identity, since it’s guarded by an useCallback call.

Java Either class

Today, at work, I had the dire need of discriminated unions in Java, which of course doesn’t support it. Then I found the idea of the Either type, which I implemented myself using the Optional class from Java 8:

import java.util.Optional;
import java.util.function.Consumer;
	
/**
 * Guarda 3 elementos mutuamente exclusivos, isto é, apenas 1 dos 3 pode existir
 * dentro do objeto.
 */
public class Either3<T1, T2, T3> {
	
	private Optional<T1> v1 = Optional.empty();
		
	private Optional<T2> v2 = Optional.empty();
		
	private Optional<T3> v3 = Optional.empty();
	
	/** Cria um objeto com o valor do tipo 1. */
	public static <<1, T2, T3> Either3<T1, T2, T3> of1(T1 v1) {
		Either3<T1, T2, T3> obj = new Either3<>();
		obj.v1 = Optional.of(v1);
		return obj;
	}
	
	/** Cria um objeto com o valor do tipo 1. */
	public static <T1, T2, T3> Either3<T1, T2, T3> of2(T2 v2) {
		Either3<T1, T2, T3> obj = new Either3<>();
		obj.v2 = Optional.of(v2);
		return obj;
	}
	
	/** Cria um objeto com o valor do tipo 1. */
	public static <T1, T2, T3> Either3<T1, T2, T3> of3(T3 v3) {
		Either3<T1, T2, T3> obj = new Either3<
		obj.v3 = Optional.of(v3);
		return obj;
	}
	
	/** Retorna o valor do tipo 1; caso não exista, lança {@code NoSuchElementException}. */
	public T1 get1() {
		return v1.get();
	}
	
	/** Retorna o valor do tipo 2; caso não exista, lança {@code NoSuchElementException}. */
	public T2 get2() {
		return v2.get();
	}
	
	/** Retorna o valor do tipo 3; caso não exista, lança {@code NoSuchElementException}. */
	public T3 get3() {
		return v3.get();
	}
	
	/** Diz se o objeto possui um valor do tipo 1. */
	public boolean has1() {
		return v1.isPresent();
	}
	
	/** Diz se o objeto possui um valor do tipo 2. */
	public boolean has2() {
		return v2.isPresent();
	}
	
	/** Diz se o objeto possui um valor do tipo 3. */
	public boolean has3() {
		return v3.isPresent();
	}
	
	/** Executa a função caso haja um valor do tipo 1. */
	public void if1(Consumer<? super T1> consumer) {
		v1.ifPresent(consumer);
	}
	
	/** Executa a função caso haja um valor do tipo 2. */
	public void if2(Consumer<? super T2> consumer) {
		v2.ifPresent(consumer);
	}
	
	/** Executa a função caso haja um valor do tipo 3. */
	public void if3(Consumer<? super T3> consumer) {
		v3.ifPresent(consumer);
	}
}

Since Java doesn’t have variadic generic parameters, having one class to each amount is needed. Nonetheless, it’s doable and remarkably ergonomic.

Using Zustand, TypeScript and Immer together

In React land, Redux nightmare finally came to an end with the inception of Zustand, which throws away all the chores we had to previously do, leaving us with a simple workflow of minimal code. On top of that, TypeScript allows us to relax our brains with some degree of strong typing.

When dealing with our Zustand store, just like Redux, we have to manipulate a chunk of immutable data, which becomes more and more annoying as we deepen the object structure. And, when it comes to dealing immutable data, Immer is everyone’s best friend – just slap a produce call and you can go home earlier.

Now here comes the question: how to use Immer inside our Zustand store?

Turns out Zustand provides a few middlewares – functions which lie between the data and your manipulation functions –, and among them an Immer middleware. Using the middleware has two advantages:

• you don’t need to explicitly call produce, because the state argument already comes to you as a WritableDraft;
• you don’t need to explicitly type the state argument, because it already comes to you properly typed.

To put everything together, with automatic type inference, we also need the combine middleware, so we don’t need to write the store type by hand. Here is the full template that can be used as the starting point of your store:

import {create} from 'zustand';
import {combine} from 'zustand/middleware';
import {immer} from 'zustand/middleware/immer';

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

const useStore = create(immer(
	combine({
		people: [] as Person[],
	},
	(set, get) => ({
		add(name: string, age: number) {
			set(state => {
				state.people.push({name, age});
			});
		},
		remove(name: string) {
			set(state => {
				state.people = state.people.filter(p => p.name === name);
			});
		},
	})),
));

export default useStore;

Notice how you can simply mutate the state inside the actions.

TypeScript map for objects

In another round of React experiments, after another Vue frustration with Volar not typing event arguments, I was again into the state normalization land. When dealing with objects with IDs as keys, every operation requires a tedious reduce, in contrast to the intuitive map we use with arrays.

So I wrote a map for objects:

function mapObj<T>(obj: Record<string, T>, callback: (elem: T, key: string) => T): Record<string, T> {
	return Object.keys(obj).reduce((accum, key) => {
		accum[key] = callback(obj[key], key);
		return accum;
	}, {} as Record<string, T>);
}

It’s fully typed, and it was surprisingly easy to write. TypeScript is a great language.

Testing GitHub pull requests before merging

My personal projects on GitHub oftentimes. It’s very flattering when other people get interested in your personal work, and actively use it. GitHub pull request is how other people suggest changes to our code.

Pull requests can be merged in GitHub with just one click, but it’s also possible – and recommended – trying the changes locally first. The usual way to do this is creating a local branch, then pulling the modified code onto it.

As an example, let’s take pull request #75 of WinSafe. We create another branch called foo and check the pull request onto it by using:

git fetch origin pull/75/head:foo
git checkout foo

Simple enough, and for some reason it took me years to try this for the first time today.

Fetch calls with global Jotai object

Zustand is a great React state management library, but it has the drawback of not having a standard way to define getters, which must be defined as ordinary hooks.

Written by the same author, Jotai seems to be the answer to this situation. However, while Zustand provides a way to change the state outside React components, Jotai does not. Today I was able to devise a way to work around this, by simply applying the hooks concept, answering my own question:

const errorAtom = atom(''); // storage

const errorReadAtom = atom(get => { // read-only (computed)
	return 'Error: ' + get(errorAtom);
});

const writeErrorAtom = atom(null, (get, set, arg: string): void => { // setter
	set(errorAtom, arg);
});

function useGet(): (url: string) => Promise {
	const [, setError] = useAtom(errorAtom);
	return async (url: string): Promise => {
		const resp = await fetch(url);
		const json = await resp.json();
		setError('Hello');
		return json as T;
	};
}

Usage:

function App() {
	const doGet = useGet();

	async function click(): void {
		const data = await doGet('/foo');
	}

	return <button onClick={click}>Click</button>;
}

So, with Jotai I finally have the complete solution to state management in React.

The three rules of lifetime elision in Rust

While reviewing some Rust fundamentals, I stumbled across this excellent video about lifetimes. What caught my attention the most was the “three rules” of lifetime elision – a topic I had some idea about, but I’ve never seen clearly explained.

For reference, they are:

• Each parameter that is a reference gets its own lifetime parameter;
• If there is exactly one input lifetime parameter, that lifetime is assigned to all output lifetime parameters;
• If there are multiple input lifetime parameters, but one of them is &self or &mut self, the lifetime of self is assigned to all output lifetime parameters.