DEV Community: David Garcia

🧩 Understanding Why Omit and Pick Fail with Union Types

David Garcia — Wed, 07 May 2025 07:16:34 +0000

Omit and Pick are some of the most loved utility types in TypeScript. They let you create new types by excluding or selecting specific properties from an existing type.
However, when you use them with union types, their behavior can be misleading - and in some cases, break your type expectations

type Employee = {
 id: string
 name: string
 job_name: string
}
type Customer = {
 id: string
 name: string
 company: string
}
type Person = Employee | Customer

❌ Problem: Using Omit Directly
Suppose you want to remove the id field from all personas:

type PersonWithoutId = Omit<Person, 'id'>

🧨 Actual Result:

type PersonWithoutId = {
 name: string
}

Only name survives. The fields job_name and company are lost.

Why?
Because Omit is not distributive over union types. It collapses the union into a common structure, then removes the property - resulting in a simplified, lossy type.

✅ Solution:

DistributiveOmit

We can fix this by explicitly distributing Omit across each union member:

type DistributiveOmit<T, K extends PropertyKey> = T extends any
 ? Omit<T, K>
 : never

type PersonWithoutId = DistributiveOmit<Person, 'id'>

✅ Expected Result:

type PersonWithoutId =
 | { name: string; job_name: string }
 | { name: string; company: string }

🧪 Same Fix for Pick

type DistributivePick<T, K extends keyof T> = T extends any
 ? Pick<T, K>
 : never

type BasicaPerson = DistributivePick<Person, 'id' | 'name'>

🧠 Summary Table

🔎 Do you know the Sensors panel in DevTools?

David Garcia — Thu, 20 Feb 2025 11:28:31 +0000

🔄 How to use it:

Open DevTools (F12 or Ctrl+Shift+I in Chrome).
Go to the More tools > Sensors tab.

1️⃣ Override Geolocation

Simulates the user’s location anywhere in the world.

Example: If you’re developing a location-based app, you can test how it behaves in New York, Tokyo, or Buenos Aires without moving.

2️⃣ Simulate Device Orientation

Modifies accelerometer and gyroscope values to test device rotation changes.

Example: If you’re building an augmented reality app or a responsive website, you can check how it behaves when rotating the device.

3️⃣ Force Touch Events

Simulates touch interactions on mobile devices.

Example: If you’re optimizing touch gestures (swipes, pinches, long presses), you can test them without a physical device.

4️⃣ Emulate an Inactive Sensor

Simulates disabled or inactive sensors, such as proximity detection.

Example: Useful for testing how an app behaves when certain sensors are unavailable on the user’s device.

👉 Have you tried these options in your projects? 🚀

ℹ️ More info on Google’s website:
https://developer.chrome.com/docs/devtools/sensors?hl=en

🧹 Remove them with a single Fish Shell command:

David Garcia — Wed, 19 Feb 2025 06:09:39 +0000

1️⃣ Save the following script in:
📂 .config/fish/functions/git-delete-branches.fish

2️⃣ Execute the command:

git-delete-branches "<regex>"

🔹 Finds and deletes local/remote branches matching a regex.
🔹 Asks for confirmation to avoid surprises.
🔹 Saves time and keeps your repo clean.

📌 Full code and explanation 👉

⚡ Master WebStorm with these key shortcuts to navigate and edit faster!

David Garcia — Mon, 17 Feb 2025 20:43:27 +0000

If you use JetBrains, these shortcuts will make you fly through your.

You can find them in the Keymap settings:

🔹 Jump between functions
Path: Main Menu → Navigate → Navigate in File → Next Method

🔹 Move between changes in a file
Path: Main Menu → Navigate → Navigate in File → Change Navigation Actions → Previous Change

🔹 Navigate references without Ctrl + F
Path: Main Menu → Edit → Find Usages → Next Highlighted

🔹 Return to the last edit location
Path: Main Menu → Navigate → Last Edit Location

🔹 Quickly select text (closer to the function closure = more selection)
Path: Editor Actions → Extend Selection

