¿Qué criterios usarías para diseñar APIs de componentes con props, emits y slots sin acoplar media aplicación?

Respuesta

• Diseña props pequeñas y semánticas; si una prop objeto concentra demasiadas decisiones, probablemente el contrato pide una división.
• Usa emits para intenciones relevantes del usuario o cambios de valor, no para exponer cada detalle interno del componente.
• Introduce slots cuando el consumidor necesite variar presentación o contenido, pero sin convertir el componente en una filtración de su implementación.

Puntos clave

• La decisión correcta en Vue casi siempre depende del alcance del problema: componente, subárbol, feature o aplicación completa.
• Una buena arquitectura deja dependencias visibles, reduce puntos de escritura y mantiene cerca del caso de uso lo que cambia junto.
• Si una solución necesita demasiadas capas para explicar algo pequeño, probablemente está modelando peor el problema, no mejor.

Errores comunes

• Crear una capa “shared” enorme donde cabe todo acaba destruyendo justo el aislamiento que se buscaba.
• Escoger mecanismo por moda en vez de por alcance suele dejar soluciones más difíciles de leer que de cambiar.

Ejemplo de código

<script setup lang="ts">
const props = defineProps<{
  modelValue: string;
  disabled?: boolean;
}>();
const emit = defineEmits<{
  "update:modelValue": [value: string];
  clear: [];
}>();
</script>

Ejemplo o caso real

Esto suele aparecer en features vivas del producto donde cada cambio pequeño empieza a tocar demasiados componentes, composables o stores.

Idea clave

La mejor arquitectura en Vue es la que reduce dependencias hoy y sigue siendo explicable mañana.