LEAA - это Monorepo CMS (система управления контентом), построенная с Nest.js, Next.js и дизайном муравья.
Посмотреть README.md каждого подчинка в packages . Возможно, вам придется сначала посмотреть на рабочие места пряжи.

Тодос
Первоначально краткое изложение должно быть написано в конце статьи, но я чувствую, что его следует выдвигать, по крайней мере, мне не нужно читать мои носки о журналах развития.
Раньше я думал, что я сам попытался подключиться к 5-eNd, написав сам проект с полным стеком. У меня не было времени, и я продолжал тащить его. Когда я написал это, я подумал, что это займет более полугода, но я не ожидал, что это займет всего полтора месяца, чтобы сделать это. И я также искал лучшие практики во многих местах, и в целом я был весьма доволен.
Первоначальное намерение проекта состояло в том, чтобы использовать React или в основном синтаксис JSX , чтобы сделать больше вещей, таких как написание мини -программ или приложений, и существующая техническая структура также поддерживает мою идею. Я начал идти в путь со своим предыдущим опытом и некоторыми новыми технологиями, такими как GraphQL .
В api , dashboard и www возникают не так много проблем, но miniprogram (小程序,下文简称mp) , а app не так повезло, потому что они не являются стандартными web 语言. Они похожи на рендеринг HTML 富文本, который естественно поддерживает web . На них они становятся fuckingSelf и должны быть проанализированы сами, например, a , потому что в mp и app нет такой a . То, что происходит с пользователями, нажимая a полностью зависит от разработчика, чтобы решить, что полностью отличается от « web -приложения», которое я разработал ранее. Если бы у меня был опыт разработки App , я считаю, что было бы меньше ловушек, чтобы лгать.
Говоря о ловушках, я думаю, что мои навыки копания ямы действительно удивительны. RN популярен, потому что у него много ям, и, как полагают, хорошо известен. Хорошо, я выбрал это. Вы можете не знать ловушки monorepo , но они действительно могут заставить людей умереть. Хорошо, я выберу. В разработке RN с TS не так много подводных камней, но их также много. Хорошо, я тоже выбрал это. Затем я выбрал эту супер большую яму RN + monorepo + TS (Cry), но я все еще немного лежал немного после этого, и я действительно восхищаюсь своим терпением (раздвигая руки).
Почему выбирают monorepo для развития? Мое первоначальное намерение состояло в том, чтобы поделиться interface TS и некоторыми повторно используемыми конфигурациями на 5-й стороне, но позже, когда я написал mp и app , я обнаружил, что из-за некоторых из их специальных механизмов я не мог их поделиться. На самом деле, mp и app полностью изолированы от monorepo . Если я реформирую код позже, я помесчу эти «非标准web 应用» отдельно в репо, потому что им действительно трудно обслуживать. node_modules также имеет один, который не может быть разделен, и каждый из них очень большой. Это не ключ, ключ к тому, что каждый раз, когда yarn install , она очень полон, и процессор парят, что компьютер собирается взлетать. Первоначально я склонен использовать yarn workspaces для решения mono без lerna , но из -за этой проблемы я попытался достать в 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», который должен обрабатывать как передние, так и задними концами, заставляет людей чувствовать себя «невыразимыми скрытыми». С каждым изменением в версии Next.js , как 8TO9, будет много изменений, похожих на скалу. Там нет никакого способа, культура Зейта такая, и вы можете утешить себя только с «все несчастье, потому что быть недостаточно сильным».
Для monorepo в проекте есть много файлов с «аналогичными именами файлов». Много раз я чувствую, что я перегружен файлами и легко вмешивается при поиске файлов. Даже если я сдаюсь, используя Components/Filter/index.tsx чтобы назвать файлы с помощью Components/Filter/Filter.tsx , чтобы найти cmd +. p может быстро найти сам файл вместо каталога, но также трудно избавиться от этого чувства «файла ада».
Первоначально было сказано, что я не должен жаловаться, если бы я мог написать резюме, но теперь кажется, что есть еще некоторые жалобы. В любом месте, от Docker до Api до UI/UX , процесс написания leaa действительно многому меня научил, и у меня есть более глубокое понимание архитектуры программного обеспечения и принципов открытия и закрытия. В прошлом я думал, что «кодирование» и «архитектура» на самом деле делали то же самое, но на этот раз у меня более глубокое понимание.
В настоящее время leaa есть много, много ошибок, но это, похоже, не мешает нуждающимся людям извлекать код, полезный для них в leaa через GitHub. Это также мое первоначальное намерение писать leaa , выше. 2019-09-17 17:01 @ guangxi hezhou
Из GIT Commit, мы видим, что этот журнал разработки (журнал разработки) только сейчас написан. Первоначально проект назывался 1d1h, что означает один час в день. Я хочу собрать предыдущий опыт написания спереди и задней части заканчивается в свободное время и выполнить проект блога с открытым исходным кодом -> CMS -> SOHP, включая API / приборную панель / веб -сайт / WeChat WEAP / React Native (iOS / Android). Поскольку это монорепо, похожий на интерфейс / запись, они обмениваются, поэтому кажется, что это очень удобно создавать полную платформу.
На самом деле, я изначально хотел написать этот журнал развития ранее, но в первые дни я потратил много проблем, которые необходимо решить, и я действительно не мог найти время для написания записей. Теперь я думаю об этом, это действительно не должно быть таким. В конце концов, если я записал много проблем раньше, это было на самом деле невидимое богатство. Хотя я снова встретился, я определенно знал бы, как их решить, но я не мог поделиться ими с другими. Но я постепенно рассмотрю следующие журналы.
Позвольте мне поговорить о моем понимании приборной панели здесь. Я думаю, что минимальная доступная панель инструментов должна быть включена.
Эти модули могут в основном использоваться в качестве блогов после их написания, особенно ролевых разрешений. Если есть бизнес -требования, в основном это очень просто разработать на основе такой минимизации панели панели. Я много раз обрабатывал разрешения в предыдущих проектах, но на этот раз это GraphQL, который немного отличается от предыдущего отдыха, поэтому я все еще потратил некоторое время на то, чтобы бросить.
Я написал так много кода с nest.js, но это неудобно рассмотреть. Причина выбора заключается в том, что меня привлекает всю его парадигму и поддержку типового произведения, которая вооружена зубами. Автор @kamilmysliwiec по -прежнему очень мощный. Некоторые из упаковочных реализаций nest.js очень изысканы. Самое важное также сочетается с различными технологиями и внедрило много бизнес -сценариев. Это действительно здорово.
React + ANTD является общим выбором технологий на dashboard . Тем не менее, на этот раз, потому что hooks полностью запущены, включая Apollo, последние версии Beta Hooks и класс практически невозможно увидеть во всем проекте. Однако после использования крючков в больших масштабах код выглядит действительно уродливым. Если ясность кода класса была набрана 10 очков в прошлом, Хукс мог набрать только 5 очков. Конечно, самое очевидное - заработать код, разделяющий FN. Если бы это было класс, было бы довольно трудно поделиться классом FN.
Для части www нет выбора, это может быть только следующее.js. На самом деле, я уже разработал относительно полный набор React-SSR, но для того, чтобы адаптироваться к волне, и @Guilmo God подталкивает его и дует каждый день, я не мог не покупать следующий.js. Когда я начал писать www, я случайно встретился с выпуском Next.js V9, который является новой версией корабля, которая была переписана в TS с Core. Я думал, что это будет очень гладко, но я не ожидал, что это будет трюк ...
В конце концов, ANTD должен быть интегрирован, что означает, что код собственных страниц клиента должен использовать CSSModule за меньшее количество, ANTD не использует его, и сервер будет бросить его, когда вы видите меньше. Таким образом, официальный без беспроблемний плагин может управлять только до 60%, а оставшаяся 40% -ная поддержка недостаточна. Первоначально, как и Next.js и CRA, это похоже на упаковку WebPack. Я действительно не хочу, чтобы вы коснулись переднего рака, и это хлопота курицы жарки.
Тем не менее, я хотел бы сказать, что рамки дадут вам в несколько раз удобство на ранней стадии проекта, поэтому она в несколько раз вызовет проблемы на более поздней стадии проекта. Это верно для CRA, Expo, и Next.js не является исключением, оба - черные ящики. Тогда я должен написать 100% с плугином за два часа, иначе проект застрянет. Я просмотрел GitHub и хотел посмотреть, есть ли решение, но, к сожалению, я не смог найти соответствующий код сразу после V9. Кажется, я могу только трахать себя. Хотя я очень хорошо знаком с WebPack, Next.js добавил тонкий слой черного ящика в WebPack, написание с Pplugin имеет своего рода погружение в неизвестное море контекста. Это очень разочаровывающий ход, но, к счастью, он наконец был сделан через полчаса. Я упомянул проблему с моим собственным решением и быстро закрыл ее, когда она не была обнаружена. Я надеюсь помочь парням, которые сталкиваются с той же проблемой при поиске проблемы. В конце концов, есть еще много людей, которые нуждаются в следующем.
Время летит так быстро, и пол месяца прошло в мгновение ока. Я недавно не написал ничего нового для LEAA. Основное внимание уделяется интеграции Alibaba Cloud OSS. Хочу реализовать такую функцию:
Процесс довольно сложный, связанный с некоторыми взаимодействиями между местными и OSS. Более того, из -за OSS напрямую все запросы не передаются через API и не становятся обратными вызовами, ожидающими OSS. Необходимо убедиться, что DB не может быть перенесен без выполнения какого -либо шага, едва достигая идентичности. На самом деле, если загрузка выполняется через API, то API обрабатывается равномерно, а затем помещается в OSS, он будет простой и очень большой. Я в основном беспокоюсь, что при выполнении определенных действий, если загружена файлы, параллелизм будет очень большой, а сервер не сможет восстановить. Таким образом, необходимо первым заблокировать OSS.
В основном www, API и Dashboard подошли к концу. Запустите 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 и положил его на вершину ReadMe. Техника, используемая для описания изображений, намного лучше, чем текст. Также упомяните имя Leaa . Это на самом деле имя французской актрисы Léa Seydoux, которое мне нравится. Чтобы избежать высокого уровня дублирования, я добавил дополнительный A за LEA. Тем не менее, наиболее распространенным вопросом LEAA в Google является Law Enforcement Assistance Administration судебный орган США (смеется).
Я только что использовал Lint, чтобы найти несколько ошибок в проекте. Что более интересно, так это packages/leaa-dashboard/src/pages/Permission/PermissionList/PermissionList.tsx .eslintrc.js 120 , printWidth проекта .prettierrc и max-len .
Я должен был добавить eslint-disable-next-line max-len . Очень вероятно, что один из них использовал > , а другой - >= . Однако после того, как я изменил свойства обоих, я обнаружил, что это не проблема. Забудьте это, добавьте первым макс-лэн. В настоящее время есть только одно место, которое есть только. Если образцов не хватает, я не буду иметь дело с этим. Я буду иметь дело с этой проблемой в будущем.
Хотя я обращаю внимание на код стиля, я буду использовать IDE, чтобы написать Marco с KeyMap и применять prettier правила и правила eslint . Но после публики проекта могут быть прихода участников (нет, нет HHHH), и я думаю, что было бы лучше подключить стиль кода в git commit .
Обычно для проекта достаточно husky , но есть так много файлов Monorepo. Каждый раз, когда git commit все пакеты, все файлы будут eslint , неизбежно застрянет, поэтому необходимо сотрудничать с помощью lint-staged чтобы минимизировать обработку Eslint, и только позволить файлам на этапе GIT запустить Eslint на этот раз.
Тем не менее, кажется, что чиновник не дал слишком много предложений и примеров для Monorepo. Изучив это, я обнаружил, что это не было проблемным, но это было не так же, как Non-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 чувствует, что он мастер. Он несет тяжелую ответственность и должен быть совместимы со слишком большим количеством类小程序сред, таких как支付宝小程序,今日头条小程序и т. Д. И. И также необходимо рассмотреть совместимые с недружественным двигателем yoga RN . Команда все еще очень сложна. Я все еще восхищаюсь этим. Я должен дать большие пальцы здесь. Затем я расскажу о своих общих чувствах через несколько часов.
Идеальный! То же самое относится и к обычной веб -разработке, нечего сказать. Поддерживает HRM и поддерживает CSS -модуль. Не заботитесь о webpack , вы можете запустить его, просто поднимаясь. Тем не менее, одна вещь, которая стоит отметить, заключается в том, что если вы хотите быть совместимым с RN , вы не можете использовать taro-ui или другие сторонние либерализатора пользовательского интерфейса. Вы можете использовать только встроенный @tarojs/component . Это ограничение кажется довольно застрявшим. Я надеюсь, что taro-ui поддержат RN как можно скорее.
Это также очень идеально, и нет плохой вещи. После бега откройте официальные инструменты отладки WeChat и плавно выходите на дорогу. Единственная ловушка заключается в том, что он не дружит с поддержкой monorepo , конечно, это понятно. В Китае мало людей используют monorepo . Если вы используете его, вы должны настроить его как отношение «у вас есть возможность решать любую проблему в monorepo ». Я бегаю под monorepo и столкнулся с этой проблемой:
can't find module : ../../../node_modules/@tarojs/taro-weapp/
Есть также некоторые люди в сообществе, которые говорят о таких проблемах, как поддержка Monorepo. Мой подход похож на его. Они используют nohoist of yarn wokesspaces, чтобы сделать это. Тем не менее, мое решение состоит в том, чтобы сохранить только модули, связанные с Taro в подпакете. Для других вещей лучше улучшить и максимизировать модули общего пользования:
{
"nohoist" : [ " **/@tarojs/** " ]
} Я запустил его после того, как увидел dev:rn in package.json . Результат был хорошим. Я увидел подсказку, что компиляция была успешной, но не было никаких последователей ... затем я пошел к официальным документам и обнаружил, что это немного сложнее. Так в чем же разница между этим и попыткой сделать набор натуральных RN Development в одиночку? И если вы полагаетесь на Taro , версия RN заблокирована на 0.55.4 , боже мой! Это далеко от официального номера версии 0.60.x Вы должны знать, что каждая версия итерация RN является качественным скачком. Если вы используете 0.60.x , вы также можете заработать Hermes на Android, и эффективность будет значительно улучшена. Еще одна вещь, которая заставляет меня беспокоиться, заключается в том, что использование RN@Taro означает, что вы можете использовать только пользовательский интерфейс @tarojs/component , что означает, что вы должны отказаться от NativeBase и Shoutem которые являются относительно высококачественными LIBS на RN .
Ну ... подвести итог, если вы не думаете о экономии затрат и времени и хотите一套代码多处运行, рекомендуется отказаться от RN@Taro . Если вы хотите поговорить о лучшем времени входа, я думаю, что это по крайней мере taro-ui , который поддерживает RN . Конечно, эта стоимость слишком высока, и вполне возможно, что чиновник никогда не окажет поддержку.
Хорошо, давайте вернемся к теме. Мое первоначальное намерение использовать Taro было использовать только для мини -программ в начале, поэтому я думаю, что «все в порядке» для текущей ситуации. leaa-app по-прежнему RN или expo , в конце концов, трюк в основном делается в прошлых проектах (смеется).
Так грустно записывать свой опыт использования Taro в течение дня сегодня ...
Прежде всего, более болезненно то, что @apollo/react-hooks и react-apollo не поддерживаются! Другими словами, официальный пакет 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.... Я проверил информацию и сказал, что это «в определенном обновлении программы WeChat Mini, глобальная выборка была удалена» ... к счастью, я сразу обнаружил, что Lib WX-Apollo-носитель написал моим предшественником. Есть только несколько строк всей библиотеки:
return new Promise(resolve =>
wx.request({
...
complete: ({ data, statusCode, errMsg }) => resolve({...})
}))
Затем замените его на HttpLink и fetch: wxApolloFetcher . Я никогда не ожидал, что WeChat сделает такое обновление в стиле обрыва, что действительно является разумной операцией.
Следующим является вопрос alias пути. Официальные вопросы, которые этот пост обсуждался наиболее интенсивно. Я попробовал это после прочтения, но у него все еще не было решения. Решение здесь заключается в том, что раствор заключается в том, что раствор на стороне小程序не является, а сторона H5 хороша. Это ... в конце концов, я monorepo , и это стало бы очень смущающим, если я не смогу поделиться кодом в пакете @leaa/common . Хорошо, я больше не буду использовать это, терпеть это.
Я думал, что это уже было мучением после того, как испытал разработку RN , но на этот раз ... о, давайте больше не будем об этом говорить, я виню, что технология, которую я использовал, слишком новая (взрыв).
? Чтение больше ...