Importation des Types

Chaque interface publique et type du SDK est ré-exporté depuis la racine du package et depuis un point d'entrée dédié oneentry/types, donc les chemins profonds oneentry/dist/... ne sont plus nécessaires.

La version courte

// 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';

Les deux points d'entrée exposent le même ensemble de types — chaque interface et type de chaque module, y compris ceux partagés depuis base/utils (IError, IAttributeValues, ILocalizeInfo, IConfig, …).

Quel point d'entrée devrais-je utiliser ?

Importer depuis	Utilisez-le quand
'oneentry'	Vous importez déjà defineOneEntry (ou un helper) depuis la racine — une ligne d'import couvre les valeurs et les types.
'oneentry/types'	Vous voulez un module uniquement de types : il ne contient aucun code d'exécution, ce qui garde les fichiers uniquement de types (*.d.ts, fichiers de modèle partagés, contrats API) exempts de toute importation de valeur.

Il n'y a pas de différence fonctionnelle entre eux — choisissez celui qui s'intègre mieux dans votre projet.

Mélanger valeurs et types

Le point d'entrée racine exporte à la fois l'API d'exécution et les types, donc une seule ligne est souvent suffisante :

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();

Utilisez import type (ou import { type X }) pour les types : l'importation est effacée au moment de la compilation, donc elle ne contribue jamais à votre bundle.

Les imports profonds fonctionnent toujours

Rien n'a été supprimé. Le code existant qui importe depuis oneentry/dist/<module>/<module>Interfaces continue de se compiler exactement comme avant — les nouveaux points d'entrée sont des ajouts, donc vous pouvez migrer fichier par fichier à votre propre rythme.

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

D'où viennent les types ?

Chaque module SDK contribue ses propres interfaces, et toutes finissent sous les deux points d'entrée :

Module	Types typiques
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, IFormsDataFilter, FormDataStatus
AttributesSets	IAttributeSetsEntity, IAttributeSchemaItem
Search	IGlobalSearchResponse, IGlobalSearchGroup, TGlobalSearchEntityType
Partagé (base/utils)	IError, IConfig, IAttributeValues, IAttributeValue, IAttributeFile, ITypedAttributeValue, ILocalizeInfo, LangType

La liste complète des types d'un module est documentée sur la page d'introduction de ce module.

Vérification des erreurs

IError est le type derrière le mode par défaut "erreurs en tant que valeurs" du SDK (isShell: true), et il est disponible depuis la racine comme tout le reste :

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);
}

---

🔗 Documentation Connexe

• Taille du Bundle & Formats de Module - comment le SDK est empaqueté et ce qui se charge réellement
• Commencer - installation et configuration

---