The fundamental thing to avoid is overwriting a fields good data, that wasn't downloaded, with a null (or empty string). A null that only exists because the field wasn't downloaded.

The problem with encoding the "don't use the data in this field" signal as a null is that sometimes you want to overwrite good data with a null (or empty string) because it's time for that data to go away.

Well, that, and some fields just can't be null.

This problem can tempt you to split the interface into basic and full varieties. Which will work well right up until you change your mind about what field goes in which.

There is an alternative. Stop insisting this is a type. Treat it like a data structure. JSON is really good at showing you what field wasn't downloaded by simply not including that field. Collections are also good here.

Static types are not good at representing partial data. Data structures are. The rub is now you have to code against a data structure.

That's the most flexible solution. If you don't need that kind of flexibility and you're confident you know what basic and full will be now and forever then stick with static types.

If you insist on static types (because you hate data structures that much) and max flexibility then you're simply going to have to find somewhere to encode that "don't use the data here" flag.

The fundamental thing to avoid is overwriting a fields good data, data that wasn't downloaded, with a null (or empty string). A null that only exists because the field wasn't downloaded.

The problem with encoding the "don't use the data in this field" signal as a null is that sometimes you want to overwrite good data with a null (or empty string) because it's time for that data to go away.

Well, that, and some fields just can't be null.

This problem can tempt you to split the interface into basic and full varieties. Which will work well right up until you change your mind about what field goes in which.

There is an alternative. Stop insisting this is a type. Treat it like a data structure. JSON is really good at showing you what field wasn't downloaded by simply not including that field. Collections are also good here.

Static types are not good at representing partial data. Data structures are. The rub is now you have to code against a data structure.

That's the most flexible solution. If you don't need that kind of flexibility and you're confident you know what basic and full will be now and forever then stick with static types.

If you insist on static types (because you hate data structures that much) and max flexibility then you're simply going to have to find somewhere to encode that "don't use the data here" flag.

The fundamental thing to avoid is overwriting a fields good data, that wasn't downloaded, with a null (or empty string). A null that only exists because the field wasn't downloaded.

The problem with encoding the "don't use the data in this field" signal as a null is sometimes you want to overwrite good data with a null (or empty string) because it's time for that data to go away.

Well, that, and some fields just can't be null.

This problem can tempt you to split the interface into basic and full varieties. Which will work well right up until you change your mind about what field goes in which.

There is an alternative. Stop insisting this is a type. Treat it like a data structure. JSON is really good at showing you what field wasn't downloaded by simply not including that field. Collections are also good here.

Static types are not good at representing partial data. Data structures are. The rub is now you have to code against a data structure.

That's the most flexible solution. If you don't need that kind of flexibility and you're confident you know what basic and full will be now and forever then stick with static types.

If you insist on static types (because you hate data structures that much) and max flexibility then you're simply going to have to find somewhere to encode that "don't use the data here" flag.

The fundamental thing to avoid is overwriting a fields good data, that wasn't downloaded, with a null (or empty string). A null that only exists because the field wasn't downloaded.

The problem with encoding the "don't use the data in this field" signal as a null is that sometimes you want to overwrite good data with a null (or empty string) because it's time for that data to go away.

Well, that, and some fields just can't be null.

This problem can tempt you to split the interface into basic and full varieties. Which will work well right up until you change your mind about what field goes in which.

There is an alternative. Stop insisting this is a type. Treat it like a data structure. JSON is really good at showing you what field wasn't downloaded by simply not including that field. Collections are also good here.

Static types are not good at representing partial data. Data structures are. The rub is now you have to code against a data structure.

That's the most flexible solution. If you don't need that kind of flexibility and you're confident you know what basic and full will be now and forever then stick with static types.

If you insist on static types (because you hate data structures that much) and max flexibility then you're simply going to have to find somewhere to encode that "don't use the data here" flag.