|
|
@@ -312,55 +312,55 @@ Appelle la route `/api/dolibarr/account/` via un appel à `$dataProvider.invoke(
|
|
|
|
|
|
##### Stores
|
|
|
|
|
|
-* faire un store 'appState', renommer form en formState? renommer page en pageState?
|
|
|
-* utiliser des interfaces pour le state des stores : https://pinia.vuejs.org/core-concepts/state.html#typescript (déja fait a priori)
|
|
|
-* j'ai l'impression que les dialogs ne sont pas gérés depuis le store "page", ce serait ptêt pas mal?
|
|
|
+x faire un store 'appState', renommer form en formState? renommer page en pageState? >> oui, renommer les stores form, page, ... en formStore, pageStore, ...
|
|
|
+x utiliser des interfaces pour le state des stores : https://pinia.vuejs.org/core-concepts/state.html#typescript (déja fait a priori) >> déjà fait
|
|
|
+x j'ai l'impression que les dialogs ne sont pas gérés depuis le store "page", ce serait ptêt pas mal? >> NA
|
|
|
|
|
|
##### Pinia
|
|
|
|
|
|
-* utiliser les hooks pinia pour répercuter les maj sur l'api? >> https://pinia-orm.codedredd.de/guide/model/lifecycle-hooks
|
|
|
+x utiliser les hooks pinia pour répercuter les maj sur l'api? >> https://pinia-orm.codedredd.de/guide/model/lifecycle-hooks >> créer nos propres hooks, mais s'inspirer des hooks pinia-orm
|
|
|
|
|
|
|
|
|
##### Data managers
|
|
|
|
|
|
-* je pense qu'on devrait sortir le `$nuxt.$loading.start()` du service baseDataManager, c'est pas trop à sa place ici
|
|
|
-* le data deleter ne passe pas par un dataProcessor pour mettre à jour le store. mais est-ce nécessaire au final?
|
|
|
-* est-ce qu'on devrait pas choisir soit de récupérer les données dans des composables (ex: useTypeOfPracticeProvider, useCountryProvider), soit dans les components? si on maintient les composables, on pourrait
|
|
|
- les mettre dans un sous-dossier ? ou même factoriser la méthode ?
|
|
|
-* DataPersister L25 : c'est bizarre de stocker l'objet sérialisé dans une de ses propres props non ? on devrait peut-être créer une nouvelle variable et laisser là l'objet DataPersisterArgs
|
|
|
-* ce serait pas mal de passer juste les props nécessaire aux différentes méthodes plutôt que le paquet `queryArgs` à chaque fois, je pense qu'on y verrait plus clair sur qui fait quoi
|
|
|
-* Les services data managers devraient être indépendant de VuexOrm/PiniaOrm, on devrait donc remplacer le param 'query' du data persister par des données sérialisables
|
|
|
+x je pense qu'on devrait sortir le `$nuxt.$loading.start()` du service baseDataManager, c'est pas trop à sa place ici >> plus d'actualité dans nuxt 3
|
|
|
+x le data deleter ne passe pas par un dataProcessor pour mettre à jour le store. mais est-ce nécessaire au final? >> plus d'actualité dans nuxt 3
|
|
|
+x est-ce qu'on devrait pas choisir soit de récupérer les données dans des composables (ex: useTypeOfPracticeProvider, useCountryProvider), soit dans les components? si on maintient les composables, on pourrait
|
|
|
+ les mettre dans un sous-dossier ? ou même factoriser la méthode ? >> plus d'actualité
|
|
|
+x DataPersister L25 : c'est bizarre de stocker l'objet sérialisé dans une de ses propres props non ? on devrait peut-être créer une nouvelle variable et laisser là l'objet DataPersisterArgs
|
|
|
+x ce serait pas mal de passer juste les props nécessaire aux différentes méthodes plutôt que le paquet `queryArgs` à chaque fois, je pense qu'on y verrait plus clair sur qui fait quoi
|
|
|
+x Les services data managers devraient être indépendant de VuexOrm/PiniaOrm, on devrait donc remplacer le param 'query' du data persister par des données sérialisables
|
|
|
|
|
|
##### Forms
|
|
|
|
|
|
-* passer le create et le loader de la page Address/new dans le formulaire? faire la même chose partout?
|
|
|
-* `const entryCopy = query.value.first()` dabs `useForm` (L185): on pourrait peut-être factoriser ça dans un composable? au passage, v-form a une méthode `reset`, ça pourrait ptêt faire le job?
|
|
|
-* UiForm, methode `saveAndQuit`: est-ce qu'on passe dans la méthode `quitForm` au final? puisque la méthode nextStep appellée depuis submit a déjà dû faire la redirection?
|
|
|
-* page address/_id, ligne 18 : on ne pourrait pas faire mieux pour le `const id = parseInt(route.value.params.id)`? faire ça en amont? dans un service? ou carrément parser les paramètres directement depuis un middleware et les stocker dans un store dédié en lecture seule?
|
|
|
-* plutôt que d'instancier une entité dans la page et de la passer au form, est-ce qu'on ne passerait pas un param 'create' au form? il faudrait lever des erreurs si `create == true & id != null` ou `create == false & id == null`
|
|
|
-* comment imposer des propriétés à tous les FormXxxx? Serait-il possible de mettre en place une interface pour l'array props, et de la tester depuis UiForm?
|
|
|
-* useError, ligne 7 : je suppose que la docstring est pas la bonne?
|
|
|
-* uiForm, L185-188 : je passerais ça dans une méthode `resetEntry` par ex
|
|
|
-* components/Form/Organization/ContactPoint.vue, L62 : est-ce que l'action Back serait pas à sa place avec les actions SUBMIT_TYPE ?
|
|
|
-*
|
|
|
+x passer le create et le loader de la page Address/new dans le formulaire? faire la même chose partout?
|
|
|
+x`const entryCopy = query.value.first()` dabs `useForm` (L185): on pourrait peut-être factoriser ça dans un composable? au passage, v-form a une méthode `reset`, ça pourrait ptêt faire le job?
|
|
|
+x UiForm, methode `saveAndQuit`: est-ce qu'on passe dans la méthode `quitForm` au final? puisque la méthode nextStep appellée depuis submit a déjà dû faire la redirection?
|
|
|
+x page address/_id, ligne 18 : on ne pourrait pas faire mieux pour le `const id = parseInt(route.value.params.id)`? faire ça en amont? dans un service? ou carrément parser les paramètres directement depuis un middleware et les stocker dans un store dédié en lecture seule?
|
|
|
+x plutôt que d'instancier une entité dans la page et de la passer au form, est-ce qu'on ne passerait pas un param 'create' au form? il faudrait lever des erreurs si `create == true & id != null` ou `create == false & id == null`
|
|
|
+x comment imposer des propriétés à tous les FormXxxx? Serait-il possible de mettre en place une interface pour l'array props, et de la tester depuis UiForm?
|
|
|
+x useError, ligne 7 : je suppose que la docstring est pas la bonne?
|
|
|
+x uiForm, L185-188 : je passerais ça dans une méthode `resetEntry` par ex
|
|
|
+x components/Form/Organization/ContactPoint.vue, L62 : est-ce que l'action Back serait pas à sa place avec les actions SUBMIT_TYPE ?
|
|
|
+
|
|
|
##### Actions des forms
|
|
|
|
|
|
-* `actions[SUBMIT_TYPE.SAVE] = { path: `/organization/address/` }` : un moyen de rendre plus explicite que l'url dans path est la page où l'on se rend après l'action?
|
|
|
-* est-ce que les chemins où se rendre après les actions submit ne devraient pas être paramétrables dans les props du formulaire lui-même?
|
|
|
-* plutôt que de passer un param 'accordion' (`{ path: `/organization`, query: { accordion: 'address_postal' } }`), est-ce qu'on ne pourrait pas utiliser des anchors?
|
|
|
+x `actions[SUBMIT_TYPE.SAVE] = { path: `/organization/address/` }` : un moyen de rendre plus explicite que l'url dans path est la page où l'on se rend après l'action?
|
|
|
+x est-ce que les chemins où se rendre après les actions submit ne devraient pas être paramétrables dans les props du formulaire lui-même?
|
|
|
+x plutôt que de passer un param 'accordion' (`{ path: `/organization`, query: { accordion: 'address_postal' } }`), est-ce qu'on ne pourrait pas utiliser des anchors?
|
|
|
|
|
|
##### Divers
|
|
|
|
|
|
-* voir à sortir les services profiles/* et rights/* et à les passer dans les composables (il faudra maj les plugins ability et castl)
|
|
|
-* UiItemFromUri, ligne 52 : pqoi ne pas appeller directement `ModelsUtils.extractIdFromUri(uri)`
|
|
|
-* UiInputImage, ligne 112 : est-ce que ce ne serait pas à sa place dans un processor attaché au data provider QUERY_TYPE.IMAGE ça?
|
|
|
-* pourquoi avoir séparé les pages parameters et organization en deux? devrais-je faire la même chose avec subscription? (ex: pages/organization.vue et pages/parameters/index.vue)
|
|
|
+x voir à sortir les services profiles/* et rights/* et à les passer dans les composables (il faudra maj les plugins ability et castl)
|
|
|
+x UiItemFromUri, ligne 52 : pqoi ne pas appeller directement `ModelsUtils.extractIdFromUri(uri)`
|
|
|
+x UiInputImage, ligne 112 : est-ce que ce ne serait pas à sa place dans un processor attaché au data provider QUERY_TYPE.IMAGE ça?
|
|
|
+x pourquoi avoir séparé les pages parameters et organization en deux? devrais-je faire la même chose avec subscription? (ex: pages/organization.vue et pages/parameters/index.vue)
|
|
|
* component useDataUtils :
|
|
|
* on pourrait renommer `getItemToEdit` en `getItem`?
|
|
|
* on pourrait ptêt renommer la méthode `createItem` en `getItemCreator` ou un truc du genre, pour expliciter le fait qu'on retourne une méthode, pas qu'on créé directement l'objet
|
|
|
-* page communication : passer getCurrentWebsite dans un service? (s'il n'existe pas déjà)
|
|
|
-* UiCollection : on pourrait pas passer l'entry root plutot que son model+id? est-ce que le terme de parent serait plus précis ou pas ?
|
|
|
-* middleware/auth.ts : on devrait mettre l'uri du front "admin" non?
|
|
|
+x page communication : passer getCurrentWebsite dans un service? (s'il n'existe pas déjà)
|
|
|
+x UiCollection : on pourrait pas passer l'entry root plutot que son model+id? est-ce que le terme de parent serait plus précis ou pas ?
|
|
|
+x middleware/auth.ts : on devrait mettre l'uri du front "admin" non?
|
|
|
* pour gérer les cas comme sur la page subdomains/id_, on pourrait sortir la logique de soumission et validation de UiForm et mettre ça dans un component séparé ou dans un composable? de cette façon, on pourrait utiliser
|
|
|
cette logique sans être dans un formulaire classique (boutons, dialog…)
|
|
|
* détail : dans UiCollection, on pourrait ptêt éviter des confusions en renommant la prop `newLink` en qqchose comme `pageNewUri`, ou `linkToNewPage`, ou même `linkToNew`, mais bon, c'est ptêt pas nécessaire...
|
Olivier Massot