Did you know these? 🚀

💡 5 little-known Git commands that will improve your workflow.

David Garcia — Wed, 12 Feb 2025 07:23:29 +0000

There's more to Git than commit, merge and checkout. Here are 5 commands that can make your life easier:

1️⃣ git switch - Switch branches without risk.

Before Git 2.23, git checkout did too many things: switch branches, restore files and more. Now, git switch is a clearer and safer option:

git switch feature-branch # Switch to an existing branch
git switch -c new-branch # Creates and switches to a new branch

No more fear of overwriting files by mistake.

2️⃣ git restore - Revert changes without hassles

To undo changes without modifying the branch or history:

git restore file.js # Discards uncommitted changes  
git restore --staged file.js # Removes changes from the staging area

Avoid errors with checkout and reset, better separating operations.

3️⃣ git maintenance - Keep your repo fast and clean

Large repos can get slow. git maintenance automates cleanup:

git maintenance start # Triggers automatic maintenance  
git maintenance run # Runs optimization tasks

Reduces git status, fetch and log time effortlessly.

4️⃣ git sparse-checkout - Work in monorepos without downloading everything

If you only need certain folders from a giant repo:

git sparse-checkout init  
git sparse-checkout set directory1/ directory2/

Download only what you need and save disk space.

5️⃣ git worktree - Work on several branches without changing directory

If you need to work on different branches without stashing or changing folders:

git worktree add ../feature-branch feature-branch  
cd ../feature-branch

Ideal for revising code without affecting your main branch.

Translated with www.DeepL.com/Translator (free version)

💡 5 comandos de Git poco conocidos que mejorarán tu flujo de trabajo

David Garcia — Wed, 12 Feb 2025 07:20:34 +0000

Git tiene más que commit, merge y checkout. Aquí tienes 5 comandos que pueden hacerte la vida más fácil:

1️⃣ git switch - Cambia de rama sin riesgos

Antes de Git 2.23, git checkout hacía demasiadas cosas: cambiaba de rama, restauraba archivos y más. Ahora, git switch es una opción más clara y segura:

git switch feature-branch  # Cambia a una rama existente
git switch -c nueva-rama   # Crea y cambia a una nueva rama

Ya no hay miedo de sobrescribir archivos por error.

2️⃣ git restore - Revierte cambios sin complicaciones

Para deshacer cambios sin modificar la rama o el historial:

git restore archivo.js         # Descarta cambios no confirmados  
git restore --staged archivo.js # Quita cambios del área de staging

Evita errores con checkout y reset, separando mejor las operaciones.

3️⃣ git maintenance - Mantén tu repo rápido y limpio

Los repos grandes pueden volverse lentos. git maintenance automatiza la limpieza:

git maintenance start  # Activa el mantenimiento automático  
git maintenance run    # Ejecuta tareas de optimización

Reduce el tiempo de git status, fetch y log sin esfuerzo.

4️⃣ git sparse-checkout - Trabaja en monorepos sin descargar todo

Si solo necesitas ciertas carpetas de un repo gigante:

git sparse-checkout init  
git sparse-checkout set directorio1/ directorio2/

Descarga solo lo necesario y ahorra espacio en disco.

5️⃣ git worktree - Trabaja en varias ramas sin cambiar de directorio

Si necesitas trabajar en diferentes ramas sin hacer stash o cambiar de carpeta:

git worktree add ../feature-branch feature-branch  
cd ../feature-branch

Ideal para revisar código sin afectar tu rama principal.

Beyond Code: The Role of a Software Developer/Architect

David Garcia — Mon, 10 Feb 2025 06:13:15 +0000

Being a software architect is not just about defining technical structures but also about making life easier for your team. It is a technical leadership role that balances vision, development, and collaboration. Here are some key principles I apply and consider essential for a software architect:

🔹 Constant Migration:
No technical debt: Don’t postpone framework and library updates (always migrate to stable versions). Keep everything up to date in each sprint to prevent future bottlenecks and ensure smooth development.

