Au moins dans coreFetch

Dans l'API de recherche existante, la gestion est groupes est très basique : on choisit une clé sur laquelle grouper et le serveur renvoie des groupes.

En particulier, on ne peut pas faire de chargement partiel, c'est à dire qu'on est dépendant de l'implémentation côté serveur pour l'exhaustivité des résultats, qui peut choisir de renvoyer tous les éléments d'un groupe ou pas, ou bien tous les groupes ou pas.

On aimerait bien pouvoir spécifier la taille d'un groupe, le nombre de groupes que l'on veut récupérer, charger les groupes qui nous manquent et plus d'éléments sur un groupe.

La vue mosaic sous IE plante. Le wrapper global devrait avoir une width définie pour que cela fonctionne.

Plus généralement, quand on clic en dehors du panel de recherche par critere, on lance la recherche et on ferme le panel.

Comportement actuel

La clé pour la valeur de regroupement n'est pas interprétée, malgré le fait qu'elle ait une valeur i18n

Comportement souhaité

Affiché la valeur de la clé i18n

Version

1.5.4

• unifier show more dans la liste (virer de results)
• virer liststore avec service (on utilise que le searchstore)
• consolider l'ensemble (ne pas avoir besoin de préciser store + data dans StoreList)

But : pouvoir utiliser StoreList à la place de AdvancedSearch gratos.

Dans le cas d'exception renvoyée par le serveur, il faudrait renvoyer le contenu complet de la réponse en paramètre de la fonction d'erreur. (Pour pouvoir l'utiliser dans un server.ts dans le projet afin de récupérer le code http d'erreur par exemple)

Déso, le toggle all sélectionne tous les élements y compris ceux non sélectionnables
Re déso.

• Supprimer la propriété route qui ne sert plus (remplacé par router.currentStore.prefix)
• Refondre la gestion du mode avec une map des formulaires et une propriété isEdit

tdlt

En mode mosaïque, on a besoin d'un affichage différent, avec la case à cocher en bas à droite et les actions au milieu en boutons "mini-fab".

Il faudrait également afficher toutes les cases à cocher en "mode sélection".

Il se trouve que si j'avais fait mes recherches correctement, j'aurais vu que ce que j'ai fait pour le module theming a déjà été fait en mieux par react-css-themr.

Il faudrait du coup migrer dessus, ce qui ne devrait rien changer de l'extérieur.

Les actions que l'on peut effectuer sur les éléments d'une recherche (ou liste) doivent être distinctes entre le type d'action (unitaire, en masse) et le type d'élément (scope dans la recherche).

De plus, il faudrait correctement remonter la gestion des actions unitaires dans la liste (et non dans la ligne, qui est laissée à l'utilisateur) et gérer la liste d'actions comme on gère la case à cocher de sélection. La liste d'actions unitaires doit être une fonction de la donnée, pour pouvoir afficher ou masquer des actions selon un état par exemple.

Pour cela, il faut préciser la valeur du champ "Name", il me semble.

On voudrait pouvoir mettre un autre EntityStore en tant que noeud d'EntityStore.
Du style :

const store2 = makeEntityStore({
    node2: {} as Node2,
});

const store1 = makeEntityStore({
    node1: {} as Node1,
    store2
});

Pour faire des accès genre store1.store2.node2 ou du store1.store2.clear(), voire le plus intéressant store1.clear() qui viderait store2 aussi.

On veut un autocomplete qui n'est pas lié à une valeur et donc vide l'input après la sélection, par exemple pour une recherche rapide pour sélectionner des choses.

Il faudrait ajouter une propritété à l'AdvancedSearch qui permette d'ajouter cette valeur à tous les libellés d'actions . Par exemple : list.actionbar.filter => myPrefix.list.actionbar.filter

Aussi, lorsque l'on sélectionne un filtre, la clef n'est plus traduite dans l'affichade de la mention "trié par"

Il faudrait pouvoir ajouter une fonction d'ajout à une liste qui afficherait un bouton dans la liste pour ajouter un élément. A faire après #9. Le bouton serait affiché en haut à droite du bouton de changement d'affichage en mode liste, et en tant que premier bloc en mode mosaïque.

Remplace #8

Gestion d'une API serveur qui autorise (ou pas !) la sélection de plusieurs valeurs pour une facette.

Is it possible toi export the ButtonProps interface located in focus-components?

Furthermore, the shape prop could be null, so we have to add that.

declare module "focus-components/button" {
    export interface ButtonProps {
        className?: string;
        color?: "colored" | "primary" | "accent";
        disabled?: boolean;
        handleOnClick: (e?: React.SyntheticEvent<any>) => void;
        hasRipple?: boolean;
        icon?: string;
        iconLibrary?: "material" | "font-awesome" | "font-custom";
        id?: string;
        isJs?: boolean;
        label?: string;
        shape?: "raised" | "fab" | "icon" | "mini-fab" | null;
        style?: React.CSSProperties;
        type?: "button" | "submit";
    }

    export default class Button extends React.Component<ButtonProps, {}> { }
}

Intégration avec les commentaires du modèle ? Option pour changer et activer/masquer.

A poser à droite du libellé.

Proposer aussi une deuxième tooltip à droite de la valeur pour une aide sur la valeur ?

Exemple : élément avec un bouton pour ajouter une nouvel item.

On ajoute un troisième bouton "Filtrer" qui ouvre un panneau avec le composant de filtres en dessous, qui remplacerait celui posé à gauche des résultats par défaut.

Idéalement, il faudrait que les listes puissent avoir deux modes d'affichage : liste ou mosaïque. Il y aurait un bouton pour changer de mode d'affichage et on fournirait 2 composants de lignes à la liste, par exemple LineComponent et MosaicComponent.

Le bouton pour changer sera affiché au dessus de la liste à droite et serait propre à une liste (et non dans une action transverse).

In the advanced search, the empty state is displayed when a search returns no results

The following search/filter should display the fact that there are no results rather than an empty state saying that you can add objects

Il y a un overflow : hidden à supprimer dans le css du header qui est gênant

https://github.com/get-focus/focus4/blob/master/src/application/layout/header/__style__/header.css#L44

Problème avec l'overflow

Problème résolue en enlevant l'overflow

Il faudrait ajouter une zone de texte pour pour filtrer une liste ou la recherche dans la barre d'actions.

Pour la recherche, c'est directement la zone de recherche textuelle.

Pour une liste, ça serait un filtre configurable simple de recherche à la volée dans la liste chargée. On spécifierait la liste des champs sur lesquels on veut rechercher dans le store, et le texte saisi serait recherché texto dans les champs demandés. L'idée est de fournir une "mini-recherche" pour des petits jeux de données pour lesquels ça ne vaut pas le coup de monter une recherche complète côté serveur.

In input fields for searching and filtering (search, filter, autocomplete, etc...) have a "X" button on the right side allowing the user to empty the input

Following a recent framework update, the server message notification displays a button with a label which is confusing to the user. Certain websites and apps now show a notification "Undo" after an action, allowing the user to under the recet action. If the feature present here is to simply dismiss the notification, I would recommend using a close button rather than a label. A close button's meaning is immediate for a user whereas a label forces him to understand the meaning of the label

Especially if in a future version we implement the "Undo" feature.

Current behavior

Expected behavior

Quand on redimensionne la fenêtre, la liste des filtres s'affiche alors que l'utilisateur n'a pas cliquer pour l'ouvrir

Ca serait stylé et très pratique d'avoir un explorateur de stores (EntityStore/ViewStore) en tant que DevTools pour pouvoir facilement visualiser ce qu'il se passe (au lieu de la console).

Ca existe dans toutes les versions de Focus sauf le 4 en plus.

Please ! :)

