leaa
v3.9.0
LEAA adalah CMS Monorepo (Sistem Manajemen Konten) yang dibangun dengan Nest.js, Next.js, dan Desain Ant.
Lihat README.md dari setiap sub-direktori dalam packages . Anda mungkin perlu melihat ruang kerja benang terlebih dahulu.
Todos
Awalnya, ringkasan harus ditulis di akhir artikel, tetapi saya merasa harus diajukan, setidaknya saya tidak perlu membaca saya mengomel tentang log pengembangan.
Dulu saya berpikir bahwa saya akan mencoba terhubung ke 5-end dengan menulis proyek tumpukan penuh sendiri. Saya tidak punya waktu dan terus menyeretnya. Ketika saya menulisnya, saya pikir itu akan memakan waktu lebih dari setengah tahun, tetapi saya tidak berharap itu hanya membutuhkan satu setengah bulan untuk melakukannya. Dan saya juga mencari praktik terbaik di banyak tempat, dan secara keseluruhan saya cukup puas.
Tujuan asli dari proyek ini adalah menggunakan React atau terutama sintaks JSX untuk melakukan lebih banyak hal, seperti menulis program mini atau aplikasi, dan kerangka teknis yang ada juga mendukung ide saya. Saya mulai pergi ke jalan dengan pengalaman saya sebelumnya dan beberapa teknologi yang lebih baru seperti GraphQL .
Tidak banyak masalah yang dihadapi pada api , dashboard , dan www , tetapi miniprogram (小程序，下文简称mp) dan app tidak seberuntung itu karena mereka bukan web 语言standar. Mereka seperti rendering HTML 富文本, yang secara alami mendukung web . Pada mereka, mereka menjadi fuckingSelf dan perlu diuraikan sendiri, seperti a , karena tidak ada a seperti itu di mp dan app . Apa yang terjadi pada pengguna klik a sepenuhnya tergantung pada pengembang untuk memutuskan, yang sama sekali berbeda dari "aplikasi web " yang saya kembangkan sebelumnya. Jika saya memiliki pengalaman dalam pengembangan App sebelumnya, saya percaya akan ada lebih sedikit jebakan untuk berbohong.
Berbicara tentang jebakan, saya pikir keterampilan penggalian lubang saya sangat menakjubkan. RN populer karena memiliki banyak lubang dan diyakini terkenal. Oke, saya memilihnya. Anda mungkin tidak tahu jebakan monorepo , tetapi mereka memang bisa membuat orang mati. Oke, saya akan memilih. Tidak banyak jebakan dalam mengembangkan RN dengan TS , tetapi ada juga banyak. Oke, saya juga memilihnya. Lalu saya memilih Pit (CRY) RN + monorepo + TS ini, tetapi saya masih berbaring sedikit demi sedikit sesudahnya, dan saya sangat mengagumi kesabaran saya (menyebarkan tangan saya).
Mengapa Memilih monorepo Untuk Dikembangkan? Niat asli saya adalah untuk berbagi interface TS dan beberapa konfigurasi yang dapat digunakan kembali pada 5-sisi, tetapi kemudian ketika saya menulis mp dan app , saya menemukan bahwa karena beberapa mekanisme khusus mereka, saya tidak dapat membagikannya. Faktanya, mp dan app sepenuhnya terisolasi dari monorepo . Jika saya refactor kode nanti, saya akan meletakkan "非标准web 应用" ini secara terpisah dalam repo karena mereka benar-benar sulit untuk dilayani. node_modules juga memiliki satu yang tidak dapat dibagikan, dan masing -masing sangat besar. Ini bukan kuncinya, kuncinya adalah bahwa setiap kali yarn install , sangat penuh, dan CPU melonjak bahwa komputer akan lepas landas. Awalnya, saya cenderung menggunakan yarn workspaces untuk memecahkan mono tanpa lerna , tetapi karena masalah ini saya mencoba untuk naik ke lerna , tetapi masalahnya tampaknya tidak membaik, jadi saya harus menyerah. Kali ini saya benar -benar memberi saya pengalaman dengan monorepo , yang dapat dianggap sebagai rasa sakit dari daging, dan itu juga memberi tahu saya bagaimana memilih mono dan multi .
Oke, jika saya diminta untuk menulis peringkat kesulitan 5 sisi sekarang, saya pikir itu akan seperti mp > app > www > api > dashboard .
Mengapa mp terdaftar sebagai bagian tersulit? Karena mp tidak hanya memiliki banyak barang pribadi, tetapi juga Devtools juga secara mengejutkan memiliki banyak bug. Kadang -kadang saya memperbaiki bug tetapi tidak bekerja dengan baik untuk waktu yang lama, tetapi cukup untuk memulai kembali Devtools. Ini benar -benar membuatku muntah. Dan karena saya menggunakan Taro , banyak fitur baru seperti custom-tab-bar tidak mengikutinya dan tidak ada dokumentasi. Saya menemukannya sendiri, tetapi butuh banyak waktu. Tentu saja, jika Anda menggunakan Taro dan memiliki persyaratan custom-tab-bar , leaa mungkin menjadi solusi optimal untuk solusi GitHub yang ada saat ini.
Selain itu, saya banyak bicara tentang www ( Next.js v9), tetapi seiring berjalannya waktu, hal -hal ini untuk dikatakan secara bertahap menghilang. Jenis "tidak ingin mengatakan" semacam ini bukanlah "tidak sulit bagi mereka yang tidak sulit", tetapi karena Next.js memiliki terlalu banyak jebakan, memecahkan satu lubang pasti akan menyebabkan beberapa jebakan lainnya. Selain itu, tidak ada praktik terbaik untuk Anda rujuk. Mereka semua adalah example sederhana. Setelah Anda ingin melakukan beberapa fungsi yang kompleks, "SSR" semacam ini yang perlu diproses oleh ujung depan dan belakang membuat orang merasa seperti "tersembunyi yang tak terkatakan". Dengan setiap perubahan dalam versi Next.js seperti 8to9, akan ada banyak perubahan seperti tebing. Tidak mungkin, budaya Zeit seperti ini, dan Anda hanya bisa menghibur diri dengan "semua ketidakbahagiaan datang dari menjadi tidak cukup kuat."
Untuk monorepo , ada banyak file dengan "nama file serupa" dalam suatu proyek. Berkali -kali saya merasa seperti saya kewalahan oleh file dan dapat dengan mudah diganggu saat mencari file. Bahkan jika saya menyerah menggunakan Components/Filter/index.tsx untuk memberi nama file dengan Components/Filter/Filter.tsx untuk menemukan cmd +. p dapat dengan cepat menemukan file itu sendiri, bukan direktori, tetapi juga sulit untuk menghilangkan perasaan "file neraka" ini.
Awalnya dikatakan bahwa saya seharusnya tidak mengeluh jika saya bisa menulis ringkasan, tetapi sekarang tampaknya masih ada beberapa keluhan. Di mana saja, dari Docker ke Api ke UI/UX , proses penulisan leaa memang telah banyak mengajari saya, dan saya memiliki pemahaman yang lebih dalam tentang arsitektur perangkat lunak dan prinsip -prinsip pembukaan dan penutupan. Di masa lalu, saya berpikir bahwa "pengkodean" dan "arsitektur" sebenarnya melakukan hal yang sama, tetapi kali ini saya memiliki pemahaman yang lebih dalam.
Saat ini, ada banyak, banyak bug leaa , tetapi ini tampaknya tidak mencegah orang yang membutuhkan untuk mengambil kode yang berguna bagi mereka di leaa melalui GitHub. Ini juga niat asli saya untuk menulis leaa , di atas. 2019-09-17 17:01 @ Guangxi Hezhou
Dari Git Commit, kita dapat melihat bahwa log dev ini (log pengembangan) baru sekarang ditulis. Proyek ini awalnya disebut 1D1H, yang berarti satu jam sehari. Saya ingin mengumpulkan pengalaman sebelumnya menulis di depan dan belakang di waktu luang saya dan melakukan proyek open source blog -> CMS -> SOHP, termasuk API / Dasbor / Situs Web / WeChat Weapp / React Native (iOS / Android). Karena ini adalah monorepo, mirip dengan antarmuka / entri, ini dibagikan, jadi rasanya adalah hal yang sangat nyaman untuk membangun platform penuh.
Bahkan, saya awalnya ingin menulis log perkembangan ini sebelumnya, tetapi pada hari -hari awal, saya menghabiskan banyak masalah yang perlu diselesaikan, dan saya benar -benar tidak dapat menemukan waktu untuk menulis catatan. Sekarang saya memikirkannya, seharusnya tidak seperti ini. Lagi pula, jika saya mencatat banyak masalah sebelumnya, itu sebenarnya kekayaan yang tidak terlihat. Meskipun saya bertemu lagi, saya pasti akan tahu cara menyelesaikannya, tetapi saya tidak bisa membagikannya kepada orang lain. Tapi saya akan meninjau log berikut secara perlahan.
Izinkan saya berbicara tentang pemahaman saya tentang dasbor di sini. Saya pikir dasbor minimum yang tersedia harus disertakan.
Modul -modul ini pada dasarnya dapat digunakan sebagai blog setelah menulisnya, terutama izin peran. Jika ada persyaratan bisnis, pada dasarnya sangat sederhana untuk dikembangkan berdasarkan minimalisasi dasbor. Saya telah memproses izin dalam proyek -proyek sebelumnya berkali -kali, tetapi kali ini GraphQL, yang sedikit berbeda dari Restful sebelumnya, jadi saya masih menghabiskan waktu untuk melemparkan.
Saya telah menulis begitu banyak kode dengan Nest.js, tetapi tidak nyaman untuk dipertimbangkan. Alasan untuk memilih adalah bahwa saya tertarik dengan seluruh paradigma dan dukungan dari naskah yang dipersenjatai untuk gigi. Penulis @kamilmysliwiec masih sangat kuat. Beberapa implementasi pengemasan Nest.js sangat indah. Yang paling penting juga dikombinasikan dengan berbagai teknologi dan telah menerapkan banyak skenario bisnis. Ini sangat bagus.
React + ANTD adalah pilihan teknologi umum di dashboard . Namun, kali ini, karena hooks diluncurkan sepenuhnya, termasuk Apollo, versi beta Hooks terbaru, dan kelas hampir tidak mungkin dilihat di seluruh proyek. Namun, setelah menggunakan kait dalam skala besar, kode ini terlihat sangat jelek. Jika kejelasan kode kelas mendapat nilai 10 poin di masa lalu, Hooks hanya bisa mencetak 5 poin. Tentu saja, hal yang paling jelas adalah mendapatkan kode berbagi kode. Jika itu adalah kelas, akan sangat merepotkan untuk berbagi kelas FN.
Tidak ada pilihan untuk bagian www , itu hanya bisa menjadi berikutnya. Bahkan, saya telah mengembangkan serangkaian reaksi-SSR yang relatif lengkap sebelumnya, tetapi untuk beradaptasi dengan gelombang, dan dewa @guillermo mendorongnya dan meniupnya setiap hari, saya tidak bisa membantu tetapi membeli selanjutnya. Ketika saya mulai menulis www, saya kebetulan mengejar ketinggalan dengan rilis Next.js V9, yang merupakan versi baru dari kapal yang telah ditulis ulang di TS sejak Core. Saya pikir itu akan sangat lancar untuk digunakan, tetapi saya tidak berharap itu menjadi trik ...
Lagi pula, ANTD perlu diintegrasikan, yang berarti bahwa kode halaman klien sendiri perlu menggunakan CSSMODULE untuk lebih sedikit, ANTD tidak menggunakannya, dan server akan melemparkannya ketika Anda melihat lebih sedikit. Oleh karena itu, plug-in tanpa withless resmi hanya dapat mengelola hingga 60%, dan dukungan 40% sisanya tidak cukup. Awalnya, seperti Next.js dan CRA, ini seperti Wrapping Webpack. Saya benar-benar tidak ingin Anda menyentuh kanker front-end, dan itu merepotkan ayam tumis.
Namun, saya ingin mengatakan bahwa kerangka kerja akan memberi Anda beberapa kali kenyamanan pada tahap awal proyek, sehingga akan menyebabkan Anda beberapa kali masalah di tahap selanjutnya dari proyek. Ini berlaku untuk CRA, Expo, dan Next.js tidak terkecuali, keduanya adalah kotak hitam. Maka saya harus menulis 100% dengan plugin dalam dua jam, atau proyek akan macet. Saya melihat melalui GitHub dan ingin melihat apakah ada solusi, tetapi sayangnya, saya tidak dapat menemukan kode yang relevan setelah V9. Sepertinya aku hanya bisa meniduri diriku sendiri. Meskipun saya sangat akrab dengan Webpack, Next.js menambahkan lapisan tipis kotak hitam ke webpack, Writing Withplugin memiliki semacam terendam dalam lautan konteks yang tidak diketahui. Ini adalah langkah yang sangat membuat frustrasi, tapi untungnya, akhirnya dilakukan dalam setengah jam. Saya menyebutkan masalah dengan resolusi saya sendiri dan dengan cepat menutupnya ketika tidak ditemukan. Saya berharap dapat membantu orang -orang yang mengalami masalah yang sama saat mencari masalah. Lagi pula, masih ada banyak orang yang membutuhkan selanjutnya. JS + Antd tanpa tanpa batas, terutama di Cina.
Waktu berlalu begitu cepat, dan setengah bulan telah berlalu dalam sekejap mata. Saya belum menulis sesuatu yang baru untuk LEAA baru -baru ini. Fokusnya adalah pada integrasi Alibaba Cloud OSS. Ingin menerapkan fungsi seperti itu:
Prosesnya cukup sulit, melibatkan beberapa interaksi antara lokal dan OSS. Selain itu, karena OSS secara langsung, semua permintaan tidak melewati API dan menjadi panggilan balik menunggu OSS. Penting untuk memastikan bahwa DB tidak dapat dipindahkan tanpa menyelesaikan langkah apa pun, nyaris tidak mencapai idempotensi. Bahkan, jika mengunggah dilakukan melalui API, maka API diproses secara seragam dan kemudian dimasukkan ke OSS, itu akan sederhana dan sangat besar. Saya terutama khawatir bahwa ketika melakukan kegiatan tertentu, jika mengunggah file terlibat, konkurensi akan sangat besar dan server tidak akan dapat pulih. Jadi perlu untuk memblokir OSS terlebih dahulu.
Pada dasarnya www, API dan dasbor berakhir. Mulai miniprogram besok.
Ketika saya pertama kali memilah paket, saya menemukan bahwa React telah ditingkatkan menjadi 16.9.0. Saya menghibur sekelompok Warning: componentWillMount... Saya melihat react changelog dan menemukan bahwa itu memang perubahan besar. Beberapa lifecycle akan dibuang di versi mendatang. Karena leaa-dashboard tergantung pada antd , lebih baik menunggu rilis antd untuk menghilangkan peringatan ini sebelum meningkatkan. Saat ini bereaksi terkunci dalam "react": "16.8.6", "react-dom": "16.8.6" .
Saya membuat spanduk Stack LEAA dan meletakkannya di atas Readme. Teknik yang digunakan untuk menggambarkan gambar jauh lebih baik daripada teks. Sebutkan juga nama Leaa . Ini sebenarnya nama seorang aktris Prancis Léa Seydoux yang saya sukai. Untuk menghindari tingginya tingkat duplikasi, saya menambahkan ekstra A di belakang Lea. Namun, poin paling umum LEAA di Google adalah Law Enforcement Assistance Administration badan peradilan AS (tertawa).
Saya baru saja menggunakan serat untuk menemukan beberapa kesalahan dalam proyek. Yang lebih menarik adalah packages/leaa-dashboard/src/pages/Permission/PermissionList/PermissionList.tsx l159 di sini, printWidth proyek .prettierrc dan max-len dari .eslintrc.js diatur ke 120 , tetapi lebih dari itu tidak melaporkan kesalahan dan tidak format secara otomatis, tetapi esl itu diatur ke 120, tetapi lebih dari itu tidak melaporkan kesalahan dan tidak diformat secara otomatis, tetapi esl ini.
Saya harus menambahkan eslint-disable-next-line max-len . Sangat mungkin salah satu dari mereka digunakan > dan yang lainnya adalah >= . Namun, setelah saya memodifikasi sifat keduanya, saya menemukan bahwa ini bukan masalahnya. Lupakan, tambahkan max-len terlebih dahulu. Saat ini, hanya ada satu tempat yang hanya. Jika tidak ada spesimen yang cukup, saya tidak akan menghadapinya. Saya akan menangani masalah ini di masa depan.
Meskipun saya memperhatikan kode gaya, saya akan menggunakan IDE untuk menulis Marco dengan Keymap dan menerapkan aturan prettier dan eslint untuk format. Tetapi setelah proyek publik, mungkin ada kontributor yang masuk (tidak, tidak hhhh), dan saya pikir akan lebih baik untuk mencolokkan gaya kode dalam git commit .
Biasanya, husky sudah cukup untuk proyek ini, tetapi ada begitu banyak file monorepo. Setiap kali git commit semua paket, semua file akan menjadi eslint pasti akan macet, jadi perlu untuk bekerja sama dengan lint-staged untuk meminimalkan pemrosesan eslint, dan hanya membiarkan file dalam git menjalankan Eslint kali ini.
Namun, tampaknya pejabat itu tidak memberikan terlalu banyak saran dan contoh untuk monorepo. Setelah menjelajahinya, saya menemukan bahwa itu tidak merepotkan, tetapi itu tidak sama dengan non-monorepo. Untuk memisahkan dari pacakge.json , saya juga menulisnya menjadi file konfigurasi, kira -kira seperti ini:
module . exports = {
'packages/**/*.ts?(x)' : [ 'prettier --write' , 'eslint' , 'git add' ] ,
'packages/**/*.(css|less)' : [ 'prettier --write' , 'stylelint' , 'git add' ] ,
} ;Saya mencobanya dan itu cukup cepat. Mungkin perlu waktu untuk mengetahui efeknya jika Anda memiliki praktik terbaik yang lebih baik.
Saya mencoba Taro selama sekitar satu malam dan itu tidak terasa sangat ideal. Mengapa? Pertama -tama, yang saya butuhkan adalah React terhadap kerangka kerja小程序, dan yang saya inginkan adalah ONLY applet. Adapun mengapa itu hanya, saya akan menjelaskan secara rinci nanti.
Setelah penggunaan awal, Taro terasa seperti dia adalah seorang master. Dia memiliki tanggung jawab yang berat dan harus kompatibel dengan terlalu banyak lingkungan类小程序, seperti支付宝小程序,今日头条小程序, dll .... dan juga perlu mempertimbangkan kompatibel dengan mesin CSS yoga RN yang tidak ramah. Tim masih sangat sulit. Saya masih sangat mengaguminya. Saya harus memberikan jempol di sini. Selanjutnya, saya akan berbicara tentang perasaan umum saya setelah beberapa jam.
Sempurna! Hal yang sama berlaku untuk pengembangan web normal, tidak ada yang bisa dikatakan. Mendukung HRM dan mendukung modul CSS. Tidak peduli tentang webpack , Anda dapat menjalankannya hanya dengan datang. Namun, satu hal yang patut dicatat adalah bahwa jika Anda ingin kompatibel dengan RN , Anda tidak dapat menggunakan taro-ui atau LIBS UI pihak ketiga lainnya. Anda hanya dapat menggunakan @tarojs/component bawaan. Pembatasan ini tampaknya sangat macet. Saya berharap taro-ui akan mendukung RN sesegera mungkin.
Ini juga sangat sempurna, dan tidak ada hal yang buruk. Setelah berlari, buka alat debug WeChat resmi dan turun ke jalan dengan lancar. Satu -satunya jebakan adalah tidak ramah untuk dukungan monorepo , tentu saja ini bisa dimengerti. Ada beberapa orang yang menggunakan monorepo di Cina. Jika Anda menggunakannya, Anda harus menyesuaikannya sebagai sikap "Anda memiliki kemampuan untuk menyelesaikan masalah apa pun di monorepo ." Saya berlari di bawah monorepo dan saya mengalami masalah ini:
can't find module : ../../../node_modules/@tarojs/taro-weapp/
Ada juga beberapa orang di komunitas yang berbicara tentang masalah, seperti dukungan monorepo. Pendekatan saya mirip dengan dia. Mereka menggunakan nohoist benang wokesspaces untuk melakukannya. Namun, solusi saya adalah hanya menyimpan modul terkait Taro di bawah sub -paket. Untuk hal -hal lain, lebih baik meningkatkan dan memaksimalkan modul berbagi:
{
"nohoist" : [ " **/@tarojs/** " ]
} Saya menjalankannya setelah melihat dev:rn di package.json . Hasilnya bagus. Saya melihat prompt bahwa kompilasi itu berhasil, tetapi tidak ada berikut ... Lalu saya pergi ke dokumen resmi dan merasa agak rumit. Jadi apa perbedaan antara ini dan mencoba melakukan satu set pengembangan RN asli saja? Dan jika Anda mengandalkan Taro , versi RN terkunci di 0.55.4 , ya ampun! Ini jauh dari nomor versi resmi 0.60.x Anda harus tahu bahwa setiap versi iterasi RN adalah lompatan kualitatif. Jika Anda menggunakan 0.60.x , Anda juga bisa mendapatkan Hermes di Android, dan efisiensinya akan sangat ditingkatkan. Hal lain yang membuat saya khawatir adalah menggunakan RN@Taro berarti Anda hanya dapat menggunakan UI lib @tarojs/component , yang berarti bahwa Anda harus menyerahkan NativeBase dan Shoutem yang relatif berkualitas tinggi UI Libs di RN .
Nah ... Singkatnya, jika Anda tidak berpikir tentang menghemat biaya dan waktu, dan ingin一套代码多处运行, disarankan untuk melepaskan RN@Taro . Jika Anda ingin berbicara tentang waktu masuk terbaik, saya pikir setidaknya taro-ui yang mendukung RN . Tentu saja, biaya ini terlalu tinggi, dan sangat mungkin bahwa pejabat tidak akan pernah memberikan dukungan.
Oke, mari kita kembali ke topik. Niat asli saya menggunakan Taro adalah menggunakan hanya untuk program mini di awal, jadi saya pikir "semuanya baik -baik saja" untuk situasi saat ini. Lagipula leaa-app masih RN atau expo , triknya pada dasarnya dilakukan di proyek-proyek masa lalu (tertawa).
Sangat menyedihkan untuk merekam pengalaman Anda menggunakan Taro di siang hari hari ini ...
Pertama-tama, yang lebih menyakitkan adalah @apollo/react-hooks dan react-apollo tidak didukung! Dengan kata lain, tidak ada paket apollo resmi yang dapat digunakan! Anda tidak dapat useQuery dan bahkan tidak mengizinkan <Query> . Jika Anda menggunakannya, Anda akan melaporkan kait kepada Anda Invariant Violation: Invalid hook call. Hasilnya adalah Anda dapat menulis ekspor apolloClient apolloClient.query() secara langsung. Ini benar -benar malam sebelum pembebasan!
Saya awalnya berpikir itu nyaman, dan saya sangat senang menjalankan dalam mode H5 dengan men -debugging dan apolloClient Saya tidak berharap ... Mode小程序muncul dan mengatakan fetch is not found globally and no fetcher passed, to fix pass.... Saya memeriksa informasi dan mengatakan itu "dalam peningkatan tertentu dari program mini WeChat, pengambilan global telah dihapus" ... Untungnya, saya segera menemukan Lib Wx-Apollo-Fetcher yang ditulis oleh pendahulu saya. Hanya ada beberapa baris dari seluruh perpustakaan:
return new Promise(resolve =>
wx.request({
...
complete: ({ data, statusCode, errMsg }) => resolve({...})
}))
Kemudian ganti pada HttpLink dan fetch: wxApolloFetcher . Saya tidak pernah berharap bahwa WeChat akan melakukan pembaruan gaya tebing seperti itu, yang benar-benar merupakan operasi yang masuk akal.
Berikutnya adalah masalah Path alias . Masalah resmi posting ini dibahas paling intens. Saya mencobanya setelah membacanya, tetapi masih tidak memiliki solusi. Solusinya di sini adalah bahwa solusinya adalah bahwa solusi pada sisi小程序tidak, dan sisi H5 bagus. Bagaimanapun, ini ... Saya monorepo , dan itu akan menjadi sangat memalukan jika saya tidak dapat membagikan kode dalam paket @leaa/common . Oke, saya tidak akan menggunakannya lagi, menanggungnya.
Saya pikir itu sudah siksaan setelah mengalami pengembangan RN , tapi kali ini ... oh, jangan membicarakannya lagi, saya menyalahkan teknologi yang saya gunakan terlalu baru (bang).
? Membaca lebih lanjut ...