🔹 Refactor within the Sprint:
Clean code—don’t put off until tomorrow what you can do today. AI can be your ally.
Help the team understand why clean code makes their lives easier. Refactor with the team, not for the team.
Incremental refactoring prevents technical debt accumulation and improves code maintainability. If another developer joins the project, it should be a great place to work, not a maze of obsolete code.

🔹 Explore and Automate:
Don’t wait for perfect tools. If you see someone performing repetitive tasks, ask yourself if they can be automated.
Create simple tools that save the team time.
Share and teach how to use these automations.
Don’t overcomplicate things—sometimes a simple script is better than an elaborate solution.

Some useful script examples:

Auto-merge in Jenkins to prevent unnecessary development flow blockages.

Automatic task generation in Jira with predefined assignments.

Release process automation to reduce manual errors and accelerate deployments.

🔹 Teamwork:

Support the team daily with mentorship and technical guidance.

Encourage collaborative challenges. Solving a task together improves solutions and fosters learning.

Promote effective communication and knowledge sharing among team members. For example, organize a meeting to explain how you plan to solve something or how you’ve solved it, discussing the pros and cons—not just the final result.

Remember that everyone has something valuable to contribute. Listen to and appreciate all team members' opinions.

🔹 Learning Culture:

Share what you learn, no matter how small (even a simple shortcut can save hours of development).

Learn from everyone, even juniors—they are often up to date with the latest trends.

Don’t be afraid to say, "I don’t know, but we can figure it out together."

Celebrate curiosity and the desire to learn.

🔹 IDE Productivity:
Mastering shortcuts and functionalities in your development environment is crucial. Many underestimate what a good IDE or customized setup can do for speed and efficiency. Tools like WebStorm (which I personally find much better than VSCode) or advanced Neovim customization can significantly enhance productivity. (I’ve been using Neovim for a couple of months and am still adapting).

🔹 Long-Term Thinking:
A good software architect should design with scalability, maintainability, and flexibility in mind. The technical decisions made today will impact the product’s lifespan in the future.

🔹 Adaptability and Continuous Learning:
Technology evolves constantly. Stay up to date with new trends, frameworks, and best practices. Experimenting and learning is a fundamental part of the role.

An architect must balance technical vision, code, and collaboration. What other skills do you think are essential for this role? 🚀

Más Allá del Código: El Rol de un Desarrollador/Arquitecto de Software

David Garcia — Mon, 10 Feb 2025 05:59:59 +0000

Ser arquitecto de software no es solo definir estructuras técnicas, sino facilitar la vida de tu equipo. Es un rol de liderazgo técnico que equilibra visión, desarrollo y colaboración. Algunas claves que aplico y pienso que son esenciales para un arquitecto de software son:

🔹 Migración constante: No deuda técnica: No dejes la actualización del framework y librerías “para después” (siempre migraciones de versiones estables) y actualiza en cada sprint para evitar bloqueos futuros y asegurar un desarrollo fluido.

🔹 Refactoriza en el sprint: Código limpio, no dejes para mañana lo que puedas hacer hoy. La IA será tu buen aliado. Ayuda al equipo a entender por qué el código limpio les hace la vida más fácil. Refactoriza con el equipo, no para el equipo. La refactorización incremental evita la acumulación de deuda técnica y mejora la mantenibilidad del código. Si otro desarrollador cae en el proyecto, que sea un buen lugar para trabajar, no un laberinto de código obsoleto.

🔹 Explora y automatiza: No esperes herramientas perfectas. Si ves que alguien hace algo repetitivo, pregúntate si se puede automatizar. Crea herramientas simples que ahorren tiempo al equipo. Comparte y enseña cómo usar estas automatizaciones. No compliques las cosas; a veces un script simple es mejor que una solución elaborada.

Algunos ejemplos de scripts útiles:

Auto-merge en Jenkins para evitar bloqueos innecesarios en el flujo de desarrollo.
Generación automática de tareas en Jira con asignaciones predefinidas.
Automatización del proceso de release para reducir errores manuales y acelerar despliegues.

