leaa
v3.9.0
Leaa는 Nest.js, Next.js 및 Ant Design으로 제작 된 Monorepo CMS (컨텐츠 관리 시스템)입니다.
packages 에서 각 하위 디렉토리의 README.md 봅니다. 먼저 원사 작업 공간을 봐야 할 수도 있습니다.
토 도스
원래 요약은 기사의 끝에 작성되어야하지만, 적어도 개발 로그에 대한 잔소리를 읽을 필요는 없습니다.
나는 전체 스택 프로젝트를 직접 작성하여 5- 엔드에 연결하려고 노력했다고 생각했습니다. 나는 시간이 없었고 계속 끌고있다. 내가 그것을 썼을 때, 나는 반년이 걸릴 것이라고 생각했지만, 그것을하는 데 1 개월 반만 걸릴 것으로 기대하지 않았습니다. 그리고 나는 또한 많은 곳에서 모범 사례를 찾았고 전반적으로 나는 매우 만족했습니다.
프로젝트의 원래 의도는 React 또는 주로 JSX 구문을 사용하여 미니 프로그램 또는 앱 작성과 같은 더 많은 작업을 수행하는 것이 었으며 기존 기술 프레임 워크도 내 아이디어를 뒷받침하는 것입니다. 나는 이전 경험과 GraphQL 과 같은 새로운 기술로 길을 가기 시작했습니다.
api , dashboard 및 www 에는 많은 문제가 없지만 miniprogram (小程序，下文简称mp) 및 app 표준 web 语言아니기 때문에 운이 좋지 않습니다. 그들은 HTML 富文本렌더링과 같습니다.이 텍스트 렌더링은 자연스럽게 web 지원합니다. 그들에게는 mp 와 app 에는 그러한 a 없기 때문에 a 와 같이 스스로 fuckingSelf 분석해야합니다. 사용자가 클릭하는 a 전적으로 개발자에게 달려 있으며, 이는 이전에 개발 한 " web 응용 프로그램"과 완전히 다릅니다. 전에 App 개발에 대한 경험이 있었다면, 그 거짓말이 적을 것이라고 생각합니다.
함정에 대해 말하면, 나는 구덩이 파기 기술이 정말 놀랍습니다. RN 구덩이가 많고 잘 알려진 것으로 여겨지기 때문에 인기가 있습니다. 좋아, 나는 그것을 선택했다. 당신은 monorepo 의 함정을 알지 못할 수도 있지만 실제로 사람들을 죽게 만들 수 있습니다. 좋아요, 선택하겠습니다. TS 로 RN 개발하는 데는 별다른 함정이 없지만 많은 것도 있습니다. 좋아, 나도 그것을 선택했다. 그런 다음이 RN + monorepo + TS Super Big Pit (Cry)를 선택했지만 나중에 조금씩 누워서 인내심에 감탄합니다 (손을 뻗어).
왜 monorepo 선택하여 개발해야합니까? 나의 원래 의도는 5 쪽에서 TS의 interface 와 일부 재사용 가능한 구성을 공유하는 것이었지만 나중에 mp 와 app 썼을 때 특수 메커니즘 중 일부 때문에 공유 할 수 없다는 것을 알았습니다. 실제로 mp 와 app monorepo 에서 완전히 분리되어 있습니다. 나중에 코드를 리팩토링하면 이러한 "非标准web 应用"을 저장하기가 어렵 기 때문에 리포지토리에 별도로 배치합니다. node_modules 에는 공유 할 수없는 것이 있으며 각각은 매우 큽니다. 핵심은 아니며, 핵심은 yarn install 때마다 매우 가득 차 있으며 CPU가 컴퓨터가 이륙하려고 할 정도로 급증한다는 것입니다. 원래, 나는 yarn workspaces 사용하여 lerna 없이 mono 해결하는 경향이 있지만,이 문제로 인해 lerna 얻으려고 노력했지만 문제는 개선되지 않은 것처럼 보였으므로 포기해야했습니다. 이번에는 monorepo 에 대한 경험을 주었고, 이는 육체의 고통으로 간주 될 수 있으며 mono 와 multi 선택하는 방법을 알려줍니다.
자, 내가 지금 5면 난이도 순위를 쓰라는 요청을 받았다면,이 mp > app > www > api > dashboard 와 같을 것 같습니다.
mp 가장 어려운 부분으로 표시되는 이유는 무엇입니까? mp 에는 많은 개인 상품이있을뿐만 아니라 DevTools에도 놀랍게도 많은 버그가 있기 때문입니다. 때로는 버그를 수리하지만 오랫동안 잘 작동하지 않지만 DevTools를 다시 시작하기에 충분합니다. 이것은 정말로 나를 혈액으로 구토하게 만듭니다. 그리고 Taro 사용했기 때문에 custom-tab-bar 와 같은 많은 새로운 기능이이를 따라 가지 못했고 문서가 없었습니다. 나는 혼자서 그것을 알아 냈지만 많은 시간이 걸렸다. 물론 Taro 사용하고 custom-tab-bar 요구 사항이있는 경우 leaa 기존 GitHub 솔루션에 대한 최적의 솔루션 일 수 있습니다.
또한, 나는 www ( Next.js v9)에 대해 할 말이 많았지 만 시간이 지남에 따라 이러한 말은 점차 사라집니다. 이런 종류의 "말하고 싶지 않다"는 "어렵지 않은 사람들에게는 어렵지 않다"는 것은 아니지만, Next.js 함정이 너무 많기 때문에 하나의 구덩이를 해결하는 것은 불가피하게 다른 함정으로 이어질 것입니다. 또한, 당신이 참조 할 모범 사례는 없습니다. 그것들은 모두 간단한 example 입니다. 복잡한 기능을 수행하려면 전면 및 뒷면 모두에서 처리 해야하는 이러한 종류의 "SSR"은 사람들이 "말할 수없는 숨겨진"것처럼 느끼게합니다. 8to9와 같은 Next.js 버전의 모든 변경 사항에 따라 절벽과 같은 많은 변경 사항이 있습니다. 방법은 없습니다. Zeit의 문화는 다음과 같습니다. "모든 불행은 충분히 강하지 않은 것으로부터 온다"고 자신을 위로 할 수 있습니다.
monorepo 의 경우 프로젝트에 "유사한 파일 이름"이 많은 파일이 많이 있습니다. 여러 번 파일에 압도 당하고 파일을 찾을 때 쉽게 방해 할 수 있다고 생각합니다. Components/Filter/index.tsx 사용하여 cmd +를 찾으려면 Components/Filter/Filter.tsx 사용하여 파일의 이름을 지정하기 위해 포기하더라도. p 디렉토리 대신 파일 자체를 빠르게 찾을 수 있지만이 "파일 지옥"느낌을 제거하기는 어렵습니다.
원래 요약을 쓸 수 있다면 불만을 제기해서는 안된다고 말했지만 이제는 여전히 몇 가지 불만이있는 것 같습니다. Docker 에서 Api , UI/UX 에 이르기까지 leaa 작성하는 과정은 실제로 많은 것을 가르쳐 주었으며 소프트웨어 아키텍처와 개방 및 폐쇄 원칙에 대해 더 깊이 이해하고 있습니다. 과거에는 "코딩"과 "아키텍처"가 실제로 같은 일을하고 있다고 생각했지만 이번에는 더 깊은 이해가 있습니다.
현재 leaa 많은 버그가 있지만 필요한 사람들이 Github를 통해 leaa 에서 유용한 코드를 검색하는 것을 막는 것은 아닙니다. 이것은 또한 위의 leaa 작성하려는 원래 의도입니다. 2019-09-17 17:01 @ Guangxi Hezhou
GIT Commit 에서이 개발자 로그 (개발 로그)가 이제 만 쓰여진다는 것을 알 수 있습니다. 이 프로젝트는 원래 1D1H라고 불렀으며 이는 하루에 1 시간을 의미합니다. 여가 시간에 전면 및 백엔드를 작성한 이전의 경험을 수집하고 API / Dashboard / Website / Wechat Weapp / React Native (iOS / Android)를 포함하여 블로그 -> CMS-> SOHP의 오픈 소스 프로젝트를 수행하고 싶습니다. 인터페이스 / 입력과 유사한 모노레 포이기 때문에 공유되므로 전체 플랫폼을 구축하는 것이 매우 편리한 것으로 느껴집니다.
사실, 나는 원래이 개발 로그를 일찍 작성하고 싶었지만 초기에는 해결해야 할 많은 문제를 썼으며 실제로 기록을 작성할 시간을 찾을 수 없었습니다. 이제 나는 그것에 대해 생각합니다. 정말 이렇게되어서는 안됩니다. 결국, 내가 전에 많은 문제를 기록했다면, 그것은 실제로 보이지 않는 부였습니다. 다시 만났지만, 나는 그것들을 해결하는 방법을 확실히 알았지 만 다른 사람들과 공유 할 수는 없었습니다. 그러나 다음 로그를 천천히 검토하겠습니다.
대시 보드에 대한 이해에 대해 이야기하겠습니다. 사용 가능한 최소 대시 보드가 포함되어야한다고 생각합니다.
이 모듈은 기본적으로 블로그를 작성한 후 블로그, 특히 역할 권한을 사용할 수 있습니다. 비즈니스 요구 사항이있는 경우 기본적으로 대시 보드 최소화를 기반으로 개발하기가 매우 간단합니다. 이전 프로젝트에서 여러 번 권한을 처리했지만 이번에는 GraphQL이므로 이전의 편안함과 약간 다르기 때문에 여전히 던지는 데 시간을 보냈습니다.
Nest.js와 함께 많은 코드를 작성했지만 고려하기에 편안하지 않습니다. 선택의 이유는 내가 그의 전체 패러다임과 치아로 무장 한 Typescript의 지원에 매료 되었기 때문입니다. 저자 @kamilmysliwiec는 여전히 매우 강력합니다. Nest.js의 포장 구현 중 일부는 매우 절묘합니다. 가장 중요한 것은 다양한 기술과 결합되며 많은 비즈니스 시나리오를 구현했습니다. 이것은 정말 훌륭합니다.
React + Antd는 dashboard 에서 일반적인 기술 선택입니다. 그러나 이번에는 Apollo를 포함하여 hooks 완전히 출시 되었기 때문에 최신 후크 베타 버전 및 클래스는 전체 프로젝트에서 거의 불가능합니다. 그러나 대규모로 후크를 사용한 후 코드는 정말 추악 해 보입니다. 클래스 코드 선명도가 과거에 10 점을 얻은 경우 Hooks는 5 점 만 득점 할 수있었습니다. 물론 가장 분명한 것은 FN을 공유하는 코드를 얻는 것입니다. 수업이라면 클래스 FN을 공유하는 것은 매우 번거 롭습니다.
www 부분에는 선택의 여지가 없으며 다음에만 가능합니다. 사실, 나는 이전에 비교적 완전한 반응 SSR 세트를 개발했지만, 파도에 적응하기 위해 @guillermo 신은 매일 그것을 밀고 날려 버리고 있으시면 다음 번에 구입할 수는 없었습니다. www를 작성하기 시작했을 때, 나는 Core 이후 TS에서 다시 작성된 새로운 버전의 배인 Next.js V9의 출시를 따라 잡았습니다. 사용하는 것이 매우 매끄 럽다고 생각했지만 트릭이 될 것으로 기대하지 않았습니다 ...
결국 ANTD를 통합해야하므로 클라이언트의 자체 페이지 코드가 CSSModule을 사용해야하며 ANTD는 사용하지 않으며 덜 볼 때 서버가 던질 수 있습니다. 따라서 공무원이없는 플러그인은 최대 60% 만 관리 할 수 있으며 나머지 40% 지원은 불충분합니다. 원래 Next.js 및 CRA와 마찬가지로 웹 팩을 포장하는 것과 같습니다. 나는 당신이 프론트 엔드 암을 만지기를 원하지 않으며, 볶음 치킨의 번거 로움입니다.
그러나 프레임 워크가 프로젝트 초기 단계에서 편의를 여러 번 제공 할 것이므로 프로젝트 후반 단계에서 여러 번 문제를 일으킬 것입니다. 이것은 CRA, Expo 및 Next.js도 예외는 아니며, 둘 다 블랙 박스입니다. 그런 다음 2 시간 안에 플러그 인과 함께 100%를 써야합니다. 그렇지 않으면 프로젝트가 갇히게됩니다. 나는 Github를보고 해결책이 있는지보고 싶었지만 불행히도 V9 직후 관련 코드를 찾을 수 없었습니다. 내가 나 자신 만 빌어 먹을 수있는 것 같다. Webpack에 매우 익숙하지만 Next.js는 Webpack에 얇은 블랙 박스 레이어를 추가했으며, Withplugin을 쓰는 것은 알려지지 않은 상황에 잠긴 일종의 침수가 있습니다. 그것은 매우 실망스러운 움직임이지만 다행히도 마침내 30 분 안에 이루어졌습니다. 나는 내 자신의 해결책에 대한 문제를 언급하고 발견되지 않았을 때 신속하게 폐쇄했습니다. 문제를 검색 할 때 같은 문제를 겪는 사람들을 도와주고 싶습니다. 결국, 특히 중국에서는 다음에 다음에 필요한 많은 사람들이 있습니다.
시간이 너무 빨리 날아가고 반세기가 눈을 깜박이게되었습니다. 최근에 Leaa에 새로운 글을 쓰지 않았습니다. Alibaba Cloud Oss의 통합에 중점을 둡니다. 이러한 기능을 구현하려고합니다.
이 과정은 지역과 OSS 간의 상호 작용을 포함하여 매우 어렵습니다. 또한 OSS로 직접적으로 모든 요청은 API를 통과하지 않고 OSS를 기다리는 콜백이됩니다. 단계를 완료하지 않고는 DB를 이동할 수 없도록해야합니다. 실제로, 업로드가 API를 통해 수행되면 API를 균일하게 처리 한 다음 OSS에 넣으면 간단하고 매우 커집니다. 주로 특정 활동을 할 때 파일 업로드가 관련되면 동시성이 매우 커지고 서버가 복구 할 수 없습니다. 따라서 먼저 OSS를 차단해야합니다.
기본적으로 www, API 및 대시 보드가 끝났습니다. 내일 miniprogram 시작하십시오.
패키지를 처음 분류했을 때 React가 16.9.0으로 업그레이드 된 것을 발견했습니다. 나는 다음의 비슷한 Warning: componentWillMount... 나는 React ChangeLog를보고 그것이 실제로 큰 변화라는 것을 발견했다. 향후 버전에서는 몇 가지 lifecycle 버릴 것입니다. Leaa-Dashboard는 antd 에 의존하기 때문에 antd 릴리스가 업그레이드하기 전에 이러한 경고를 제거하기 위해 기다리는 것이 좋습니다. 현재 React는 "react": "16.8.6", "react-dom": "16.8.6" 에 잠겨 있습니다.
나는 Leaa Stack 배너를 만들어 Readme 상단에 올려 놓았습니다. 그림을 설명하는 데 사용되는 기술은 텍스트보다 훨씬 낫습니다. 또한 Leaa 라는 이름을 언급하십시오. 이것은 실제로 내가 좋아하는 프랑스 여배우 Léa Seydoux의 이름입니다. 높은 복제 속도를 피하기 위해 LEA 뒤에 추가 A를 추가했습니다. 그러나 Google에서 LEAA 가장 일반적인 요점은 미국 사법 기관인 Law Enforcement Assistance Administration (Laughs)입니다.
방금가 Lint를 사용하여 프로젝트에서 몇 가지 오류를 찾았습니다. 더 흥미로운 점은 packages/leaa-dashboard/src/pages/Permission/PermissionList/PermissionList.tsx L159 여기 프로젝트의 printWidth .prettierrc 및 max-len 의 .eslintrc.js 는 120 으로 설정되어 있지만 Prettier는 오류를보고하지 않지만 Eslint는 120 이상이라고 말했습니다.
나는 eslint-disable-next-line max-len 추가해야했다. 그들 중 하나 > 사용되었고 다른 하나는 >= 입니다. 그러나 두 가지의 특성을 수정 한 후 이것이 문제가되지 않는다는 것을 알았습니다. 잊어 버리세요. 먼저 최대임을 추가하십시오. 현재는 단 하나의 장소 만 있습니다. 표본이 충분하지 않으면 그것을 다루지 않을 것입니다. 앞으로이 문제를 다룰 것입니다.
스타일 코드에주의를 기울이지 만 IDE를 사용하여 Keymap으로 Marco를 작성하고 prettier eslint 규칙을 포맷 할 것입니다. 그러나 프로젝트가 공개 된 후에는 기고자들이 들어올 수 있으며 (No, HHHH), git commit 에서 코드 스타일을 연결하는 것이 더 나을 것이라고 생각합니다.
일반적으로 husky 프로젝트에 충분하지만 Monorepo 파일이 너무 많습니다. git commit 때마다 모든 파일이 eslint 필연적으로 붙어있게되므로 lint-staged 와 협력하여 Eslint 처리를 최소화하고 이번에는 Git Stage의 파일 만 실행하도록해야합니다.
그러나 공무원은 Monorepo에 대한 많은 제안과 사례를 제공하지 않은 것 같습니다. 그것을 탐색 한 후, 나는 그것이 번거롭지 않다는 것을 알았지 만, 그것은 비 모노포와 거의 같지 않았다. pacakge.json 에서 분리하기 위해, 나는 이것을 대략적으로 다음과 같은 구성 파일로 썼습니다.
module . exports = {
'packages/**/*.ts?(x)' : [ 'prettier --write' , 'eslint' , 'git add' ] ,
'packages/**/*.(css|less)' : [ 'prettier --write' , 'stylelint' , 'git add' ] ,
} ;나는 그것을 시도했고 그것은 꽤 빨랐다. 더 나은 모범 사례가 있다면 효과를 아는 데 시간이 걸릴 수 있습니다.
나는 어느 날 밤에 Taro 시도했지만 그다지 이상적이지 않았습니다. 왜? 우선, 내가 필요한 것은小程序프레임 워크에 대한 React 이며, 내가 원하는 것은 ONLY 애플릿입니다. 그것이 왜 단지 단지, 나는 나중에 자세히 설명 할 것입니다.
초기 사용 후 Taro 자신이 마스터 인 것처럼 느낍니다. 그는 책임이 크며支付宝小程序,今日头条小程序RN yoga 너무 많은类小程序환경과 호환되어야합니다. 팀은 여전히 매우 어렵습니다. 나는 여전히 그것을 매우 존경한다. 나는 여기에 엄지 손가락을 주어야한다. 다음으로 몇 시간 후에 저의 일반적인 감정에 대해 이야기하겠습니다.
완벽한! 정상적인 웹 개발도 마찬가지입니다. 할 말이 없습니다. HRM을 지원하고 CSS 모듈을 지원합니다. webpack 에 신경 쓰지 마십시오. 그러나 주목할만한 가치는 RN 과 호환되기를 원한다면 taro-ui 또는 기타 타사 UI Libs를 사용할 수 없다는 것입니다. 내장 @tarojs/component 만 사용할 수 있습니다. 이 제한은 상당히 붙어있는 것 같습니다. taro-ui 가능한 빨리 RN 지원하기를 바랍니다.
그것은 또한 매우 완벽하며 나쁜 것은 없습니다. 실행 후 공식 WeChat 디버그 도구를 열고 도로로 내려갑니다. 유일한 함정은 monorepo 지원에 친숙하지 않다는 것입니다. 물론 이것은 이해할 수 있습니다. 중국에서는 monorepo 사용하는 사람은 거의 없습니다. 당신이 그것을 사용한다면, 당신은 그것을 " monorepo 에서 문제를 해결할 수있는 능력이 있습니다"라는 태도로 사용자 정의해야합니다. 나는 monorepo 에서 달리고이 문제를 겪었다.
can't find module : ../../../node_modules/@tarojs/taro-weapp/
지역 사회에는 Monorepo 지원과 같은 문제에 대해 이야기하는 사람들도 있습니다. 내 접근 방식은 그와 비슷합니다. 그들은 원사 Wokesspaces의 Nohoist를 사용하여 그것을 수행합니다. 그러나 내 솔루션은 Taro 관련 모듈 만 하위 패키지에만 유지하는 것입니다. 다른 것들의 경우 공유 모듈을 개선하고 최대화하는 것이 좋습니다.
{
"nohoist" : [ " **/@tarojs/** " ]
} package.json 의 dev:rn 본 후에 실행했습니다. 결과가 좋았습니다. 나는 편집이 성공적이라는 프롬프트를 보았지만 다음은 없었습니다 ... 그런 다음 공식 문서에 가서 조금 복잡하다는 것을 알았습니다. 그렇다면 이것과 일련의 기본 RN 개발을 시도하는 것의 차이점은 무엇입니까? 그리고 당신이 Taro 에 의존한다면, RN 버전은 0.55.4 , 나의 선함으로 고정됩니다! 이것은 공식 버전 번호 0.60.x 와는 거리가 멀다. RN 의 모든 버전 반복은 질적 도약이라는 것을 알아야합니다. 0.60.x 사용하면 Android에서 헤르메스를 얻을 수 있으며 효율성이 크게 향상됩니다. RN@Taro 사용한다는 것은 UI lib @tarojs/component 만 사용할 수 있다는 것을 의미합니다. 즉, RN 에서 비교적 고품질 UI LIBS 인 NativeBase 와 Shoutem 포기해야한다는 것을 의미합니다.
글쎄요, 요약하면 비용과 시간을 절약하고一套代码多处运行경우 RN@Taro 포기하는 것이 좋습니다. 최고의 입학 시간에 대해 이야기하고 싶다면 RN 지원하는 것은 적어도 taro-ui 라고 생각합니다. 물론,이 비용은 너무 높아서 공무원이 결코 지원을 제공하지 않을 가능성이 매우 높습니다.
좋아, 주제로 돌아가 봅시다. Taro 사용하려는 원래 의도는 처음에는 미니 프로그램에만 사용하는 것이 었으므로 현재 상황에 대해 "모든 것이 괜찮다"고 생각합니다. leaa-app 은 여전히 RN 또는 expo 입니다. 결국 트릭은 기본적으로 과거 프로젝트에서 수행됩니다 (웃음).
오늘 하루 동안 Taro 사용 경험을 녹음하는 것은 너무 슬프다 ...
우선, 더 고통스러운 것은 @apollo/react-hooks and react-apollo 가 지원되지 않는다는 것입니다! 다시 말해, 공식 아폴로 패키지를 사용할 수 없습니다! 당신은 useQuery 수없고 <Query> 허용하지 않습니다. 당신이 그것을 사용하면, 당신은 당신에게 고리를보고하게됩니다 Invariant Violation: Invalid hook call. 결과적으로 내보내기 apolloClient apolloClient.query() 를 직접 쓸 수 있습니다. 이것은 실제로 해방 전 밤입니다!
나는 원래 그것이 편리하다고 생각했고, 디버깅과 apolloclient를 통해 H5 모드로 실행하는 것이 매우 기뻤습니다 apolloClient 나는小程序모드가 튀어 나오고 fetch is not found globally and no fetcher passed, to fix pass.... 전 세계적으로 찾을 수 없다고 말했다. 전체 라이브러리에는 몇 줄만 있습니다.
return new Promise(resolve =>
wx.request({
...
complete: ({ data, statusCode, errMsg }) => resolve({...})
}))
그런 다음 HttpLink 에서 교체하고 fetch: wxApolloFetcher 됩니다. 나는 WeChat이 절벽 스타일 업데이트를 할 것이라고 결코 기대하지 않았다.
다음은 PATH alias 문제입니다. 이 게시물이 공식적인 문제는 가장 강렬하게 논의되었습니다. 읽은 후 시도했지만 여전히 해결책이 없었습니다. 여기서 솔루션은 솔루션은小程序측의 솔루션이 아니며 H5 측이 양호하다는 것입니다. 이것은 ... 결국 monorepo 이며 @leaa/common 패키지에서 코드를 공유 할 수 없다면 매우 당황스러워 질 것입니다. 좋아, 더 이상 사용하지 않을거야.
나는 그것이 RN 개발을 경험 한 후 이미 고통이라고 생각했지만 이번에는 ... 아, 더 이상 그것에 대해 이야기하지 말자, 나는 내가 사용한 기술이 너무 새롭다는 것을 비난했다 (bang).
? 더 읽기 ...
