leaa
v3.9.0
Leaaは、Nest.js、Next.js、およびANTデザインで構築されたモノレポCMS（コンテンツ管理システム）です。
packages内の各サブディレクトリのREADME.md表示します。最初に糸のワークスペースを見る必要があるかもしれません。
トドス
もともと、要約は記事の最後に書かれている必要がありますが、私はそれを提案する必要があると感じています。少なくとも、開発ログについて私のしつこく読む必要はありません。
私は、自分でフルスタックプロジェクトを書くことで、5つのエンドに接続しようとすると思っていました。時間がなかったので、ドラッグし続けました。私がそれを書いたとき、私はそれが半年以上かかると思ったが、それをするのに1か月半かかるとは思わなかった。また、私は多くの場所でベストプラクティスを求めましたが、全体的には非常に満足していました。
プロジェクトの当初の意図は、Miniプログラムやアプリの作成など、より多くのことを行うためにReactまたは主にJSX構文を使用することでした。既存の技術的フレームワークも私のアイデアをサポートしています。私は以前の経験とGraphQLなどのいくつかの新しいテクノロジーとともに道を進み始めました。
api 、 dashboard 、 wwwで発生する問題は多くありませんが、 miniprogram (小程序，下文简称mp)とapp 、標準的なweb 语言ではないため、それほど幸運ではありません。それらは、 HTML 富文本レンダリングのようなもので、当然webサポートしています。彼らの上で、彼らはfuckingSelfとなり、 mpやappにはそのようなaがないため、 aなどの自分で解析される必要があります。ユーザーが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選択方法を教えてくれました。
OK、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は多くの落とし穴があるため、1つのピットを解決することは必然的に他のいくつかの落とし穴につながります。さらに、参照するベストプラクティスはありません。それらはすべて簡単なexampleです。複雑な機能を実行したい場合、フロントエンドとバックエンドの両方で処理する必要があるこの種の「SSR」は、人々が「言いようのない隠れ」のように感じます。 8to9のようなNext.jsバージョンのすべての変更により、崖のような多くの変更があります。 Zeitの文化はこのようなものであり、「すべての不幸は十分に強くないことから来る」だけで自分を慰めることができます。
monorepoの場合、プロジェクトに「同様のファイル名」を含む多くのファイルがあります。多くの場合、私はファイルに圧倒され、ファイルを探すときに簡単に干渉することができます。 Components/Filter/index.tsxを使用してあきらめてもComponents/Filter/Filter.tsxを使用してファイルに名前を付けてcmd +を見つける場合でも。 pディレクトリの代わりにファイル自体をすばやく見つけることができますが、この「ファイル地獄」の感覚を取り除くことも困難です。
もともとは、要約を書くことができれば文句を言うべきではないと言われていましたが、今ではまだいくつかの苦情があるようです。 DockerからApi 、 UI/UXまで、 leaaを書くプロセスはどこでも私に多くのことを教えてくれました。ソフトウェアアーキテクチャと開閉原則をより深く理解しています。過去には、「コーディング」と「アーキテクチャ」が実際に同じことをしていると思っていましたが、今回はより深い理解がありました。
現在、 leaa多くのバグがありますが、これはGitHubを介してleaaで有用なコードを必要とする人々を取得することを妨げるようには見えません。これは、上記のleaaを書くという私の当初の意図でもあります。 2019-09-17 17:01 @ Guangxi Hezhou
Git Commitから、このDEVログ（開発ログ）が現在書かれていることがわかります。このプロジェクトはもともと1D1Hと呼ばれていました。これは、1日1時間を意味します。暇なときにフロントエンドとバックエンドを書く以前の経験を収集し、ブログのオープンソースプロジェクト - > cms-> soHPを実行したいと思います。インターフェイス /エントリと同様にモノレポであるため、これらは共有されるため、フルプラットフォームを構築するのは非常に便利なものだと感じています。
実際、私はもともとこの開発ログを早めに書きたいと思っていましたが、初期の時代には、解決する必要がある多くの問題を費やしました。今、私はそれについて考えています、それは本当にこのようではないはずです。結局のところ、私が以前に多くの問題を記録した場合、それは実際には目に見えない富でした。私は再び会ったが、私はそれらを解決する方法を間違いなく知っているだろうが、私はそれらを他の人と共有することはできなかった。ただし、次のログをゆっくりと確認します。
ここでダッシュボードについての私の理解について話させてください。最小限のダッシュボードを含める必要があると思います。
これらのモジュールは、基本的にブログを作成した後、特に役割の許可としてブログとして使用できます。ビジネス要件がある場合、このようなダッシュボードの最小化に基づいて開発することは基本的に非常に簡単です。私は以前のプロジェクトの許可を何度も処理しましたが、今回は以前のRESTFULとはわずかに異なるGRAPHQLなので、まだ投げるのに時間を費やしました。
nest.jsで非常に多くのコードを書きましたが、考慮するのは快適ではありません。選択する理由は、私が彼のパラダイム全体と、歯に武装したタイプスクリプトのサポートに惹かれているからです。著者@kamilmysliwiecはまだ非常に強力です。 nest.jsのパッケージング実装の一部は非常に絶妙です。最も重要なことは、さまざまなテクノロジーと組み合わされており、多くのビジネスシナリオを実装しています。これは本当に素晴らしいです。
React + ANTDは、 dashboard上の一般的なテクノロジー選択です。ただし、今回は、最新のフックベータバージョンであるApolloを含むhooksが完全に発売されるため、プロジェクト全体でクラスを見ることはほとんど不可能です。ただし、大規模にフックを使用した後、コードは本当に醜く見えます。クラスコードの透明度が過去に10ポイントを獲得した場合、フックは5ポイントしか得点できませんでした。もちろん、最も明白なことは、FNを共有するコードを獲得することです。クラスの場合、クラスFNを共有するのは非常に厄介です。
wwwパートには選択肢がありません。次は次のことです。実際、私は以前に比較的完全な反応のセットを開発しましたが、波に適応するために、 @guillermoの神はそれを押し上げて毎日吹き飛ばしています。 wwwを書き始めたとき、私はたまたまnext.js v9のリリースに追いつきました。これは、Core以来TSで書き直された船の新しいバージョンです。使用するのは非常にスムーズだと思っていましたが、トリックになるとは思っていませんでした...
結局のところ、ANTDを統合する必要があります。つまり、クライアント自身のページコードはCSSmoduleを少なく使用する必要があり、ANTDはそれを使用しません。したがって、公式のプラグインは最大60％しか管理できず、残りの40％のサポートは不十分です。もともと、next.jsやCraのように、それはWebpackをラッピングするようなものです。フロントエンドがんに触れることを本当に望んでおらず、炒めた鶏肉の手間です。
ただし、フレームワークにより、プロジェクトの初期段階での利便性が数倍になるため、プロジェクトの後期段階で何度もトラブルが発生します。これは、CRA、Expo、およびNext.jsに当てはまります。また、どちらもブラックボックスです。その後、2時間でプラギンで100％を書く必要があります。そうしないと、プロジェクトが行き詰まります。 Githubを調べて、解決策があるかどうかを確認したかったのですが、残念ながら、V9の直後に関連するコードを見つけることができませんでした。私は自分自身しかできないようです。私はwebpackに非常に精通していますが、次のjsはブラックボックスの薄い層をWebpackに追加しました。それは非常にイライラする動きですが、幸いなことに、ついに30分で行われました。私は自分の決議に関する問題に言及し、発見されなかったときにすぐにそれを閉じました。問題を検索するときに同じ問題に遭遇した人たちを助けたいと思っています。結局のところ、特に中国では、next.js + antdが必要な人がまだたくさんいます。
時間は非常に速く、半月は瞬く間に過ぎ去りました。私は最近LEAに新しいものを書いていません。焦点は、Alibaba Cloud OSSの統合にあります。そのような関数を実装したい：
このプロセスは非常に困難であり、ローカルと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 Bannerを作成し、ReadMeの上に置きました。写真を説明するために使用される手法は、テキストよりもはるかに優れています。 Leaaという名前についても言及してください。これは実際、私が好きなフランスの女優レア・セイドゥーの名前です。重複率が高いことを避けるために、Leaの後ろに追加を追加しました。ただし、GoogleでのLEAA最も一般的な点はLaw Enforcement Assistance Administrationです（笑）。
Lintを使用して、プロジェクトにいくつかのエラーを見つけました。さらに興味深いのはpackages/leaa-dashboard/src/pages/Permission/PermissionList/PermissionList.tsx l159です。ここでは、プロジェクトのprintWidth .prettierrc and max-len of .eslintrc.jsは120に設定されていますが、エラーはエラーを報告しません。
eslint-disable-next-line max-lenを追加する必要がありました。それらの1つ>使用し、もう1つは>=使用している可能性が非常に高いと感じています。しかし、両方のプロパティを変更した後、これは問題ではないことがわかりました。それを忘れて、最初にmax-lenを追加してください。現在、1つの場所だけがあります。十分な標本がなければ、私はそれを扱いません。私は将来この問題に対処します。
スタイルコードに注意を払いますが、IDEを使用してキーマップを使用してMarcoを作成し、 prettierとeslintルールをフォーマットに適用します。しかし、プロジェクトの公開の後、貢献者がやってくるかもしれません（いいえ、HHHHなし）。GIT git commitでコードスタイルをプラグインする方が良いと思います。
通常、 huskyではプロジェクトに十分ですが、モノレポファイルは非常に多くあります。 git commitたびに、すべてのファイルがeslintになります。必然的に停止するため、ESLINT処理を最小限に抑えるためにlint-stagedと協力する必要があります。
ただし、当局者はモノレポにあまり多くの提案や例を与えていないようです。それを探索した後、私はそれが厄介ではないことを発見しましたが、それは非モノレポとそれほど同じではありませんでした。 pacakge.jsonから切り離すために、私はそれをこのような構成ファイルにも書きました。
module . exports = {
'packages/**/*.ts?(x)' : [ 'prettier --write' , 'eslint' , 'git add' ] ,
'packages/**/*.(css|less)' : [ 'prettier --write' , 'stylelint' , 'git add' ] ,
} ;私はそれを試してみました、そしてそれは非常に速かったです。より良いベストプラクティスがある場合、その効果を知るのに時間がかかるかもしれません。
私は約1泊しTaroたが、あまり理想的ではありませんでした。なぜ？まず第一に、私が必要とするのは、小程序フレームワークへのReactであり、私が望むのはONLYアプレットです。なぜそれだけなのか、後で詳しく説明します。
最初の使用後、 Taro彼がマスターのように感じます。彼は重い責任を負っており、支付宝小程序、今日头条小程序など、あまりにもRNの类小程序環境と互換性がある必要がありますyogaチームはまだ非常に困難です。私はまだそれをとても賞賛しています。ここで親指を立てなければなりません。次に、数時間後に私の一般的な感情について話します。
完璧！通常のWeb開発にも同じことが言えますが、何も言うことはありません。 HRMをサポートし、CSSモジュールをサポートします。 webpackを気にしないでください。登場するだけで実行できます。ただし、注目に値することの1つは、 RNと互換性がある場合は、 taro-uiまたは他のサードパーティUI Libsを使用できないということです。 bilding @tarojs/componentのみを使用できます。この制限は非常に詰まっているようです。 taro-uiできるだけ早くRNをサポートすることを願っています。
それはまた非常に完璧であり、悪いことはありません。実行後、公式のWeChatデバッグツールを開き、スムーズに道路に降ります。唯一の落とし穴は、 monorepoサポートに友好的ではないということです。もちろん、これは理解できます。中国でmonorepoを使用している人はほとんどいません。使用する場合は、「 monorepoで問題を解決する能力がある」という態度としてカスタマイズする必要があります。私はmonorepoの下で走り、この問題に遭遇しました。
can't find module : ../../../node_modules/@tarojs/taro-weapp/
また、コミュニティには、Monorepoサポートなど、問題について話している人もいます。私のアプローチは彼のアプローチに似ています。彼らはそれを行うために糸wokesspacesのノホイストを使用します。ただし、私の解決策は、サブパッケージの下にTaro関連のモジュールのみを維持することです。他のことについては、共有モジュールを改善して最大化することをお勧めします。
{
"nohoist" : [ " **/@tarojs/** " ]
}package.jsonでdev:rn見た後に実行しました。結果は良かった。コンピレーションが成功したというプロンプトを見ましたが、以下はありませんでした...その後、公式のドキュメントに行き、少し複雑であることがわかりました。それでは、これとネイティブRN開発のセットだけを実行しようとすることの違いは何ですか？ Taroに依存している場合、 RNバージョンは0.55.4でロックされています。これは、 0.60.xの公式バージョン番号からはほど遠いです。 RNのすべてのバージョンの反復が定性的な飛躍であることを知っておく必要があります。 0.60.x使用すると、Androidでエルメスを獲得することもでき、効率は大幅に改善されます。私が心配するもう1つのことは、 RN@Taroを使用することは、UI Lib @tarojs/componentのみを使用できることを意味することです。つまり、 RNで比較的高品質のUI LIBである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.その結果、export apolloClient apolloClient.query()を直接記述できます。これは本当に解放の前の夜です！
私はもともとそれが便利だと思っていたので、デバッグとアポロクライエントで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）を責めます。
？もっと読む...
