Solución:
Si bien es cierto que el readonly El modificador de TypeScript solo existe en el tipo de diseño y no afecta el código de tiempo de ejecución, esto es cierto para todo el sistema de tipos. Es decir, nada te detiene en tiempo de ejecución de asignar un número a una variable de tipo string. Entonces esa respuesta es una especie de pista falsa … si te advierten en el momento del diseño que estás tratando de mutar algo marcado como const o readonly, entonces eso posiblemente eliminaría la necesidad de una comprobación exhaustiva del tiempo de ejecución.
Pero hay una razón importante por la que readonly es insuficiente. Hay un problema pendiente con readonly, que es que actualmente (a partir de TS3.4), los tipos que difieren solo en su readonly los atributos son mutuamente asignables. Lo que te permite atravesar fácilmente el protector readonly cáscara de cualquier propiedad y lío con las entrañas:
type Person = { name: string, age: number }
type ReadonlyPerson = Readonly<Person>;
const readonlyPerson: ReadonlyPerson = { name: "Peter Pan", age: 12 };
readonlyPerson.age = 40; // error, "I won't grow up!"
const writablePerson: Person = readonlyPerson; // no error?!?!
writablePerson.age = 40; // no error! Get a job, Peter.
console.log(readonlyPerson.age); // 40
Esto es bastante malo para readonly. Hasta que eso se resuelva, es posible que esté de acuerdo con un archivador de problemas anterior que originalmente había llamado al problema “los modificadores de solo lectura son una broma”.
Incluso si esto se resuelve, readonly puede que no cubra todos los casos de uso. También necesitaría recorrer todas las interfaces y tipos en sus bibliotecas (o incluso las bibliotecas estándar) y eliminar los métodos que mutan el estado. Entonces todos los usos de Array necesitaría ser cambiado a ReadonlyArray y todos los usos de Map necesitaría ser cambiado a ReadonlyMap, etc. Una vez que haya hecho esto, tendrá una forma bastante segura de representar la inmutabilidad. Pero es mucho trabajo.
De todos modos, espero que eso ayude; ¡buena suerte!
El propósito de Immutable.js no es para evitar que un desarrollador realice una mutación ilegal en tiempo de compilación. Proporciona una API conveniente para crear copias de un objeto con algunas de sus propiedades cambiadas. El hecho de que obtenga seguridad de tipo en los objetos que administra con immutable.js es básicamente un efecto secundario de su uso.
TypeScript es “solo” un sistema de mecanografía. No implementa ninguna de las características. Immutable.js hace para hacer copias de objetos inmutables. Todo lo que hace, al declarar una variable como readonly, es comprobar en tiempo de compilación que no lo mute. La forma en que diseña su código para manejar la inmutabilidad no es el alcance de un sistema de mecanografía y aún necesitaría una forma de lidiar con él.
React asegura la inmutabilidad proporcionando un método setState en lugar de mutar el objeto de estado directamente. Se encarga de fusionar las propiedades modificadas por usted. Pero si, por ejemplo, usa redux, es posible que también desee una solución conveniente para manejar la inmutabilidad. Eso es lo que Immutable.js proporciona y mecanografiado nunca lo hará y es independiente de si le gusta la API o no.