Importación de tipos
Todas las interfaces y tipos públicos del SDK se reexportan desde la raíz del paquete y desde un punto de entrada específico, oneentry/types. No necesitas rutas profundas del tipo oneentry/dist/....
En resumen
// 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: todas las interfaces y tipos de todos los módulos, 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 una utilidad) desde la raíz, de modo que una sola línea de importación cubre valores y tipos. |
'oneentry/types' | Quieres un módulo solo de tipos. No contiene código de ejecución, lo que mantiene los archivos solo de tipos (*.d.ts, archivos de modelos compartidos, contratos de API) libres de importaciones de valores. |
Funcionan igual; elige el que se lea mejor en tu proyecto.
Combinar valores y tipos
El punto de entrada raíz exporta tanto la API de ejecución como los tipos, así que a menudo basta con una sola línea:
import { defineOneEntry } from 'oneentry';
import type { IConfig, IError, IProductsResponse } from 'oneentry';
const config: IConfig = { token: 'your-app-token' };
const api = defineOneEntry('https://your-project.oneentry.cloud', config);
const products: IProductsResponse | IError = await api.Products.getProducts();
Usa import type (o import { type X }) para los tipos. La importación se elimina al compilar, así que no añade nada a tu bundle.
Las importaciones profundas siguen funcionando
Las importaciones desde oneentry/dist/<module>/<module>Interfaces siguen compilando. La raíz y oneentry/types son puntos de entrada adicionales, así que puedes migrar archivo por archivo.
// still valid
import type { IOrderData } from 'oneentry/dist/orders/ordersInterfaces';
¿De dónde vienen los tipos?
Cada módulo del SDK aporta sus propias interfaces, y todas están disponibles desde ambos puntos de entrada:
| Módulo | Tipos habituales |
|---|---|
| Products | IProductsEntity, IProductsResponse, IProductsQueryBase, IFilterParams |
| Pages | IPagesEntity, IPositionBlock, PageType |
| Blocks | IBlockEntity, BlockType, IBlockSlidesResponse |
| Orders | IOrderData, IBaseOrdersEntity, IOrderByMarkerEntity, IRefundRequest |
| Users | IUserEntity, ICartResponse, IWishlistResponse |
| Forms / FormData | IFormsEntity, IFormAttribute, IBodyPostFormData, IFormsDataFilter, FormDataStatus |
| AttributesSets | IAttributeSetsEntity, IAttributeSchemaItem |
| Search | IGlobalSearchResponse, IGlobalSearchGroup, TGlobalSearchEntityType |
Compartidos (base/utils) | IError, IConfig, IAttributeValues, IAttributeValue, IAttributeFile, ITypedAttributeValue, ILocalizeInfo, LangType, IVectorSearchResponse |
La lista completa de tipos de un módulo está documentada en la página de introducción de ese módulo.
Comprobar errores
IError es el tipo que hay detrás del modo predeterminado del SDK de "errores como valores" (isShell: true). Impórtalo desde la raíz como cualquier otro tipo:
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);
}
Relacionado
- Tamaño del bundle y formatos de módulo: cómo se empaqueta el SDK y qué se carga realmente
- Primeros pasos: instalación y configuración