rendre générique `useResourceSearch`

[ccreusat]

@jcbe-ode

Est-ce qu'on rendrait pas générique le typage de useResourceSearch car pour le moment il est fait pour ILinkerResource. Il utilise la recherche explorer

await odeServices
            .resource(appCode, resourceType)
            .searchContext(filters)
            .then((results) => results.resources);

mais le hook retourne en promesse un tableau de ILinkerResource.

return { resourceApplications, loadResources } as {
    resourceApplications: Array<App>;
    loadResources: (filters: GetContextParameters) => Promise<ILinkedResource[]>;
  };

Ce que je propose pour pouvoir récupérer des IResource :

export const useResourceSearch = <T>(appCode: App) => {...}

retourne

return { resourceApplications, loadResources } as {
    resourceApplications: Array<App>;
    loadResources: (filters: GetContextParameters) => Promise<T[]>;
  };

et à l'usage :

// LinkerResource
const { loadResources } =
    useResourceSearch<ILinkedResource>(appCode);

// IResource
const { loadResources } =
    useResourceSearch<IResource>(appCode);

[jcbe-ode]

Pour mémoire: je dresse l'état des lieux avant de réfléchir et répondre :)

On dispose en ce moment de 2 API dans edifice-ts-client pour rechercher des ressources :

• l'API d'exploration : pas encore supportée par toutes les applis, car elles nécessitent un dev backend pour indexer les ressources.

• l'API de listing de ressources (celle intégrée dans useResourceSearch) : basée sur le rétro-engineering des fonctions loadResources() des behaviours historiques des applis.

Seule la première API devrait exister, la seconde étant vouée à disparaître car biaisée (pb de filtres, ordonnancement, pagination...).

Les 2 API se ressemblent, elles implémentent la même interface IResourceService => les loadResources() historiques mappent désormais les données trouvées sur un sous-ensemble du modèle de données de l'explorateur, IResource (à noter : c'est faux. En pratique c'est une extension, pas un sous-ensemble)

La 1ère API intègre sa propre registry; La 2nde propose un service de plus haut niveau SnippletService, volontairement séparé des services standard de ts-client, car il permet de surcharger la registry du 1er. Et ne doit pas être utilisé ailleurs que dans le Linker.

Comme les applis seront adaptées petit à petit côté back, la seconde API va pouvoir aussi évoluer petit à petit, dans ts-client; il suffira de supprimer la behaviour d'une appli migrée, et de supprimer la surcharge dans la registry, sans rien devoir modifier côté UI; en théorie... car côté UI, useResourceSearch() est actuellement biaisée : elle utilise la 1ère API d'exploration, mais la données retournée est de type ILinkedResource au lieu de IResource (contenant un champ path en +); voir note précédente.

Quand toutes seront migrées, on pourra complètement supprimer la seconde API et remplacer l'interface du Linker par une interface d'exploration standard... C'était le plan imaginé initialement. Au final, useResourceSearch() aurait gagné à être nommée useLinkerSearch(), car elle est fortement liée à l'UI du Linker.

[jcbe-ode]

La question est donc :

• comment supprimer le type ILinkedResource, et faire en sorte que le Linker continue de fonctionner via l'API d'exploration standard.
• comment sécuriser l'usage de SnippletService, dans l'intervalle de temps où toutes les applis seront migrées. et par extension,
• comment mieux gérer la registry de IResourceServices ?

[ccreusat]

@jcbe-ode Effectivement, je voulais juste clarifier l'usage du hook, mais il faudra un plan pour retirer les services de Blog et Mindmap, et Mur collaboratif avec le portage React et pouvoir charger les services qui sont sur ts-client pour le moment depuis l'app cible et avoir un moyen de les charger ailleurs (à terme dans le linker par exemple)

On verra lundi, s'il faut des packages ou taper sur des scripts chargés dynamiquement et surtout où mettre le "service" d'une app migré dans l'explorateur