El uso del Null y Undefined en la definición y envío de data (Angular - TypeScript)

Regularmente cuando desarrollamos aplicaciones que reciben y envían data al backend, tenemos al menos un proceso en el cuál preparamos la data para su parseo hacia un formulario o template o su envío al backend.
Soy consciente que esta propuesta en cierta forma es debatible, por lo cuál resulta una suerte de opinión sobre el tratamiento de la información, para colocarnos en contexto debemos de tener en cuenta las definiciones del null y undefined.

Null - definición:

El Valor null es un literal de Javascript que representa intencionalmente un valor nulo o "vacío". (MDN)

Undefined - definición

Una variable a la que no se le ha asignado valor, o no se ha declarado en absoluto (no se declara, no existe) ... (MDN)

Con ambas definiciones en cuenta podemos decir en resumen qué, aunque en la práctica indiquen la ausencia de valor, null agrega un sentido de intencionalidad la ausencia de dicho valor; esto resulta útil, en el control del código que realizamos en el sentido de ser conscientes de lo que envíamos

Ahora bien supongamos que tenemos el siguiente método senData que se recibe como argumento el form.value de un formulario reactivo en Angular que envía los datos al backend a través de un servicio.

sendData(model: T): void {
   this.servicio.enviar(model).subscribe(...)
} 

El servicio recibe enteramente el objeto, tenemos una fe ciega de lo que se envía. En mi opinión resulta más saludable controlar el envío ya sea desde la inicialización o del método que prepara la data de envío; la inicialización indica el momento en el que en un formulario se define e inicializa el formControl

z:FormControl = new FormControl(null)

O del método preparativo

senData(model:T):void {
 const dataToSend: T = {
     a:model.a ?? null,
     b: +(model.b ?? null),
}

this.servicio.enviar(dataToSend).subscribe(...)

}

Y es que este ejercicio trae un trasfondo, al ser conscientes de la data que deseamos enviar también realizamos los parseos adecuados de la data.

Y en definitiva, también puede resultar en que decantes en que el diseño de las propiedades del objeto que envías no sea el más adeacuado, ¿Por qué enviar elementos que el backend no requiere?, ¿O cómo tratamos los datos sensibles?, y ahí es donde evolucionamos hacia los DTO's (próximo post)