leaa
v3.9.0
LeaA es un CMS Monorepo (sistema de gestión de contenido) construido con Nest.js, Next.js y Hormy Design.
Vea el README.md de cada subdirectorio en packages . Es posible que primero deba mirar los espacios de trabajo de Yarn.
Diádico
Originalmente, el resumen debe escribirse al final del artículo, pero creo que debe presentarse, al menos no tengo que leer mi molestia sobre los registros de desarrollo.
Solía pensar que trataría de conectarme al 5 extremo escribiendo un proyecto de pila completo. No tenía tiempo y seguí arrastrándolo. Cuando lo escribí, pensé que tomaría más de medio año, pero no esperaba que solo tomara un meses y medio para hacerlo. Y también busqué las mejores prácticas en muchos lugares, y en general estaba bastante satisfecho.
La intención original del proyecto era usar React o principalmente sintaxis JSX para hacer más cosas, como escribir mini programas o aplicaciones, y el marco técnico existente también respalda mi idea. Comencé a seguir el camino con mi experiencia previa y algunas tecnologías más nuevas como GraphQL .
No hay muchos problemas encontrados en api , dashboard y www , pero miniprogram (小程序，下文简称mp) y app no son tan afortunadas porque no son web 语言estándar. Son como la representación HTML 富文本, lo que naturalmente admite web . En ellos, se vuelven fuckingSelf y necesitan ser analizados por sí mismos, como a enlace, porque no existe tal a en mp y app . Lo que les sucede a los usuarios Haga clic en a depende completamente del desarrollador para decidir, que es completamente diferente de la "aplicación web " que desarrollé antes. Si tuviera experiencia en el desarrollo App antes, creo que habría menos dificultades para mentir.
Hablando de trampas, creo que mis habilidades de excavación en boxes son realmente sorprendentes. RN es popular porque tiene muchos pozos y se cree que es bien conocido. Está bien, lo elegí. Es posible que no conozca las trampas de monorepo , pero de hecho pueden hacer que la gente muera. Está bien, elegiré. No hay muchas dificultades en el desarrollo RN con TS , pero también hay muchos. Ok, yo también lo elegí. Luego elegí este RN + monorepo + TS Super Big Pit (Cry), pero todavía me acosté poco a poco después, y realmente admiro mi paciencia (extendiendo mis manos).
¿Por qué elegir monorepo para desarrollar? Mi intención original era compartir interface de TS y algunas configuraciones reutilizables en los 5 del lado, pero más tarde, cuando escribí mp y app , descubrí que debido a algunos de sus mecanismos especiales, no pude compartirlos. De hecho, mp y app están completamente aislados de monorepo . Si refactoro el código más tarde, pondré estas "非标准web 应用" por separado en un repositorio porque son realmente difíciles de servir. node_modules también tiene uno que no se puede compartir, y cada uno es muy grande. No es la clave, la clave es que cada vez que yarn install , está muy lleno y la CPU está aumentando que la computadora está a punto de despegar. Originalmente, tiendo a usar yarn workspaces para resolver mono sin lerna , pero debido a este problema, intenté conseguir en lerna , pero el problema no pareció mejorar, por lo que tuve que rendirme. Esta vez realmente me di experiencia con monorepo , que puede considerarse como un dolor por la carne, y también me hizo saber cómo elegir mono y multi .
Ok, si se me pidiera que escribiera una clasificación de dificultad de 5 lados ahora, creo que sería como este mp > app > www > api > dashboard .
¿Por qué mp figura como la parte más difícil? Porque mp no solo tiene muchos productos privados, sino que también DevTools también tiene sorprendentemente muchos errores. A veces reparo un error, pero no funciona bien durante mucho tiempo, pero es suficiente para reiniciar DevTools. Esto realmente me hace vomitar sangre. Y debido a que usé Taro , muchas características nuevas, como custom-tab-bar no lo mantuvieron al día y no había documentación. Lo descubrí solo, pero me llevó mucho tiempo. Por supuesto, si usa Taro y tiene el requisito custom-tab-bar , leaa puede ser la solución óptima para la solución GitHub existente en la actualidad.
Además, tenía mucho que decir sobre www ( Next.js v9), pero a medida que pasa el tiempo, estas cosas que decir gradualmente desaparecen. Este tipo de "no quiero decir" no es el tipo de "no es difícil para aquellos que no son difíciles", sino porque Next.js tiene demasiadas dificultades, resolver un pozo inevitablemente conducirá a varias otras dificultades. Además, no hay mejores prácticas a las que se consulte. Todos son example simples. Una vez que desee hacer algunas funciones complejas, este tipo de "SSR" que necesita ser procesado por los extremos delanteros y traseros hace que las personas se sientan como "ocultas inseguras". Con cada cambio en la versión Next.js como 8to9, habrá muchos cambios en forma de acantilado. No hay forma, la cultura de Zeit es así, y solo puedes consolarte con "toda la infelicidad proviene de no ser lo suficientemente fuerte".
Para monorepo , hay muchos archivos con "nombres de archivos similares" en un proyecto. Muchas veces siento que estoy abrumado por los archivos y puedo interferir fácilmente cuando busco archivos. Incluso si me rindo usando Components/Filter/index.tsx para nombrar los archivos con Components/Filter/Filter.tsx para encontrar cmd +. p puede ubicar rápidamente el archivo en sí en lugar del directorio, pero también es difícil deshacerse de esta sensación de "infierno de archivo".
Originalmente se dijo que no debía quejarme si podía escribir un resumen, pero ahora parece que todavía hay algunas quejas. En cualquier lugar, desde Docker hasta Api hasta UI/UX , el proceso de escritura leaa me ha enseñado mucho, y tengo una comprensión más profunda de la arquitectura de software y los principios de apertura y cierre. En el pasado, pensé que la "codificación" y la "arquitectura" en realidad estaban haciendo lo mismo, pero esta vez tengo una comprensión más profunda.
En la actualidad, hay muchos, muchos errores leaa , pero esto no parece evitar que las personas necesitadas recuperen el código útil para leaa a través de Github. Esta es también mi intención original de escribir leaa , arriba. 2019-09-17 17:01 @ Guangxi Hezhou
De Git Commit, podemos ver que este registro de desarrollo (registro de desarrollo) solo está escrito ahora. El proyecto se llamaba originalmente 1D1H, lo que significa una hora al día. Quiero reunir la experiencia previa de escribir extremos frontales y traseros en mi tiempo libre y hacer un proyecto de código abierto de Blog -> CMS -> SOHP, incluido API / Dashboard / Sitio web / WeChat WAUPPP / React Native (iOS / Android). Debido a que es un monorepo, similar a la interfaz / entrada, se comparten, por lo que considera que es algo muy conveniente construir una plataforma completa.
De hecho, originalmente quería escribir este registro de desarrollo antes, pero en los primeros días, gasté muchos problemas que debían resolverse, y realmente no pude encontrar tiempo para escribir registros. Ahora lo pienso, realmente no debería ser así. Después de todo, si grabé muchos problemas antes, en realidad era riqueza invisible. Aunque volví a conocer de nuevo, definitivamente sabría cómo resolverlos, pero no pude compartirlos con los demás. Pero revisaré los siguientes registros lentamente.
Déjame hablar sobre mi comprensión del tablero aquí. Creo que se debe incluir un tablero mínimo disponible.
Estos módulos se pueden usar básicamente como blogs después de escribirlos, especialmente los permisos de roles. Si hay un requisito comercial, es básicamente muy simple desarrollar en base a tal minimización del tablero. He procesado permisos en proyectos anteriores muchas veces, pero esta vez es GraphQL, que es ligeramente diferente de lo anterior RESTFUL, por lo que todavía pasé un tiempo a lanzar.
He escrito tanto código con Nest.js, pero no es cómodo de considerar. La razón para elegir es que me atrae todo su paradigma y el apoyo de mecanografiado que está armado hasta los dientes. El autor @kamilmysliwiec sigue siendo muy poderoso. Algunas de las implementaciones de embalaje de Nest.js son muy exquisitas. Lo más importante también se combina con varias tecnologías y ha implementado muchos escenarios comerciales. Esto es realmente genial.
React + Antd es una selección de tecnología común en dashboard . Sin embargo, esta vez, porque hooks se lanzan completamente, incluido Apollo, las últimas versiones beta de Hooks, y la clase es casi imposible de ver en todo el proyecto. Sin embargo, después de usar ganchos a gran escala, el código se ve realmente feo. Si la claridad del código de clase se anotó 10 puntos en el pasado, Hooks solo podía anotar 5 puntos. Por supuesto, lo más obvio es ganar un código compartiendo FN. Si fuera clase, sería bastante problemático compartir la clase FN.
No hay otra opción para www , solo puede ser Next.js. De hecho, he desarrollado un conjunto relativamente completo de react-ssr antes, pero para adaptarme a la ola, y el dios @Guillermo lo está empujando y soplándolo todos los días, no pude evitar comprar Next.js. Cuando comencé a escribir WWW, me puse al día con el lanzamiento de Next.js V9, que es una nueva versión del barco que ha sido reescribida en TS desde el núcleo. Pensé que sería muy suave de usar, pero no esperaba que fuera un truco ...
Después de todo, Antd debe integrarse, lo que significa que el código de páginas del cliente debe usar CSSMODULE por menos, Antd no lo usa, y el servidor lo lanzará cuando ve menos. Por lo tanto, el complemento oficial sin problemas solo puede administrar hasta el 60%, y el soporte restante del 40% es insuficiente. Originalmente, como Next.js y CRA, es como envolver Webpack. Realmente no quiero que toques el cáncer frontal, y es una molestia de pollo saltador.
Sin embargo, me gustaría decir que un marco le dará varias veces la conveniencia en la etapa inicial del proyecto, por lo que le causará varias veces los problemas en la etapa posterior del proyecto. Esto es cierto para CRA, Expo y Next.js no es una excepción, ambas son cajas negras. Luego tengo que escribir un 100% con Plugin en dos horas, o el proyecto se atascará. Miré a través de Github y quería ver si había una solución, pero desafortunadamente no pude encontrar el código relevante justo después de V9. Parece que solo puedo follarme. Aunque estoy muy familiarizado con Webpack, Next.js agregó una capa delgada de caja negra a Webpack, escribir con Plugin tiene una especie de sumergido en un mar desconocido de contexto. Es un movimiento muy frustrante, pero afortunadamente, finalmente se hizo en media hora. Mencioné un problema con mi propia resolución y lo cerré rápidamente cuando no se descubrió. Espero ayudar a los chicos que se encuentran con el mismo problema al buscar el problema. Después de todo, todavía hay muchas personas que necesitan Next.js + Antd sin más, especialmente en China.
El tiempo vuela muy rápido, y medio mes ha pasado en un abrir y cerrar de ojos. No he escrito nada nuevo en Leaa recientemente. La atención se centra en la integración del OSS de la nube de Alibaba. Quiere implementar dicha función:
El proceso es bastante difícil, que implica algunas interacciones entre local y OSS. Además, debido al OSS directamente, todas las solicitudes no se pasan por la API y se convierten en devoluciones de llamada esperando OSS. Es necesario asegurarse de que DB no se pueda mover sin completar ningún paso, apenas logrando idempotencia. De hecho, si la carga se realiza a través de la API, la API se procesa de manera uniforme y luego se coloca en OSS, será simple y muy grande. Principalmente me preocupa que al realizar ciertas actividades, si se trata de cargar archivos, la concurrencia será muy grande y el servidor no podrá recuperarse. Por lo tanto, es necesario bloquear el OSS primero.
Básicamente, WWW, API y Panel de tablero llegaron a su fin. Comienza miniprogram mañana.
Cuando ordené el paquete por primera vez, descubrí que React se ha actualizado a 16.9.0. Consolé el siguiente grupo de Warning: componentWillMount... miré a React Changelog y descubrí que de hecho era un cambio importante. Algunos lifecycle se descartarán en la versión futura. Dado que Leaa-Dashboard depende de antd , es mejor esperar a que la liberación antd elimine estas advertencias antes de actualizar. Actualmente React está bloqueado en "react": "16.8.6", "react-dom": "16.8.6" .
Hice una pancarta de la pila de Leaa y lo puse en la parte superior de Readme. La técnica utilizada para describir imágenes es mucho mejor que el texto. También mencione el nombre Leaa . Este es en realidad el nombre de una actriz francesa Léa Seydoux que me gusta. Para evitar la alta tasa de duplicación, agregué un extra A detrás de Lea. Sin embargo, el punto más común LEAA en Google es Law Enforcement Assistance Administration un organismo judicial estadounidense (risas).
Acabo de usar la pelusa para encontrar varios errores en el proyecto. Lo que es más interesante son packages/leaa-dashboard/src/pages/Permission/PermissionList/PermissionList.tsx L159 Aquí, printWidth del proyecto .prettierrc y max-len de .eslintrc.js está configurado en 120 , pero Prettier no informa un error y no funciona de forma formatada automáticamente, pero Eslint me dijo que es más que 120.
Tuve que agregar eslint-disable-next-line max-len . Se siente muy probable que uno de ellos use > y el otro es >= . Sin embargo, después de modificar las propiedades de ambos, descubrí que este no es el problema. Olvídalo, agregue Max-Len primero. En la actualidad, solo hay un lugar que es solo. Si no hay suficientes especímenes, no lo trataré. Trataré este problema en el futuro.
Aunque presto atención al código de estilo, usaré el IDE para escribir Marco con Keymap y aplicar reglas prettier y eslint para formatear. Pero después del público del Proyecto, puede haber contribuyentes entrando (no, no HHHH), y creo que sería mejor enchufar el estilo de código en git commit .
Por lo general, un husky es suficiente para el proyecto, pero hay tantos archivos Monorepo. Cada vez que git commit todos los paquetes, todos los archivos se verán inevitablemente eslint , por lo que es necesario cooperar con lint-staged para minimizar el procesamiento de Eslint, y solo dejar que los archivos en la etapa GIT ejecuten eslint esta vez.
Sin embargo, parece que el funcionario no ha dado demasiadas sugerencias y ejemplos para Monorepo. Después de explorarlo, descubrí que no era problemático, pero no era lo mismo que el no monorreo. Para desacoplar de pacakge.json , también lo escribí en un archivo de configuración, aproximadamente así:
module . exports = {
'packages/**/*.ts?(x)' : [ 'prettier --write' , 'eslint' , 'git add' ] ,
'packages/**/*.(css|less)' : [ 'prettier --write' , 'stylelint' , 'git add' ] ,
} ;Lo probé y fue bastante rápido. Puede tomar algún tiempo conocer el efecto si tiene mejores prácticas mejores.
Probé Taro durante una noche y no se sentía muy ideal. ¿Por qué? En primer lugar, lo que necesito es React al marco de小程序, y lo que quiero es ONLY . En cuanto a por qué es solo, explicaré en detalle más adelante.
Después del uso inicial, Taro siente que es un maestro. Tiene una gran responsabilidad y debe ser compatible con demasiados entornos类小程序, como支付宝小程序,今日头条小程序, etc. y también debe considerar compatible con el motor CSS yoga hostil de RN . El equipo sigue siendo muy difícil. Todavía lo admiro mucho. Debo dar los pulgares aquí arriba. A continuación, hablaré sobre mis sentimientos generales después de unas horas.
¡Perfecto! Lo mismo es cierto para el desarrollo web normal, no hay nada que decir. Admite HRM y admite el módulo CSS. No me importa webpack , puede ejecutarlo simplemente por venir. Sin embargo, una cosa que vale la pena señalar es que si quieres ser compatible con RN , no puedes usar taro-ui u otras libras de UI de terceros. Solo puede usar el @tarojs/component incorporado. Esta restricción parece estar bastante atascada. Espero que taro-ui apoye RN lo antes posible.
También es muy perfecto, y no hay nada malo. Después de correr, abra las herramientas oficiales de depuración de WeChat y salga a la carretera sin problemas. La única dificultad es que no es amigable para el apoyo monorepo , por supuesto, esto es comprensible. Hay pocas personas que usan monorepo en China. Si lo usa, debe personalizarlo como una actitud de "tiene la capacidad de resolver cualquier problema en monorepo ". Corrí bajo monorepo y encontré este problema:
can't find module : ../../../node_modules/@tarojs/taro-weapp/
También hay algunas personas en la comunidad que están hablando de problemas, como el apoyo de Monorepo. Mi enfoque es similar al de él. Usan el nohoist de los espacios de wokess de hilos para hacerlo. Sin embargo, mi solución es solo mantener los módulos relacionados con Taro bajo el subgrado. Para otras cosas, es mejor mejorar y maximizar los módulos de compartir:
{
"nohoist" : [ " **/@tarojs/** " ]
} Lo ejecuté después de ver dev:rn en package.json . El resultado fue bueno. Vi el aviso de que la compilación fue exitosa, pero no hubo seguidores ... luego fui a los documentos oficiales y lo encontré un poco complicado. Entonces, ¿cuál es la diferencia entre esto y tratar de hacer un conjunto de desarrollo nativo de RN solo? Y si confías en Taro , RN está bloqueada en 0.55.4 , ¡Dios mío! Esto está lejos del número de versión oficial de 0.60.x Debe saber que cada versión de iteración de RN es un salto cualitativo. Si usa 0.60.x , también puede ganar Hermes en Android, y la eficiencia mejorará mucho. Otra cosa que me hace preocuparme es que usar RN@Taro significa que solo puedes usar el UI lib @tarojs/component , lo que significa que tienes que renunciar NativeBase y Shoutem que son Libs UI de calidad relativamente alta en RN .
Bueno ... para resumir, si no está pensando en ahorrar costos y tiempo, y querer一套代码多处运行, se recomienda renunciar RN@Taro . Si quieres hablar sobre la mejor hora de entrada, creo que es al menos taro-ui lo que admite RN . Por supuesto, este costo es demasiado alto, y es muy posible que el funcionario nunca brinde apoyo.
Ok, volvamos al tema. Mi intención original de usar Taro era usar solo para mini programas al principio, por lo que creo que "todo está bien" para la situación actual. leaa-app todavía es RN o expo , después de todo, el truco se realiza básicamente en los proyectos pasados (risas).
Es muy triste registrar su experiencia de usar Taro durante el día de hoy ...
En primer lugar, lo más doloroso es que @apollo/react-hooks y react-apollo no son compatibles. En otras palabras, ¡no se puede usar ningún paquete oficial de Apolo! No puede useQuery y ni siquiera permitas <Query> . Si lo usa, le informará ganchos Invariant Violation: Invalid hook call. El resultado es que puede escribir la exportación apolloClient apolloClient.query() directamente. ¡Esta es realmente una noche antes de la liberación!
Originalmente pensé que era conveniente, y estaba muy feliz de ejecutar en modo H5 depurando y apolloClient No esperaba ...小程序apareció y dijo que fetch is not found globally and no fetcher passed, to fix pass.... revisé la información y dije que estaba "en una cierta actualización de WeChat Mini Program, la búsqueda global fue eliminada" ... Afortunadamente, inmediatamente encontré el Lib WX-Apollo-Apolcocher escrito por mi predecesor. Solo hay unas pocas líneas de toda la biblioteca:
return new Promise(resolve =>
wx.request({
...
complete: ({ data, statusCode, errMsg }) => resolve({...})
}))
Luego reemplácelo en HttpLink y conviértete en fetch: wxApolloFetcher . Nunca esperé que WeChat hiciera una actualización de estilo acantilado, que es realmente una operación sensata.
El siguiente es el problema del alias de ruta. Los problemas oficiales de esta publicación se discutieron más intensamente. Lo probé después de leerlo, pero todavía no tenía solución. La solución aquí es que la solución es que la solución en小程序no lo es, y H5 es bueno. Esto ... soy monorepo después de todo, y sería muy vergonzoso si no puedo compartir el código en @leaa/common . Ok, ya no lo usaré, tenlo.
Pensé que ya era un tormento después de experimentar el desarrollo RN , pero esta vez ... oh, no hablemos más de eso, culpo a la tecnología que utilicé es demasiado nueva (Bang).
? Leyendo más ...
