"Si un trabajador quiere hacer bien su trabajo, primero debe afilar sus herramientas." - Confucio, "Las Analectas de Confucio. Lu Linggong"
Página delantera > Programación > Más allá de la seguridad del tipo: análisis del selector de tiempo de ejecución de TypeScript en profundidad

Más allá de la seguridad del tipo: análisis del selector de tiempo de ejecución de TypeScript en profundidad

Publicado el 2025-03-12
Navegar:326

Beyond Type Safety: making TypeScript smarter by Building a Runtime Picker

Descargo de responsabilidad

hey, antes de comenzar, déjame aclarar algo: mientras hablaré mucho sobre mi paquete, ts-runtime-picker , este no es un artículo promocional. Solo estoy compartiendo mi experiencia y el viaje que tomé antes de construirla. ( pero hey , si tienes curiosidad, ¿aquí está el enlace al paquete?).


cómo me llevó a una nueva idea (y un paquete)

vamos a rebobinar un poco. Entonces, he estado trabajando con TypeScript por un tiempo. No me llamaría un profesional de mecanografiado, pero he creado algunos proyectos grandes y trabajé con él en mi empresa. Ya sabes, los proyectos habituales, algunos "hola mundo", algunos un poco más complejos y, por supuesto, una buena parte de los viajes a Google para descubrir "¿Qué diablos significa este error?" o "¿Cómo elijo los campos de una interfaz nuevamente?" (Obtienes el punto.?)

Un día, me encontré con un problema mientras trabajaba con Firebase Cloud Functions. Estaba en el punto final createUser , escribiendo mi lógica de validación, recortando datos y manejando la locura de solicitud de crud habitual. Todo se movía sin problemas hasta que me encontré con este código de un desarrollador anterior:

firebase.collection("users").add(request.data.user);

... y mi Inner TypeScript Pro estaba gritando. ?

quiero decir, vamos , esta era una bandera roja masiva. ¿Bien? Insertar datos de usuario sin filtrar directamente fue arriesgado: ¿qué pasaría si los datos de solicitud no tenían alguna validación y terminamos insertando campos no deseados en la base de datos? No genial.

