leaa
v3.9.0
O Leaa é um CMS Monorepo (sistema de gerenciamento de conteúdo) construído com o Nest.js, Next.js e Ant Projeto.
Veja o README.md de cada subdiretório em packages . Pode ser necessário olhar primeiro para os espaços de trabalho de Yarn.
Todos
Originalmente, o resumo deve ser escrito no final do artigo, mas sinto que ele deve ser apresentado, pelo menos não preciso ler minhas incômodas sobre os registros de desenvolvimento.
Eu costumava pensar que tentaria me conectar ao 5 final, escrevendo um projeto de pilha completa. Eu não tinha tempo e continuava arrastando -o. Quando escrevi, pensei que levaria mais de meio ano, mas não esperava que levasse apenas um mês e meio para fazê -lo. E também procurei práticas recomendadas em muitos lugares e, no geral, fiquei bastante satisfeito.
A intenção original do projeto era usar React ou principalmente a sintaxe JSX para fazer mais coisas, como escrever mini programas ou aplicativos, e a estrutura técnica existente também suporta minha ideia. Comecei a ir à estrada com minha experiência anterior e algumas tecnologias mais recentes, como GraphQL .
Não há muitos problemas encontrados na api , dashboard e www , mas miniprogram (小程序，下文简称mp) e app não têm tanta sorte porque não são web 语言padrão. Eles são como a renderização HTML 富文本, que naturalmente suporta web . Sobre eles, eles se tornam fuckingSelf e precisam ser analisados por si mesmos, como a link, porque não existe esse a no mp e app . O que acontece com os usuários de clique em a depende inteiramente do desenvolvedor para decidir, o que é completamente diferente do "aplicativo web " que desenvolvi antes. Se eu tivesse experiência em desenvolvimento App antes, acredito que haveria menos armadilhas para mentir.
Falando em armadilhas, acho que minhas habilidades de escavação de pit são realmente incríveis. RN é popular porque tem muitos poços e acredita -se ser bem conhecido. Ok, eu escolhi isso. Você pode não conhecer as armadilhas de monorepo , mas elas podem realmente fazer as pessoas morrerem. Ok, vou escolher. Não há muitas armadilhas no desenvolvimento RN com TS , mas também existem muitos. Ok, eu escolhi isso também. Então eu escolhi este RN + monorepo + TS super grande poço (choro), mas ainda deitei pouco a pouco depois, e realmente admiro minha paciência (espalhando minhas mãos).
Por que escolher monorepo para desenvolver? Minha intenção original era compartilhar interface do TS e algumas configurações reutilizáveis nos 5 lados, mas mais tarde quando escrevi mp e app , descobri que, devido a alguns de seus mecanismos especiais, não consegui compartilhá-los. De fato, mp e app são completamente isolados do monorepo . Se eu refatorar o código mais tarde, colocarei esses "非标准web 应用" separadamente em um repositório porque eles são realmente difíceis de servir. node_modules também possui um que não pode ser compartilhado e cada um é muito grande. Não é a chave, a chave é que toda vez que yarn install , está muito cheio, e a CPU está subindo que o computador está prestes a decolar. Originalmente, eu costumo usar yarn workspaces para resolver mono sem lerna , mas por causa desse problema, tentei entrar em lerna , mas o problema não parecia melhorar, então tive que desistir. Desta vez, eu realmente me dei experiência com monorepo , que pode ser considerado como uma dor da carne, e também me avisa como escolher mono e multi .
Ok, se eu fosse solicitado a escrever um ranking de dificuldade de 5 lados agora, acho que seria como este mp > app > www > api > dashboard .
Por que mp é listado como a parte mais difícil? Como mp não apenas possui muitos produtos privados, mas também o Devtools também tem surpreendentemente muitos bugs. Às vezes, reparo um bug, mas não funciona bem por um longo tempo, mas é o suficiente para reiniciar o Devtools. Isso realmente me faz vomitar sangue. E como eu usei Taro , muitos novos recursos, como custom-tab-bar não o acompanhavam e não havia documentação. Eu descobri sozinho, mas demorou muito tempo. Obviamente, se você usar Taro e tiver o requisito custom-tab-bar , leaa pode ser a solução ideal para a solução do GitHub existente.
Além disso, eu tinha muito a dizer sobre www ( Next.js v9), mas com o passar do tempo, essas coisas a dizer gradualmente desaparecem. Esse tipo de "não querer dizer" não é o tipo de "não difícil para aqueles que não são difíceis", mas porque Next.js tem muitas armadilhas, resolver um poço inevitavelmente levará a várias outras armadilhas. Além disso, não há práticas recomendadas para você se referir. Eles são todos example simples. Depois que você deseja fazer algumas funções complexas, esse tipo de "SSR" que precisa ser processado pelas extremidades da frente e da parte traseira faz com que as pessoas se sintam "indizíveis ocultas". Com todas as mudanças na versão Next.js como 8to9, haverá muitas mudanças semelhantes a penhascos. Não há como a cultura de Zeit é assim, e você só pode se confortar com "toda a infelicidade vem de não ser forte o suficiente".
Para monorepo , existem muitos arquivos com "nomes de arquivos semelhantes" em um projeto. Muitas vezes, sinto que estou impressionado com os arquivos e posso ser facilmente interferido ao procurar arquivos. Mesmo se eu desistir usando Components/Filter/index.tsx para nomear os arquivos com Components/Filter/Filter.tsx para encontrar cmd +. p pode localizar rapidamente o próprio arquivo em vez do diretório, mas também é difícil se livrar dessa sensação de "o inferno do arquivo".
Dizia -se originalmente que eu não deveria reclamar se pudesse escrever um resumo, mas agora parece que ainda existem algumas queixas. Em qualquer lugar, do Docker à Api e UI/UX , o processo de escrever leaa realmente me ensinou muito, e eu tenho um entendimento mais profundo da arquitetura de software e princípios de abertura e fechamento. No passado, eu pensava que "codificação" e "arquitetura" estavam realmente fazendo a mesma coisa, mas desta vez eu tenho um entendimento mais profundo.
Atualmente, existem muitos, muitos insetos leaa , mas isso não parece impedir que as pessoas necessitam recuperar o código útil para eles em leaa através do Github. Esta também é minha intenção original de escrever leaa , acima. 2019-09-17 17:01 @ guangxi hezhou
Do GIT Commit, podemos ver que esse log de desenvolvimento (log de desenvolvimento) só está agora escrito. O projeto foi originalmente chamado 1d1h, o que significa uma hora por dia. Quero reunir a experiência anterior de escrever front e traseiro no meu tempo livre e fazer um projeto de código aberto do blog -> CMS -> SOHP, incluindo API / Dashboard / Website / WeChat Weapp / React Native (iOS / Android). Por ser um monorepo, semelhante à interface / entrada, eles são compartilhados, por isso parece que é uma coisa muito conveniente construir uma plataforma completa.
Na verdade, eu originalmente queria escrever esse registro de desenvolvimento mais cedo, mas nos primeiros dias, passei muitos problemas que precisavam ser resolvidos e realmente não consegui encontrar tempo para escrever registros. Agora eu penso nisso, realmente não deveria ser assim. Afinal, se eu registrasse muitos problemas antes, era realmente uma riqueza invisível. Embora eu tenha conhecido novamente, definitivamente saberia como resolvê -los, mas não consegui compartilhá -los com os outros. Mas vou revisar os seguintes logs lentamente.
Deixe -me falar sobre minha compreensão do painel aqui. Eu acho que um painel mínimo disponível deve ser incluído.
Esses módulos podem basicamente ser usados como blogs depois de escrevê -los, especialmente as permissões de função. Se houver um requisito de negócios, é basicamente muito simples de desenvolver com base em tal minimização do painel. Eu processei permissões em projetos anteriores muitas vezes, mas desta vez é o GraphQL, que é um pouco diferente do repouso anterior, então ainda passei algum tempo para jogar.
Eu escrevi muito código com o Nest.js, mas não é confortável de considerar. O motivo da escolha é que sou atraído por todo o seu paradigma e pelo apoio do TypeScript que está armado para os dentes. O autor @kamilmysliwiec ainda é muito poderoso. Algumas das implementações de embalagem do Nest.js são muito requintadas. O mais importante também é combinado com várias tecnologias e implementou muitos cenários de negócios. Isso é realmente ótimo.
React + ANTD é uma seleção de tecnologia comum no dashboard . No entanto, desta vez, porque hooks são totalmente lançados, incluindo a Apollo, as mais recentes versões beta de ganchos, e a classe é quase impossível de ver em todo o projeto. No entanto, depois de usar ganchos em larga escala, o código parece realmente feio. Se a clareza do código da classe fosse marcada 10 pontos no passado, os ganchos poderiam marcar apenas 5 pontos. Obviamente, o mais óbvio é ganhar um FN de compartilhamento de código. Se fosse classe, seria bastante problemático compartilhar a classe FN.
Não há escolha para www , só pode ser o próximo.js. Na verdade, eu desenvolvi um conjunto relativamente completo de React-SSR antes, mas para se adaptar à onda, e o @guillermo Deus está empurrando-o e soprando todos os dias, não pude deixar de comprar a seguir. Quando comecei a escrever www, por acaso acompanhava o lançamento do Next.JS V9, que é uma nova versão do navio que foi reescrita no TS desde o Core. Eu pensei que seria muito suave de usar, mas não esperava que fosse um truque ...
Afinal, o ANTD precisa ser integrado, o que significa que o código de páginas do próprio cliente precisa usar o CSSModule para menos, o ANTD não o usa e o servidor o jogará quando vir menos. Portanto, o plug-in oficial sem apenas 60% e o suporte restante de 40% é insuficiente. Originalmente, como Next.js e CRA, é como envolver o WebPack. Eu realmente não quero que você toque no câncer de front-end, e é um aborrecimento de frango fritar.
No entanto, gostaria de dizer que uma estrutura lhe dará várias vezes a conveniência no estágio inicial do projeto, por isso fará com que você várias vezes o problema no estágio posterior do projeto. Isso é verdade para CRA, Expo e Next.js não é exceção, ambos são caixas pretas. Então eu tenho que escrever um 100% com plugina em duas horas, ou o projeto ficará preso. Olhei através do Github e queria ver se havia uma solução, mas, infelizmente, não consegui encontrar o código relevante logo após o V9. Parece que eu só posso foder eu mesmo. Embora eu esteja muito familiarizado com o Webpack, o Next.js adicionou uma fina camada de caixa preta ao Webpack, escrever com o Plugin tem uma espécie de submerso em um mar desconhecido de contexto. É uma jogada muito frustrante, mas felizmente, finalmente foi feita em meia hora. Mencionei um problema com minha própria resolução e a fechei rapidamente quando não foi descoberta. Espero ajudar os caras que encontram o mesmo problema ao procurar problemas. Afinal, ainda há muitas pessoas que precisam do próximo.js + Antd sem sem querer, especialmente na China.
O tempo voa tão rápido, e meio mês se passou em um piscar de olhos. Não escrevi nada de novo no Leaa recentemente. O foco está na integração do OSS do Alibaba Cloud. Deseja implementar essa função:
O processo é bastante difícil, envolvendo algumas interações entre o local e o OSS. Além disso, por causa do OSS diretamente, todas as solicitações não são passadas pela API e se tornam retornos de chamada à espera de OSS. É necessário garantir que o DB não possa ser movido sem concluir nenhuma etapa, apenas alcançando a idempotência. De fato, se o upload for feito através da API, a API será processada uniformemente e depois colocada no OSS, será simples e muito grande. Preocupo -me principalmente que, ao realizar determinadas atividades, se o upload de arquivos estiver envolvido, a simultaneidade será muito grande e o servidor não poderá se recuperar. Portanto, é necessário bloquear o OSS primeiro.
Basicamente, www, API e painel chegaram ao fim. Comece miniprogram amanhã.
Quando resolvi o pacote pela primeira vez, descobri que o React foi atualizado para 16.9.0. Consolei o próximo monte de Warning: componentWillMount... Eu olhei para o React Changelog e descobri que era realmente uma grande mudança. Alguns lifecycle serão descartados na versão futura. Como o Leaa-Dashboard depende do antd , é melhor aguardar a liberação antd para eliminar esses avisos antes de atualizar. Atualmente, o React está bloqueado em "react": "16.8.6", "react-dom": "16.8.6" .
Fiz uma faixa de pilha Leaa e a coloquei no topo do ReadMe. A técnica usada para descrever imagens é muito melhor que o texto. Mencione também o nome Leaa . Este é realmente o nome de uma atriz francesa Léa Seydoux que eu gosto. Para evitar a alta taxa de duplicação, adicionei um extra por trás de Lea. No entanto, o ponto mais comum LEAA no Google é Law Enforcement Assistance Administration um órgão judicial dos EUA (risos).
Acabei de usar fiapos para encontrar vários erros no projeto. O mais interessante são packages/leaa-dashboard/src/pages/Permission/PermissionList/PermissionList.tsx L159 aqui, printWidth do projeto .prettierrc e max-len de .eslintrc.js são definidos como 120 , mas mais o que não relata um erro e não se forma automaticamente, mas também se formou.
Eu tive que adicionar eslint-disable-next-line max-len . Parece muito provável que um deles tenha usado > e o outro seja >= . No entanto, depois de modificar as propriedades de ambos, descobri que esse não é o problema. Esqueça, adicione o max-len primeiro. Atualmente, existe apenas um lugar que é apenas. Se não houver amostras suficientes, não lidarei com isso. Vou lidar com esse problema no futuro.
Embora eu preste atenção ao código de estilo, usarei o IDE para escrever Marco com keymap e aplicar regras prettier e eslint para formatar. Mas depois do público do projeto, pode haver colaboradores chegando (não, não HHHH), e acho que seria melhor conectar o estilo de código no git commit .
Geralmente, um husky é suficiente para o projeto, mas existem muitos arquivos Monorepo. Toda vez que git commit todos os pacotes, todos os arquivos serão inevitavelmente eslint , por isso é necessário cooperar com lint-staged para minimizar o processamento de ESLint e apenas permitir que os arquivos no estágio git executem ESLint desta vez.
No entanto, parece que o funcionário não deu muitas sugestões e exemplos para Monorepo. Depois de explorá-lo, achei que não era problemático, mas não era o mesmo que não monorepo. A fim de se dissipar de pacakge.json , também escrevi em um arquivo de configuração, aproximadamente como este:
module . exports = {
'packages/**/*.ts?(x)' : [ 'prettier --write' , 'eslint' , 'git add' ] ,
'packages/**/*.(css|less)' : [ 'prettier --write' , 'stylelint' , 'git add' ] ,
} ;Eu tentei e foi bastante rápido. Pode levar algum tempo para saber o efeito se você tiver melhores práticas recomendadas.
Eu tentei Taro por cerca de uma noite e não parecia muito ideal. Por que? Primeiro de tudo, o que eu preciso é React à estrutura小程序, e o que eu quero é ONLY applet. Quanto ao motivo pelo qual é apenas, explicarei em detalhes posteriormente.
Após o uso inicial, Taro parece que é um mestre. Ele tem uma responsabilidade pesada e precisa ser compatível com muitos ambientes类小程序, como支付宝小程序,今日头条小程序, etc ... e também precisa considerar compatível com o mecanismo de yoga CSS do RN . A equipe ainda é muito difícil. Eu ainda admiro muito. Devo dar um polegares aqui em cima. Em seguida, falarei sobre meus sentimentos gerais depois de algumas horas.
Perfeito! O mesmo vale para o desenvolvimento normal da Web, não há nada a dizer. Suporta a GRH e suporta o módulo CSS. Não se importe com webpack , você pode executá -lo apenas chegando. No entanto, uma coisa que vale a pena notar é que, se você quiser ser compatível com RN , não pode usar taro-ui ou outras libs de UI de terceiros. Você só pode usar o @tarojs/component embutido. Essa restrição parece estar bastante presa. Espero que taro-ui apoie RN o mais rápido possível.
Também é muito perfeito, e não há coisa ruim. Depois de correr, abra as ferramentas oficiais de depuração do WeChat e vá para a estrada sem problemas. A única armadilha é que não é amigável monorepo o apoio, é claro que isso é compreensível. Existem poucas pessoas usando monorepo na China. Se você o usar, deve personalizá -lo como uma atitude de "você tem a capacidade de resolver qualquer problema no monorepo ". Eu corro sob monorepo e encontrei esse problema:
can't find module : ../../../node_modules/@tarojs/taro-weapp/
Há também algumas pessoas na comunidade que estão falando sobre questões, como o apoio da Monorepo. Minha abordagem é semelhante à dele. Eles usam o nohoist of Yarn Wokesspaces para fazê -lo. No entanto, minha solução é manter apenas módulos relacionados ao Taro em sub -pacote. Para outras coisas, é melhor melhorar e maximizar os módulos de compartilhamento:
{
"nohoist" : [ " **/@tarojs/** " ]
} Eu o executei depois de ver dev:rn em package.json . O resultado foi bom. Vi o aviso de que a compilação foi bem -sucedida, mas não houve seguidores ... então fui aos documentos oficiais e achei um pouco complicado. Então, qual é a diferença entre isso e tentando fazer um conjunto de desenvolvimento de RN nativo sozinho? E se você confia no Taro , RN está bloqueada em 0.55.4 , meu Deus! Isso está longe do número oficial da versão de 0.60.x Você deve saber que todas as iterações de versão do RN são um salto qualitativo. Se você usar 0.60.x , também poderá ganhar o Hermes no Android e a eficiência será bastante aprimorada. Outra coisa que me deixa me preocupar é que o uso RN@Taro significa que você só pode usar o UI lib @tarojs/component , o que significa que você precisa desistir de NativeBase e Shoutem que são LIBs da UI de qualidade relativamente de alta qualidade no RN .
Bem ... para resumir, se você não está pensando em economizar custos e tempo e desejar一套代码多处运行, é recomendável desistir RN@Taro . Se você quiser falar sobre o melhor horário de entrada, acho que é pelo menos taro-ui que suporta RN . Obviamente, esse custo é muito alto e é muito possível que o funcionário nunca forneça suporte.
OK, vamos voltar ao tópico. Minha intenção original de usar Taro era usar apenas para mini programas no início, então acho que "tudo está bem" para a situação atual. leaa-app ainda é RN ou expo , afinal, o truque é basicamente feito nos projetos anteriores (risos).
É tão triste gravar sua experiência de usar Taro durante o dia hoje ...
Primeiro de tudo, o mais doloroso é que @apollo/react-hooks e react-apollo não são suportados! Em outras palavras, nenhum pacote oficial da Apollo pode ser usado! Você não pode useQuery e nem mesmo permitir <Query> . Se você o usar, você relatará ganchos a você Invariant Violation: Invalid hook call. O resultado é que você pode escrever o exportar apolloClient apolloClient.query() diretamente. Esta é realmente uma noite antes da libertação!
Originalmente, pensei que era conveniente e fiquei muito feliz em executar no modo H5 por depuração e apolloClient Eu não esperava ...小程序Mode apareceu e disse que fetch is not found globally and no fetcher passed, to fix pass.... Eu verifiquei as informações e disse que estava "em uma certa atualização do WeChat Mini Program, a busca global foi removida" ... Felizmente, imediatamente encontrei o Lib Wx-apol-fetch escrito por meu predecessor. Existem apenas algumas linhas de toda a biblioteca:
return new Promise(resolve =>
wx.request({
...
complete: ({ data, statusCode, errMsg }) => resolve({...})
}))
Em seguida, substitua -o no HttpLink e torne -se fetch: wxApolloFetcher . Eu nunca esperava que o WeChat fizesse uma atualização tão penhasco, que é realmente uma operação sensata.
Em seguida, é a questão do alias do caminho. As questões oficiais que este post foram discutidas mais intensamente. Eu tentei depois de ler, mas ainda não tinha solução. A solução aqui é que a solução é que a solução no lado小程序não é, e H5 é bom. Afinal, eu sou monorepo , e ficaria muito embaraçoso se eu não pudesse compartilhar o código no pacote @leaa/common . Ok, eu não vou mais usar, leve -o.
Eu pensei que já era um tormento depois de experimentar o desenvolvimento RN , mas desta vez ... oh, não vamos mais falar sobre isso, culpo a tecnologia que usei é muito nova (Bang).
? Lendo mais ...
