leaa
v3.9.0
Leaa est un CMS MonorePO (Système de gestion de contenu) construit avec Nest.js, Next.js et Ant Design.
Consultez le README.md de chaque sous-répertoire dans packages . Vous devrez peut-être d'abord regarder les espaces de travail du fil.
Todos
À l'origine, le résumé devrait être rédigé à la fin de l'article, mais je pense qu'il devrait être mis en avant, au moins je n'ai pas à lire mon harcèlement sur les journaux de développement.
J'avais l'habitude de penser que j'essaierais de me connecter aux 5 fins en écrivant moi-même un projet complet. Je n'avais pas de temps et je me suis glisser. Quand je l'ai écrit, je pensais que cela prendrait plus de demi-année, mais je ne m'attendais pas à ce que cela ne prenne qu'un seul mois et demi pour le faire. Et j'ai également cherché les meilleures pratiques dans de nombreux endroits, et dans l'ensemble, j'étais assez satisfait.
L'intention initiale du projet était d'utiliser React ou principalement la syntaxe JSX pour faire plus de choses, telles que la rédaction de mini programmes ou applications, et le cadre technique existant soutient également mon idée. J'ai commencé à partir sur la route avec mon expérience précédente et certaines technologies plus récentes telles que GraphQL .
Il n'y a pas beaucoup de problèmes rencontrés sur api , dashboard et www , mais miniprogram (小程序，下文简称mp) et app ne sont pas si chanceux car ce ne sont pas web 语言standard. Ils sont comme un rendu HTML 富文本, qui prend naturellement web . Sur eux, ils deviennent fuckingSelf et doivent être analysés par eux-mêmes, comme a lien, car il n'y a pas a de tel mp et app . Ce qui arrive aux utilisateurs cliquez sur a est entièrement jusqu'à ce que le développeur décide, ce qui est complètement différent de "l'application web que j'ai développée auparavant. Si j'avais déjà de l'expérience dans le développement App , je crois qu'il y aurait moins de pièges à mentir.
En parlant de pièges, je pense que mes compétences de fouille de stand sont vraiment incroyables. RN est populaire car il a de nombreux fosses et est considéré comme bien connu. D'accord, je l'ai choisi. Vous ne connaissez peut-être pas les pièges de monorepo , mais ils peuvent en effet faire mourir les gens. D'accord, je vais choisir. Il n'y a pas beaucoup de pièges dans le développement RN avec TS , mais il y en a aussi beaucoup. Ok, je l'ai choisi aussi. Ensuite, j'ai choisi ce RN + monorepo + TS Super Big Pit (Cry), mais je me suis toujours couché petit à petit après, et j'admire vraiment ma patience (diffusant mes mains).
Pourquoi choisir monorepo pour se développer? Mon intention initiale était de partager interface de TS et certaines configurations réutilisables sur les 5 côtés, mais plus tard, lorsque j'ai écrit mp et app , j'ai trouvé qu'en raison de certains de leurs mécanismes spéciaux, je n'ai pas pu les partager. En fait, mp et app sont complètement isolés de monorepo . Si je refactez le code plus tard, je mettrai séparément ces "非标准web 应用" dans un repo car elles sont vraiment difficiles à servir. node_modules en a également un qui ne peut pas être partagé, et chacun est très grand. Ce n'est pas la clé, la clé est que chaque fois yarn install , il est très plein et le CPU monte en flèche que l'ordinateur est sur le point de décoller. À l'origine, j'ai tendance à utiliser yarn workspaces pour résoudre mono sans lerna , mais à cause de ce problème, j'ai essayé de monter sur lerna , mais le problème ne semblait pas s'améliorer, j'ai donc dû abandonner. Cette fois, je me suis vraiment donné de l'expérience avec monorepo , qui peut être considérée comme une douleur de la chair, et cela m'a également fait savoir comment choisir mono et multi .
OK, si on m'a demandé d'écrire un classement de difficulté à 5 côtés maintenant, je pense que ce serait comme cette app mp > www > api > dashboard .
Pourquoi mp est-il répertorié comme la partie la plus difficile? Parce que mp a non seulement beaucoup de biens privés, mais aussi Devtools ont également étonnamment de nombreux bogues. Parfois, je répète un bug, mais cela ne fonctionne pas bien pendant longtemps, mais il suffit de redémarrer Devtools. Cela me fait vraiment vomir du sang. Et parce que j'ai utilisé Taro , de nombreuses nouvelles fonctionnalités telles que custom-tab-bar ne le suivaient pas et il n'y avait pas de documentation. Je l'ai compris par moi-même, mais cela a pris beaucoup de temps. Bien sûr, si vous utilisez Taro et que vous avez l'exigence custom-tab-bar , leaa peut être la solution optimale pour la solution GitHub existante actuellement.
De plus, j'avais beaucoup à dire sur www ( Next.js v9), mais au fil du temps, ces choses à dire disparaissent progressivement. Ce genre de "ne veut pas dire" n'est pas le genre de "pas difficile pour ceux qui ne sont pas difficiles", mais parce que Next.js a trop de pièges, résoudre une fosse mènera inévitablement à plusieurs autres pièges. De plus, il n'y a pas de meilleures pratiques à laquelle vous faites référence. Ce sont tous example simples. Une fois que vous souhaitez faire des fonctions complexes, ce type de "SSR" qui doit être traité par les deux avant et les gens donne à les gens de se sentir comme "cachés indicibles". Avec chaque changement dans la version Next.js comme 8to9, il y aura de nombreux changements de falaise. Il n'y a aucun moyen, la culture de Zeit est comme ça, et vous ne pouvez vous réconforter que "tout le malheur vient d'être assez fort".
Pour monorepo , il existe de nombreux fichiers avec des "noms de fichiers similaires" dans un projet. Plusieurs fois, j'ai l'impression d'être submergé par des fichiers et peut facilement être interféré lors de la recherche de fichiers. Même si j'abandonne en utilisant Components/Filter/index.tsx pour nommer les fichiers avec Components/Filter/Filter.tsx pour trouver cmd +. p peut rapidement localiser le fichier lui-même au lieu du répertoire, mais il est également difficile de se débarrasser de ce sentiment de "fichier de l'enfer".
Il a été initialement dit que je ne devais pas me plaindre si je pouvais écrire un résumé, mais maintenant il semble qu'il y ait encore des plaintes. Partout, de Docker à Api à UI/UX , le processus d'écriture leaa m'a en effet beaucoup appris, et j'ai une compréhension plus approfondie de l'architecture logicielle et des principes d'ouverture et de clôture. Dans le passé, je pensais que le «codage» et «l'architecture» faisaient en fait la même chose, mais cette fois, j'ai une compréhension plus profonde.
À l'heure actuelle, il y a beaucoup, beaucoup de bugs leaa , mais cela ne semble pas empêcher les personnes dans le besoin de récupérer le code utile à leaa via Github. C'est aussi mon intention initiale d'écrire leaa ci-dessus. 2019-09-17 17:01 @ Guangxi Hezhou
De Git Commit, nous pouvons voir que ce journal de développement (journal de développement) est seulement écrit. Le projet était à l'origine appelé 1d1h, ce qui signifie une heure par jour. Je souhaite rassembler l'expérience précédente de l'écriture avant et arrière dans mon temps libre et faire un projet open source de blog -> CMS -> SOHP, y compris l'API / Dashboard / Site Web / WeChat WeApp / React Native (iOS / Android). Parce qu'il s'agit d'un monorepo, similaire à l'interface / entrée, ceux-ci sont partagés, il est donc dit que c'est une chose très pratique de créer une plate-forme complète.
En fait, je voulais à l'origine écrire ce journal de développement plus tôt, mais au début, j'ai passé beaucoup de problèmes qui devaient être résolus, et je n'ai vraiment pas pu trouver le temps d'écrire des enregistrements. Maintenant j'y pense, ça ne devrait vraiment pas être comme ça. Après tout, si j'avais enregistré beaucoup de problèmes auparavant, c'était en fait une richesse invisible. Bien que j'aie à nouveau rencontré, je saurais certainement comment les résoudre, mais je ne pouvais pas les partager avec les autres. Mais je passerai en revue les journaux suivants lentement.
Permettez-moi de parler de ma compréhension du tableau de bord ici. Je pense qu'un tableau de bord minimum disponible doit être inclus.
Ces modules peuvent essentiellement être utilisés comme blogs après les avoir écrits, en particulier les autorisations de rôle. S'il y a une exigence commerciale, il est fondamentalement très simple à développer en fonction d'une telle minimisation du tableau de bord. J'ai traité les autorisations dans les projets précédents à plusieurs reprises, mais cette fois, c'est GraphQL, qui est légèrement différent de la précédente Restful, donc j'ai encore passé du temps à lancer.
J'ai écrit tellement de code avec Nest.js, mais ce n'est pas confortable à considérer. La raison de choisir est que je suis attiré par tout son paradigme et le support de dactylographe qui est armé aux dents. L'auteur @kamilmysliwiec est toujours très puissant. Certaines des implémentations d'emballage de Nest.js sont très exquises. La chose la plus importante est également combinée avec diverses technologies et a mis en œuvre de nombreux scénarios commerciaux. C'est vraiment génial.
React + ANTD est une sélection de technologie courante sur dashboard . Cependant, cette fois, car hooks sont entièrement lancés, notamment Apollo, les dernières versions bêta de crochets, et la classe est presque impossible à voir dans l'ensemble du projet. Cependant, après avoir utilisé des crochets à grande échelle, le code semble vraiment moche. Si la clarté du code de classe était marquée de 10 points dans le passé, les crochets ne pouvaient marquer que 5 points. Bien sûr, la chose la plus évidente est de gagner un code partageant FN. S'il s'agissait de classe, il serait assez difficile de partager la classe FN.
Il n'y a pas le choix pour www , il ne peut être que le prochain.js. En fait, j'ai déjà développé un ensemble relativement complet de React-SSR, mais pour m'adapter à la vague, et le dieu @Gillermo le pousse et le fait sauter tous les jours, je ne pouvais pas m'empêcher d'acheter Next.js. Lorsque j'ai commencé à écrire www, il m'est arrivé de rattraper la sortie de Next.js V9, qui est une nouvelle version du navire qui a été réécrite dans TS depuis Core. Je pensais que ce serait très fluide à utiliser, mais je ne m'attendais pas à ce que ce soit une astuce ...
Après tout, Antd doit être intégré, ce qui signifie que le code des pages du client doit utiliser CSSModule pour moins, ANT ne l'utilise pas et le serveur le lancera lorsque vous en verrez moins. Par conséquent, le plug-in officiel avec un plug-in sans gestion jusqu'à 60%, et le support de 40% restant est insuffisant. À l'origine, comme Next.js et CRA, c'est comme envelopper WebPack. Je ne veux vraiment pas que vous touchez le cancer frontal, et c'est un tracas de poulet sauté.
Cependant, je voudrais dire qu'un cadre vous donnera plusieurs fois la commodité au début du projet, donc cela vous causera plusieurs fois les problèmes au stade ultérieur du projet. Cela est vrai pour l'ARC, l'Expo et Next.js ne fait pas exception, les deux sont des boîtes noires. Ensuite, je dois écrire un 100% avec Plugin en deux heures, ou le projet restera coincé. J'ai regardé Github et je voulais voir s'il y avait une solution, mais malheureusement, je n'ai pas pu trouver le code pertinent juste après V9. Il semble que je ne peux que me baiser. Bien que je sois très familier avec WebPack, Next.js a ajouté une fine couche de boîte noire à WebPack, l'écriture avec Plugin a une sorte de submergée dans une mer inconnue de contexte. C'est une décision très frustrante, mais heureusement, cela a finalement été fait dans une demi-heure. J'ai mentionné un problème avec ma propre résolution et je l'ai rapidement fermé lorsqu'il n'a pas été découvert. J'espère aider les gars qui rencontrent le même problème lors de la recherche d'un problème. Après tout, il y a encore beaucoup de gens qui ont besoin de Suivant.js + Antd avec des sans-fin, surtout en Chine.
Le temps passe si vite et un demi-mois s'est écoulé en un clin d'œil. Je n'ai rien écrit de nouveau à Leaa récemment. L'accent est mis sur l'intégration du cloud OSS d'alibaba. Veulent implémenter une telle fonction:
Le processus est assez difficile, impliquant certaines interactions entre local et OSS. De plus, en raison de l'OSS directement, toutes les demandes ne sont pas passées par l'API et deviennent des rappels en attente d'OSS. Il est nécessaire de s'assurer que la base de données ne peut pas être déplacée sans terminer aucune étape, atteignant à peine idempotence. En fait, si le téléchargement se fait via l'API, alors l'API est traitée uniformément puis mise à OSS, elle sera simple et très grande. Je m'inquiète principalement que lors de certaines activités, si le téléchargement des fichiers est impliqué, la concurrence sera très grande et que le serveur ne pourra pas récupérer. Il est donc nécessaire de bloquer l'OSS en premier.
Fondamentalement, www, l'API et le tableau de bord ont pris fin. Commencez miniprogram demain.
Lorsque j'ai trié le package pour la première fois, j'ai constaté que React a été mis à niveau à 16.9.0. J'ai consolé le prochain groupe d' Warning: componentWillMount... J'ai regardé React Changelog et j'ai constaté que c'était en effet un changement majeur. Quelques lifecycle seront jetés dans la future version. Étant donné que Leaa-Dashboard dépend de antd , il est préférable d'attendre la libération antd pour éliminer ces avertissements avant la mise à niveau. Actuellement, React est verrouillé dans "react": "16.8.6", "react-dom": "16.8.6" .
J'ai fait une bannière Leaa Stack et je l'ai mise au sommet de Readme. La technique utilisée pour décrire les images est bien meilleure que le texte. Mentionnez également le nom Leaa . C'est en fait le nom d'une actrice française Léa Seydoux que j'aime. Pour éviter le taux de duplication élevé, j'ai ajouté un supplément en un derrière. Cependant, le point le plus courant LEAA sur Google est Law Enforcement Assistance Administration un organisme judiciaire américain (rires).
Je viens d'utiliser des peluches pour trouver plusieurs erreurs dans le projet. Ce qui est plus intéressant, ce sont packages/leaa-dashboard/src/pages/Permission/PermissionList/PermissionList.tsx L159 Ici, printWidth du projet .prettierrc et max-len de .eslintrc.js sont fixées à 120 , mais plus jolie ne rapporte pas une erreur et ne forme pas automatiquement, mais Eslint m'a dit que c'est plus que 120.
J'ai dû ajouter eslint-disable-next-line max-len . Il est très probable que l'un d'eux soit utilisé > et l'autre est >= . Cependant, après avoir modifié les propriétés des deux, j'ai constaté que ce n'était pas le problème. Oubliez-le, ajoutez d'abord Max-Len. À l'heure actuelle, il n'y a qu'un seul endroit qui n'est que. S'il n'y a pas assez de spécimens, je ne vais pas y faire face. Je traiterai ce problème à l'avenir.
Bien que je fasse attention au code de style, j'utiliserai l'IDE pour écrire Marco avec Keymap et appliquer des règles prettier et eslint au format. Mais après le public du projet, il peut y avoir des contributeurs à venir (non, pas de HHHH), et je pense qu'il serait préférable de brancher le style de code dans git commit .
Habituellement, un husky suffit pour le projet, mais il y a tellement de fichiers monorepo. Chaque fois que git commit tous les packages, tous les fichiers seront inévitablement eslint , il est donc nécessaire de coopérer avec lint-staged pour minimiser le traitement Eslint, et de laisser les fichiers en stade git exécuter Eslint cette fois.
Cependant, il semble que le fonctionnaire n'a pas donné trop de suggestions et d'exemples pour Monorepo. Après l'avoir exploré, j'ai trouvé que ce n'était pas gênant, mais ce n'était pas beaucoup la même que le non-monorepo. Afin de se découpler à partir de pacakge.json , je l'ai également écrit dans un fichier de configuration, à peu près ceci:
module . exports = {
'packages/**/*.ts?(x)' : [ 'prettier --write' , 'eslint' , 'git add' ] ,
'packages/**/*.(css|less)' : [ 'prettier --write' , 'stylelint' , 'git add' ] ,
} ;Je l'ai essayé et c'était assez rapide. Il peut prendre un certain temps pour connaître l'effet si vous avez de meilleures meilleures pratiques.
J'ai essayé Taro pendant environ une nuit et ça ne semblait pas très idéal. Pourquoi? Tout d'abord, ce dont j'ai besoin, c'est d'une React à l'小程序, et ce que je veux, c'est ONLY applet. Quant à savoir pourquoi il ne l'est pas, je vais expliquer en détail plus tard.
Après une utilisation initiale, Taro a l'impression d'être un maître. Il a une lourde responsabilité et doit être compatible avec trop d'environnements类小程序, tels yoga支付宝小程序,今日头条小程序RN etc. L'équipe est encore très difficile. Je l'admire toujours beaucoup. Je dois donner un coup de pouce ici. Ensuite, je parlerai de mes sentiments généraux après quelques heures.
Parfait! Il en va de même pour le développement Web normal, il n'y a rien à dire. Prend en charge la GRH et prend en charge le module CSS. Ne vous souciez pas de webpack , vous pouvez l'exécuter simplement en arrivant. Cependant, une chose qui mérite d'être notée est que si vous voulez être compatible avec RN , vous ne pouvez pas utiliser taro-ui ou d'autres LIB d'interface utilisateur tiers. Vous ne pouvez utiliser que le composant intégré @tarojs/component . Cette restriction semble être assez coincée. J'espère que taro-ui soutiendra RN dès que possible.
C'est aussi très parfait et il n'y a pas de mauvaise chose. Après avoir couru, ouvrez les outils officiels de débogage de WeChat et allez sur la route en douceur. Le seul piège est qu'il n'est pas amical pour le soutien monorepo , bien sûr, cela est compréhensible. Il y a peu de gens qui utilisent monorepo en Chine. Si vous l'utilisez, vous devez le personnaliser comme une attitude de "vous avez la possibilité de résoudre tout problème sur monorepo ". Je cours sous monorepo et j'ai rencontré ce problème:
can't find module : ../../../node_modules/@tarojs/taro-weapp/
Il y a aussi des gens dans la communauté qui parlent de problèmes, tels que le soutien de Monorepo. Mon approche est similaire à celle de lui. Ils utilisent le nohoist de Warn Wokesspaces pour le faire. Cependant, ma solution est de ne garder que des modules liés à Taro sous sous-package. Pour d'autres choses, il est préférable d'améliorer et de maximiser les modules de partage:
{
"nohoist" : [ " **/@tarojs/** " ]
} Je l'ai couru après avoir vu dev:rn dans package.json . Le résultat a été bon. J'ai vu l'invite que la compilation a réussi, mais il n'y avait pas de suivi ... puis je suis allé aux documents officiels et j'ai trouvé ça un peu compliqué. Alors, quelle est la différence entre cela et d'essayer de faire un ensemble de développement de RN natif seuls? Et si vous comptez sur Taro , RN est verrouillée à 0.55.4 , mon Dieu! Ceci est loin du numéro de version officielle de 0.60.x Vous devez savoir que chaque itération de la version de RN est un saut qualitatif. Si vous utilisez 0.60.x , vous pouvez également gagner Hermès sur Android, et l'efficacité sera considérablement améliorée. Une autre chose qui me fait m'inquiéter, c'est que l'utilisation RN@Taro signifie que vous ne pouvez utiliser que l'interface utilisateur @tarojs/component , ce qui signifie que vous devez abandonner NativeBase et Shoutem qui sont des LIB d'interface utilisateur de haute qualité sur RN .
Eh bien ... pour résumer, si vous ne pensez pas à économiser les coûts et le temps, et que vous souhaitez一套代码多处运行, il est recommandé de renoncer RN@Taro . Si vous voulez parler du meilleur temps d'entrée, je pense que c'est au moins taro-ui qui prend en charge RN . Bien sûr, ce coût est trop élevé, et il est très possible que le fonctionnaire ne fournisse jamais de soutien.
Ok, revenons au sujet. Mon intention initiale d'utiliser Taro était d'utiliser uniquement pour les mini programmes au début, donc je pense que "tout va bien" pour la situation actuelle. leaa-app est toujours RN ou expo , après tout, l'astuce se fait essentiellement dans les projets passés (rires).
C'est tellement triste d'enregistrer votre expérience d'utilisation Taro pendant la journée aujourd'hui ...
Tout d'abord, la chose la plus douloureuse est que @apollo/react-hooks et react-apollo ne sont pas pris en charge! En d'autres termes, aucun package officiel Apollo ne peut être utilisé! Vous ne pouvez pas useQuery et ne permettez même pas <Query> . Si vous l'utilisez, vous vous rapporterez des crochets Invariant Violation: Invalid hook call. Le résultat est que vous pouvez écrire directement l'exportation apolloClient apolloClient.query() . C'est vraiment une nuit avant la libération!
Je pensais à l'origine que c'était pratique, et j'étais très heureux de fonctionner en mode H5 en débogage et apolloClient Je ne m'attendais pas à ce que小程序monté soit apparu et a dit que fetch is not found globally and no fetcher passed, to fix pass.... J'ai vérifié les informations et j'ai dit que c'était "dans une certaine mise à niveau du mini programme WECHAT, le Global Fetch a été supprimé" ... heureusement, j'ai immédiatement trouvé le lib wx-apollo-fetch-fetch écrit par mon prédécesseur. Il n'y a que quelques lignes de toute la bibliothèque:
return new Promise(resolve =>
wx.request({
...
complete: ({ data, statusCode, errMsg }) => resolve({...})
}))
Remplacez-le ensuite sur HttpLink et devenez fetch: wxApolloFetcher . Je ne m'attendais pas à ce que WeChat fasse une telle mise à jour de style Cliff, ce qui est vraiment une opération raisonnable.
Vient ensuite la question de l' alias de chemin. Les problèmes officiels de ce poste ont été discutés le plus intensément. Je l'ai essayé après l'avoir lu, mais il n'avait toujours pas de solution. La solution ici est que la solution est que la solution du côté小程序n'est pas, et H5 est bon. Ce ... je suis monorepo après tout, et cela deviendrait très embarrassant si je ne peux pas partager le code dans @leaa/common . Ok, je ne l'utiliserai plus, le supportez.
Je pensais que c'était déjà un tourment après avoir vécu le développement RN , mais cette fois ... Oh, ne parlons plus, je blâme la technologie que j'ai utilisée est trop nouvelle (bang).
? Lire plus ...