Rápidamente eliminé el código, pero luego, me congelé por un segundo. ? Miré mi pantalla pensando: "Espera, si solo asigno request.data al tipo de interfaz de usuario, ¿no me impediría hacer algo así? ¿No debería solucionar esto el problema?" (Cue una mirada esperanzadora a mi ide.

pero espera ...? Es solo un cheque en tiempo de compilación, ¿verdad? No existe en tiempo de ejecución. TypeScript es una máscara para el tipo de seguridad, pero en realidad no hace cumplir nada cuando el código se está ejecutando. No

realmente deja de que los campos adicionales se inserten en tiempo de ejecución. Entonces, llamé a uno de mis compañeros de equipo y le pregunté: "Hola hermano, si tenemos un objeto llamado alfabetos con todas las letras en el alfabeto, y creamos una interfaz solo que los pisos que solo permiten las letras 'A' y 'B', ¿qué sucede cuando arrojamos el objeto de alfabetos a esa interfaz?”

// Object con todas las letras de Alphabet const alfabets = { A: 'Apple', B: 'Banana', C: 'Cherry', D: 'Fecha', E: 'Berenjena', F: 'Fig', // ... todo el camino a Z }; // interfaz que solo permite 'a' y 'b' interfaz OnlyTwoletters { a: cadena; B: cadena; } // Casting alfabetos a solo tituletters const filtredalphabets = alfabetos como solo twoletters; console.log (filtredalphabets);

sin perder un ritmo, mi compañero de equipo dijo: "Jaja, bueno, aún obtendrías todas las letras del alfabeto porque TypeScript realmente no puede detener eso en tiempo de ejecución".
// Object with all alphabet letters
const alphabets = {
  a: 'Apple',
  b: 'Banana',
  c: 'Cherry',
  d: 'Date',
  e: 'Eggplant',
  f: 'Fig',
  // ... all the way to z
};

// Interface that only allows 'a' and 'b'
interface OnlyTwoLetters {
  a: string;
  b: string;
}

// Casting alphabets to OnlyTwoLetters
const filteredAlphabets = alphabets as OnlyTwoLetters;

console.log(filteredAlphabets);

Maldición. Lo sabía. Estaba bajo el efecto de la esperanza:

esperando

que el mecanografiado podría evitar que me cometiera errores en tiempo de ejecución. ?

Pero luego, me golpeó: ¿Qué pasaría si TypeScript podría imponer esto en tiempo de ejecución? ¿Qué pasaría si pudiéramos lanzar un objeto a una interfaz específica y tener typeScript eliminar automáticamente

alguna propiedad que no se definiera en la interfaz?

que

resolvería mi problema.

El nacimiento de ts-runtime-picker

Entonces, con este momento de bombilla, pensé: "¿Por qué no hacer esto una realidad?" Si pudiera proyectar Sold.Data a la interfaz de usuario, TypeScript podría ayudarme automáticamente

Eliminar cualquier propiedad adicional, haciendo que el objeto sea seguro para insertar en Firebase. ?

y solo así, nació la idea para ts-runtime-picker

. El objetivo era simple: crear un paquete que permita a los usuarios de TypeScript filtrar propiedades no deseadas de un objeto, basado en los campos definidos en una interfaz específica.

¿la mejor parte? Me salvaría de la validación manual y el filtrado de campos. Atrás quedaron los días de:

const FilteredData = { Nombre: requestData.name, edad: requestdata.age, }; Firebase.Collection ("Usuarios"). ADD (FilteredData); // más trabajo, menos divertido.

const filteredData = {
  name: requestData.name,
  age: requestData.age,
};

firebase.collection("users").add(filteredData);  // More work, less fun.
Cómo funciona: Deje que TypeScript haga su trabajo

con ts-runtime-picker

, todo el proceso está automatizado. Puede lanzar un objeto a una interfaz, y el paquete asegurará que solo se mantengan las propiedades definidas en la interfaz. Así es como funciona en acción:

antes: validación manual

Interface User { Nombre: cadena; Edad: número; } const requestData = {nombre: 'John', edad: 30, dirección: '123 street'}; // Verifique manualmente los campos no deseados: const filtreddata = { Nombre: requestData.name, edad: requestdata.age, }; Firebase.Collection ('Usuarios'). Add (FilteredData); // no muy elegante.

interface User {
  name: string;
  age: number;
}

const requestData = { name: 'John', age: 30, address: '123 Street' };

// Manually check and remove unwanted fields:
const filteredData = {
  name: requestData.name,
  age: requestData.age,
};

firebase.collection('users').add(filteredData);  // Not very elegant.

import {pick} de 'TS-Runtime-Picker'; usuario de interfaz { Nombre: cadena; Edad: número; } const requestData = {nombre: 'John', edad: 30, dirección: '123 street'}; // filtra automáticamente propiedades inexistentes: const safedata = pick (requestData, usuario); Firebase.Collection ('Usuarios'). ADD (Safedata); // ¡mucho más limpio!

¿la mejor parte? Este código es
import { pick } from 'ts-runtime-picker';

interface User {
  name: string;
  age: number;
}

const requestData = { name: 'John', age: 30, address: '123 Street' };

// Automatically filters out non-existent properties:
const safeData = pick(requestData, User);

firebase.collection('users').add(safeData);  // Much cleaner!
por defecto. No hay necesidad de verificaciones manuales o manipulación de objetos. TS-Runtime-Picker lo maneja automáticamente filtrando todos los campos que no existen en la interfaz de usuario. Puede concentrarse en su lógica central sin preocuparse por la inserción accidental de campo. ?

el poder de la pereza (y cómo puede conducir a la innovación)

Entonces, es posible que se pregunte: "¿Esto salió de pura pereza?" Y a eso, digo: sí, pero también, no.

?

Claro, la chispa inicial de la idea vino de que yo fuera un poco perezosa; no quería filtrar manualmente los campos cada vez que necesitaba insertar datos. Pero bueno, ¡a veces la pereza conduce a la brillantez! El deseo de facilitar las cosas

puede ser una fuerza impulsora para la innovación.

de hecho, a pesar de la "pereza" inicial, gasté 8 horas

construyendo el paquete. Sí, eso es correcto. ?

Pero así es como va a veces. "La necesidad da a luz a la invención", y esta necesidad de evitar los controles repetitivos tediosos me llevó a una nueva solución que finalmente me hizo la vida (y con suerte la vida de muchos otros) mucho más fáciles.

Entonces, mientras puedo

culpar

perezoso por hacer rodar la pelota, era la necesidad de resolver el problema que dio lugar a

ts-runtime-picker . Y así es como a veces, estar atascado o perezoso no es necesariamente algo malo, ¡es el lugar de nacimiento de algo nuevo y útil!

Conclusión

y esa es la historia detrás del paquete ts-runtime-picker

. Un viaje desde la frustración mecanografiada hasta la creación de una herramienta que resuelva un problema real. Este paquete es mi forma de ayudar a los usuarios de TypeScript a aprovechar al máximo la seguridad del tipo, no solo durante el desarrollo sino también en tiempo de ejecución.

Si está cansado de filtrar manualmente los campos o preocuparse de que los datos no deseados se metan, dan ts-runtime-picker

una toma. Es una cosa menos de qué preocuparse, y hace que trabajar con TypeScript sea un poco más inteligente. ?

Declaración de liberación Este artículo se reproduce en: https://dev.to/hichemtab-tech/beyond-type-safety-raking-typescript-smarter-by-building- a-runtime-picker-26d5?1 Si hay alguna infracción, comuníquese con [email protected] para eliminarlo.
Último tutorial Más>

Descargo de responsabilidad: Todos los recursos proporcionados provienen en parte de Internet. Si existe alguna infracción de sus derechos de autor u otros derechos e intereses, explique los motivos detallados y proporcione pruebas de los derechos de autor o derechos e intereses y luego envíelos al correo electrónico: [email protected]. Lo manejaremos por usted lo antes posible.

Copyright© 2022 湘ICP备2022001581号-3