Et surtout, en mode quicksearch, l'appeler sur le onChange.

La sélection du scrollspy ne fonctionne pas en correspondance avec le scroll de la page

Au click, la page scroll mais la sélection n'est pas affichée sur le scrollspy. Idem quand on scroll, le scrollspy ne suit pas l'affichage à la page.
Ca fonctionnait dans une version antérieure, je ne sais pas depuis laquelle c'est cassé

Actuellement, il n'y a que le scroll infini qui est mis en place pour la présentation des items dans l'Advanced Search.
On aimerait avoir la possibilité de choisir entre un scroll manuel et un scroll infini.

• On a besoin de pouvoir spécifier un vraie page de fallback dans le routeur (à la place de rediriger vers home)
• Cette page doit correspondre à une route précise (par exemple "/error"), et doit prendre au moins un paramètre en plus pour gérer des codes d'erreurs ("/error/notfound", "/error/forbidden", ou encore "/error/customBusinessError")
• On a besoin d'avoir accès à un hook "beforeEnter", à la fois sur le routeur et en intercepteur sur currentView, pour pouvoir par exemple faire des vérifications et des redirections (au moins vers la page d'erreur).

Ajouter une propriété "Selected" sur les objets de la recherche afin qu'on puisse les styler

• Ajouter du padding sur la mosaïque add
• Bouton Group qui devient Filter

J'avais en tête d'adresser la recherche par critères, qui adresse un besoin complémentaire pour l'utilisateur, de cette manière :

Coté FOCUS, la mise en place pourrait être faite par fichier de configuration.
Côté Backend, il y a peu de travail à mon sens, à part ouvrir un peu l'API (peut-être).

Actuellement, il n'est possible de sélectionner que des éléments qui ont effectivement été chargés par le service de recherche/chargement. De même, la sélection de masse va toujours sélectionner l'ensemble des éléments chargés, sans vérifier s'ils sont affichés ou non, et surtout sans consulter le serveur sur les éléments non chargés.

Par exemple, une sélection de masse sur une recherche paginée va seulement sélectionner les éléments dans les pages qu'on a téléchargé.

Cela pose aussi la question sur les actions de masse, qui s'effectuent sur les éléments sélectionnés.

Il manque du coup probablement quelque chose dans l'API de recherche pour sélectionner des éléments sur le serveur, et il faudrait pouvoir bien clarifier les cas d'usages (est-ce-qu'on en a vraiment besoin ? est-ce-que ça a du sens ? dans quels cas la sélection de masse doit-elle effectivement appeler le serveur ?)

Il faudrait pouvoir forcer le rechargement d'une liste de référence dans un ReferenceStore.
Par exemple suite ajout/suppression d'un élement dans un écran.

Si un utilisateur ne veut pas utiliser les modules CSS pour le style de son application, il faudrait pouvoir le laisser pouvoir générer des noms de classes déterministes par le build webpack.
Si on nomme les classes focus-[nomFichier]-[nomClasse] dans le css-loader, on devrait pouvoir assurer qu'il n'y ait pas de collision.
Cela marchera si les noms de fichiers sont bien uniques.

In the search bar, some of the features aren't always desired

For instance, the "Group By" is not pertinent for our users or very confusing and therefore we'd like to remove it.

Avec la V3, l'affichage des filtres (liste des facettes) à été repensé et il faut qu'on reprenne ce travail.
Ce sera également l'occasion d'y faire un peu de ménage.