Importando Tipos

Cada interfaz pública y tipo del SDK se re-exporta desde la raíz del paquete y desde un punto de entrada dedicado oneentry/types, por lo que ya no se requieren rutas profundas oneentry/dist/....

La versión corta

// before — deep path into the build output
import type { IAttributeSchemaItem, IAttributeSetsEntity } from 'oneentry/dist/attribute-sets/attributeSetsInterfaces';

// now — either of these
import type { IAttributeSchemaItem, IAttributeSetsEntity } from 'oneentry';
import type { IAttributeSchemaItem, IAttributeSetsEntity } from 'oneentry/types';

Ambos puntos de entrada exponen el mismo conjunto de tipos — cada interfaz y tipo de cada módulo, incluidos los compartidos de base/utils (IError, IAttributeValues, ILocalizeInfo, IConfig, …).

¿Qué punto de entrada debo usar?

Importar desde	Úsalo cuando
'oneentry'	Ya importas defineOneEntry (o un helper) desde la raíz — una línea de importación cubre valores y tipos.
'oneentry/types'	Quieres un módulo solo de tipos: no lleva ningún código en tiempo de ejecución, lo que mantiene los archivos solo de tipos (*.d.ts, archivos de modelo compartidos, contratos de API) libres de cualquier importación de valor.

No hay diferencia funcional entre ellos — elige el que se lea mejor en tu proyecto.

Mezclando valores y tipos

El punto de entrada raíz exporta tanto la API en tiempo de ejecución como los tipos, por lo que una sola línea suele ser suficiente:

import { defineOneEntry } from 'oneentry';
import type { IConfig, IError, IProductsEntity } from 'oneentry';

const config: IConfig = { token: 'your-app-token' };
const api = defineOneEntry('https://my-project.oneentry.cloud', config);

const products: IProductsEntity[] | IError = await api.Products.getProducts();

Usa import type (o import { type X }) para tipos: la importación se elimina en tiempo de compilación, por lo que nunca contribuye con nada a tu paquete.

Las importaciones profundas siguen funcionando

Nada fue eliminado. El código existente que importa desde oneentry/dist/<module>/<module>Interfaces sigue compilando exactamente como antes — los nuevos puntos de entrada son adiciones, por lo que puedes migrar archivo por archivo a tu propio ritmo.

// still valid
import type { IOrderData } from 'oneentry/dist/orders/ordersInterfaces';

¿De dónde vienen los tipos?

Cada módulo del SDK contribuye con sus propias interfaces, y todas terminan bajo ambos puntos de entrada:

Módulo	Tipos típicos
Products	IProductsEntity, IProductsResponse, IProductsQueryBase, IFilterParams
Pages	IPagesEntity, IPositionBlock, PageType
Blocks	IBlocksEntity, BlockType, IContentSlidesResponse
Orders	IOrderData, IBaseOrdersEntity, IOrderByMarkerEntity, IRefundRequest
Users	IUserEntity, ICartResponse, IWishlistResponse
Forms / FormData	IFormsEntity, IFormAttribute, IBodyPostFormData
AttributesSets	IAttributeSetsEntity, IAttributeSchemaItem
Compartido (base/utils)	IError, IConfig, IAttributeValues, IAttributeValue, ILocalizeInfo, LangType

La lista completa de tipos de un módulo está documentada en la página de introducción de ese módulo.

Comprobando errores

IError es el tipo detrás del modo predeterminado "errores como valores" del SDK (isShell: true), y está disponible desde la raíz como todo lo demás:

import type { IError } from 'oneentry';

function isErrorResult(result: unknown): result is IError {
  return (
    !!result &&
    typeof result === 'object' &&
    ('statusCode' in result || 'message' in result)
  );
}

const result = await api.Products.getProducts();

if (isErrorResult(result)) {
  console.error('Error:', result.message);
} else {
  console.log('Success:', result);
}

---

🔗 Documentación Relacionada

• Tamaño del Paquete y Formatos de Módulo - cómo se empaqueta el SDK y qué se carga realmente
• Comenzar - instalación y configuración

---