Safety Conventions

Last updated Sep 29, 2022

We want to prevent null values from making their way to places they shouldn’t, that’s why we have null handling in place. If something could possibly be null, it must be handled as if it is guaranteed to sometimes be null.

In our eslint we forbid use of the null-forgiving operator (!) when used to declare that a nullable value is not null as we want to have strict null handling. This operator is however sometimes very important.

The convention when using it can be seen in the following example:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

public getOrSet(key: K, defaultFn: () => V): V
{
	if (this.has(key))
		// SAFETY: We have just verified that this object does exist.
		// eslint-disable-next-line @typescript-eslint/no-non-null-assertion
		return this.get(key)!;
	const val = defaultFn();
	this.set(key, val);
	return val;
}

In this example, we know for a fact that we have the key, as we just checked it the line before, so what we do is first disable the eslint rule for that line - thenput a comment above it starting with SAFETY: with an explanation following with why the usage of the operator is still safe.

The idea is that its usage is very clearly documented and if we later discover a bug as a result of the operator being used - we will know what the author was thinking at the time and what they overlooked. By extension, the little extra time spent when writing it should save us a lot of time later should something go wrong.

We use results where we can to let us handle success/failure code paths as normal values.

TODO: FILL THIS OUT

We write tests to ensure that our code works the way we expect, and that any new changes don’t break old behaviours. All bugs that we fix should also have tests written for them to prevent us re-introducing those same bugs in the future.

Some of the following links help give a good overview when it comes to auto-testing React Native apps.

• Testing React native Apps
• React Native Testing Overview