Fpo/schematics
Solidify Schematics Moved on Solidify-Frontend
Merge request reports
Activity
- solidify-schematics/README.md 0 → 100644
37 38 39 ### Manual Publishing (when no nexus...) 40 41 ```bash 42 npm run tgz 43 ``` 44 45 This commands should generate the file `schematics-solidify-1.0.0.tgz` at the root of the project. 46 Run the following command on an Angular CLI project (adapt the path to the file `schematics-solidify-1.0.0.tgz`) : 47 48 npm i --no-save path/to/DLCM-Solidify-Tools/solidify-schematics/schematics-solidify-1.0.0.tgz 49 50 ### Usage 51 52 Now, on the CLI project you can run the following command depending of the king of component you want to generate : Il peut être intéressant d'ajouter dans le README le fait que l'on peut définir le schematics solidify comme schematics par défaut afin de ne pas avoir besoin de taper :
ng g @schematics/solidify:view my-view
mais plutôt :ng g view my-view
. Plus d'informations ici : https://hackernoon.com/%EF%B8%8F-the-7-pro-tips-to-get-productive-with-angular-cli-schematics-b59783704c54 (voir chapitre 5, deuxième point).
- solidify-schematics/.gitignore 0 → 100644
1 # Outputs Ajouter le fichier schematics-solidify*.tgz dans le git ignore et en profiter pour retirer le fichier schematics-solidify-1.0.0.tgz de la merge request ;)
Edited by Nicolas.Forney
1 import {Component, OnInit, ChangeDetectionStrategy, Inject} from '@angular/core'; 2 import {MAT_DIALOG_DATA, MatDialogRef} from '@angular/material'; 3 import {Store} from '@ngxs/store'; 4 import {BaseDirective} from '@app/shared/directives/base.directive'; Il faut que l'on puisse customizer le path de cet import. Je trouve pratique l'utilisation d'une classe BaseDirective (pour gérer, comme tu l'as fait, le unsubscribe, je souhaitais aussi créer une classe similaire). Par contre, comme nous n'avons pas de librairie angular partagée, le path entre votre projet et les nôtres sera différent. Explication ici sûr comment définir des configs pour les schematics par projet dans le fichier angular.json : https://hackernoon.com/%EF%B8%8F-the-7-pro-tips-to-get-productive-with-angular-cli-schematics-b59783704c54 (chapitre 5, première partie). Cas concrêt de configuration de multiple options : https://github.com/angular/angular-cli/tree/f8fe4b0ee82d880396119a2594f3cee8dadb2947/packages/schematics/angular/component
L'idée est donc de pouvoir faire un
ng g view my-view --baseDirectivePath='mon/path'
ou de configurer cette option directement comme valeur par défaut dans le fichier angular.json de son projet : "@schematics/solidify:view": { "baseDirectivePath": "mon/path" }Ce n'est qu'un example, il faudrait peut être ajouter un option qui permet de spécifier également le nom de la librairie de base. Il y a plusieurs possibilités. On peut en rediscuter si jamais.
Edited by Nicolas.Forney
Je ai pour l'instant juste fait une mini review du code dans Gitlab, je n'ai pas encore testé le schematics dans un de nos projet. Je ferai ça la semaine prochaine (je fais le pont). Sinon, c'est vraiment chouette, cela va nous permettre de gagner du temps et en continuant à faire évoluer cette librairie, on pourra même créer des schematics pour d'autres aspect comme NGXS, formulaire, etc.
Good job !!
En effet on pourra intégrer d'autres aspects :) Pour NGXS il y a un schematics déjà existant https://github.com/ngxs/schematics Il faudra voir si cela est nécessaire de le rendre aussi configurable que la CLI angular (choix css/scss/sass, detection change onPush ou pas, etc...). Pour l'instant c'est en dure... N'hésite pas à modifier la merge request car dans mon cas je fais le viaduc !
Pour les schematics NGXS je pensais à quelque chose d'un peu plus complet, qui nous permettrait par exemple de générer automatiquement les action Get/Success/Failed et déjà mieux configuré que ceux générés par les schematics de NGXS qui sont assez basiques. Mais cela signifie qu'il faudra davantage creuser dans le fonctionnement des schematics, car il faudra cette fois pouvoir ajouter des informations à un fichier existant. A voir.
Edited by Nicolas.Forney