Peut pas utiliser un lien <a routerLink> filtré vers le listing courant

[PowerKiKi]

En faite je rouvre le ticket plutôt qu'en créer un autre car ça reste très lié.

Il nous reste une zone morte : On n'initialise natural-search que lors qu'on initialise son composant parent. Du coup, on ne peut pas utiliser un lien <a routerLink> filtré vers le listing courant car il est ignoré à la fois par la barre de recherche et par les résultats. On n'a aucune implémentation pour réagir à un changement d'url en regard de la recherche (hors cas spécifique de l'historique).

Paradoxalement, on peut linker vers un autre listing filtré, puisque le filtre est pris à l'initialisation de l'autre composant.

Disposer d'un lien standard (html) avec un filtre vers le composant courant est en faite assez compliqué. Il faut déléguer le pouvoir à l'url.

L'implémentation actuelle implique qu'on appelle search (update url + query) lors d'un changement manuel de la recherche.

           <natural-search
                    [selections]="selections"
                    (selectionChange)="persistAndSearch($event)"
                />

Ce qu'il nous faudrait c'est plutôt de mettre à jour l'url, et ensuite d'écouter les changements sur l'url :

           <natural-search
                    [selections]="selections"
                    (selectionChange)="persistOnly($event)"
                />

persist() update le local storage et l'url.

        this.router.events(...) .subscribe(() => {
                const selections = fromUrl(this.persistenceService.getFromUrl('ns', this.route));
                this.naturalSearchSelections = selections;
                this.translateSearchAndRefreshList(this.naturalSearchSelections, true);
            });

J'ai implémenté un prototype approximatif et ca marche plutôt bien pour résoudre le cas spécifique. Mais il y a d'autres cas que j'anticipe qui ne vont pas fonctionner :

• Partir et revenir sur un listing filtré n'est pas initialisé depuis le local storage (il faut approfondir le sujet)
• Les composants qui n'ont pas de persistance ne peuvent pas marcher, puisqu'il n'y a pas d'url pour eux. Notamment tous ceux qui sont wrappés dans d'autres composants ou dont la persistance est désactivée.

Donc cette approche alternative ne se suffit pas à elle même, et les deux approches (actuelle + nouvelle) ne peuvent pas vivre ensemble, sinon il y a double recherche (double query vers le serveur).

Je vais continuer à creuser la question en off, mais si t'as un avis je t'écoute volontiers.

Originally posted by @sambaptista in #195