How to deal with optional data in a typed domain model?

Question

When developing applications / domain models in general, I am wondering what would be the best way to deal with incomplete or optional data. Typed languages such as TypeScript and C# give us the power of typing our models. Sometimes this is powerful, as it put constraints on our model and can force it to be integer. However, usually, real-life data is incomplete and that appears to reduce the advantages of typing constraints drastically.

Imagine a simple data model in a sample application (TypeScript frontend and some backend) of an entity called Project which has an id, a name and an optional description. The data is retrieved from a backend.

The data model is defined in the frontend using interfaces:

export interface IProject {
    id: number;
    name: string;
    description: string;
}

The data is retrieved from the backend as follows:

export class ProjectService {
    public getProject(projectId: number): Observable<IProject> {
        const url = 'http://server/api/project/' + projectId;
        return this.httpClient.get<IProject>(url);
    }
}

Example response of a project which actually has a description.

{
    "id": 1
    "name": "My first project",
    "description": "My first project is just a demo"
}

In the frontend application we display the retrieved data. For example, let's display the first 10 characters of the project description.

alert(project.description.substr(0,10));

So far, everything fine.

But imagine that our user created "Project two" without filling in the optional description. Now the backend can respond with:

{
    "id": 2
    "name": "Project two"
}

or

{
    "id": 2
    "name": "Project two",
    "description" : null
}

Now we get a null-reference exception in the frontend: Cannot read property 'substr' of null. Of course it's possible to add an if statement that checks for the description to be null:

if(project.description) {
  alert(project.description.substr(0,10));
}

This works, but it means adding null checks across the whole application. The whole code base would be full with those checks, along with the dangers of masking bugs instead of preventing them. That just does not feel right to me.

A possible solution could be to always return a description, hence returning an empty string if none was filled in.

{
    "id": 2
    "name": "Project two",
    "description": ""
}

Now the frontend does not need null checks for description any more, but it is no longer possible to distinguish between an explicitly filled-in empty description and a not(-yet) filled-in description.

What is the best way to deal with these kind of problems? The example above is just to illustrate, the scope is quite generic. It seem to plague all typed languages in which a typed contract/interface is defined which cannot always be fulfilled.

Answer 1

In C# 8 you can use Nullable Reference Types to explicitly mark the description field as being optional¹:

class Project
{
    public int Id { get; set; }
    public string Name { get; set; }
    public string? Description { get; set; }
}

Here, we declare Description as a string? -- a string which may be null. Then, whenever we try and call a method on Description which first checking it for null, the compiler will give us a warning.

C# also gives you syntax for working with null. For example, if you wanted to get the first 10 characters of the description but return an empty string if the description is null, you can write:

project.Description?.Substring(0, 10) ?? "";

(Note that this will throw if your description not null, but is less than 10 characters long, so you'll need some extra logic here in practice).

It looks like Typescript has similar concepts.

---

¹ This class will give you a warning because Name isn't nullable, but it's also not initialised. There are a few ways of solving this: give it a default value of ""; give Project a constructor which sets Name; forcefully break the non-nullable contract for a short period before the type is deserialized by assigning null!; some others.