¿Como dividir el diseño de figma para identificar la cantidad de componentes que se deben crear y cuales son los componentes padre e hijos?

Gracias por la respuesta tu metodologia de identificar componentes la relacione con atomic design. .

Hay un principio muy simple que puedes seguir: Un componente debe de encargarse de sus propias cosas, no de las de sus padres, no de las de sus hijos, y si aun así hace demasiadas cosas, tal vez es hora de dividirlo en subcomponentes, aunque estos subcomponentes solo se usen para armar este componente.

Hay que pensar mucho en la reusabilidad, si el componente no contiene a otros, debe ser más reusable y agnóstico, a medida que contiene a otros que contienen a otros, va tomando la lógica de negocios de la aplicación.

Por ejemplo, Componente base: un botón, un dropdown. Ambos son simples y agnósticos al negocio.

Componente de alto nivel: carrito de compra. Incluye lógica de negocio en su definición y código.

Hacer un componente base muy complejo, implicaría poca reusabilidad, mucho código que mantener.

Hacer un componente de alto nivel muy reutilizable, podría hacer que nuestras aplicaciones sean demasiado genéricas con experiencias de usuario muy pobres, por ejemplo, poner un simple textarea con capacidad de leer Markdown (altamente reutilizable), es mucho más pobre en UX que un editor como Google Docs (más específico).

Eso solo te lo va dando la experiencia, en mi experiencia y personalmente, he aprendido a dividir los componentes en:

• Blocks: elementos indivisibles, como botones, inputs, imágenes, etc...
• Groups: conjuntos simples de blocks, como headers, button groups, inputs complejos (ej. input icon, input search, input autocomplete), etc...
• Widgets: unidades de lógica de negocio, formados por blocks, groups y hasta otros widgets, como formulario de login, carrito de compra, input de código de verificación, tabs, input chat, etc.
• Layout Components: componentes reutilizables que ayudan al acomodo de elementos en pantalla, para hacer los Layouts más simples, por ejemplo, sistema de columnas, grid, slider, covers, lógica de modals, alerts y notifications (no su UI), etc.
• Layouts: acomodo de elementos en pantalla reutilizable, como layout de blog, calendario, tabla, resultados de búsqueda, panel de administración, etc.
• Pages: son las vistas finales armadas de todas las partes anteriores, aquí conecto con JS la lógica de negocios, y así logro separar la lógica de los componentes o UI, de las reglas de negocio, y armar nuevas vistas con partes reutilizables.

Sin embargo, es un criterio muy personal, puede haber muchas formas de pensar en esto.