🔹 Trabajo en equipo: Apoya al equipo en el día a día con mentoría y acompañamiento técnico.
Fomenta retos colaborativos. Resolver una tarea entre varios mejora las soluciones y fomenta el aprendizaje.
Promueve la comunicación efectiva y el intercambio de conocimientos entre los miembros del equipo. Por ejemplo, organiza una reunión y explica cómo piensas resolver algo o cómo lo has resuelto, junto con sus pros y contras, no solo el resultado final.
Recuerda que cada persona tiene algo valioso que aportar. Escucha y valora las opiniones de todos los miembros del equipo.

🔹 Cultura de aprendizaje: Comparte lo que aprendes, por pequeño que sea (un simple atajo, por ejemplo, puede ahorrarte horas de desarrollo).
Aprende de todos, incluso de los más júniors, muchas veces están al tanto de las últimas tendencias.
No tengas miedo de decir “no sé, pero podemos averiguarlo juntos”.

🔹 Productividad en el IDE: Dominar atajos y funcionalidades del entorno de desarrollo es clave. Muchos subestiman lo que un buen IDE o configuración personalizada puede hacer por su velocidad y eficiencia. Herramientas como WebStorm (para mí, mucho mejor que VSCode) o la personalización avanzada de Neovim pueden mejorar enormemente la productividad. (Llevo un par de meses en Neovim, aun en adaptación).

🔹 Pensar en el largo plazo: Un buen arquitecto de software debe diseñar con escalabilidad, mantenimiento y flexibilidad en mente. Las decisiones técnicas de hoy impactarán la vida útil del producto en el futuro.

🔹 Adaptabilidad y aprendizaje continuo: La tecnología evoluciona constantemente. Mantente al día con nuevas tendencias, frameworks y mejores prácticas. Experimentar y aprender es parte fundamental del rol.

Un arquitecto debe equilibrar visión técnica, código y colaboración. ¿Qué otras habilidades crees que son clave en este rol? 🚀

📌 Strongly Typed Forms in Angular Without Duplicating Interfaces

David Garcia — Tue, 04 Feb 2025 21:12:06 +0000

Angular’s documentation suggests defining both interfaces and a manually typed form model. But with TypeScript and recursive types, we can avoid duplication! 🚀

Define a generic type:

export type IToForm<T> = {
  [K in keyof T]: T[K] extends Array<infer U>
    ? FormArray<U extends object ? FormGroup<IToForm<U>> : FormControl<U>>
    : T[K] extends Date
    ? FormControl<T[K]>
    : T[K] extends object
    ? FormGroup<IToForm<T[K]>>
    : FormControl<T[K]>>;
};

Now, create automatically typed forms:

customerForm = new FormGroup<IToForm<Customer>>({
  id: new FormControl(''),
  email: new FormControl(''),
  firstName: new FormControl(''),
  lastName: new FormControl(''),
  addresses: new FormArray([]),
  preferences: new FormGroup({
    newsletter: new FormControl(false),
    language: new FormControl('en'),
  }),
});

✅ Benefits:
🔹 No key name errors.
🔹 Autocomplete in the editor.
🔹 Less repetitive code.
🔹 If you change the model, the entire code will be affected.

📢 Have you tried this approach in your Angular forms? 🚀

🚀 A Better Alternative to .get() in Angular Forms

David Garcia — Tue, 04 Feb 2025 18:28:22 +0000

If you’re using form.get('field') to access a control in a FormGroup, you’re not alone. It’s the most common approach, but there’s a safer and more type-friendly alternative.

💡 Why use .controls instead of .get()?
**
✅ **Type Safety – .controls returns the exact type (FormControl, FormGroup, etc.), eliminating unnecessary type assertions.

✅ Easier Access to Methods – With a FormArray, for example, you can directly use form.controls.items.push(...).

✅ Better Intellisense – Your IDE will autocomplete control names accurately.

🔹 A small change that makes a big difference in your code. Do you use it, or are you still sticking with .get()? 💬