leaa
v3.9.0
Leaa is a monorepo CMS (Content Management System) built with Nest.js, Next.js, and Ant Design.
View the README.md of each sub-directory in packages . You may need to look at yarn workspaces first.
TODOS
Originally, the summary should be written at the end of the article, but I feel that it should be put forward, at least I don’t have to read my nagging about the development logs.
I used to think that I would try to connect to the 5-end by writing a full stack project myself. I had no time and kept dragging it on. When I wrote it, I thought it would take more than half a year, but I didn’t expect it to take only one and a half months to do it. And I also sought best practices in many places, and overall I was quite satisfied.
The original intention of the project was to use React or mainly JSX syntax to do more things, such as writing mini programs or apps, and the existing technical framework also supports my idea. I started to go on the road with my previous experience and some newer technologies such as GraphQL .
There are not many problems encountered on api , dashboard , and www , but miniprogram (小程序，下文简称mp) and app are not so lucky because they are not standard web 语言. They are like HTML 富文本rendering, which naturally supports web . On them, they become fuckingSelf and need to be parsed by themselves, such as a link, because there is no such a in mp and app . What happens to users click a is entirely up to the developer to decide, which is completely different from the " web application" I developed before. If I had experience in App development before, I believe there would be fewer pitfalls to lie.
Speaking of pitfalls, I think my pit digging skills are really amazing. RN is popular because it has many pits and is believed to be well known. Okay, I chose it. You may not know the pitfalls of monorepo , but they can indeed make people die. Okay, I'll choose. There are not many pitfalls in developing RN with TS , but there are also many. OK, I chose it too. Then I chose this RN + monorepo + TS super big pit (cry), but I still lay down little by little afterwards, and I really admire my patience (spreading my hands).
Why choose monorepo to develop? My original intention was to share interface of TS and some reusable configurations on the 5-side, but later when I wrote mp and app , I found that due to some of their special mechanisms, I couldn't share them. In fact, mp and app are completely isolated from monorepo . If I refactor the code later, I will put these "非标准web 应用" separately in a repo because they are really difficult to serve. node_modules also have one that cannot be shared, and each one is very large. It's not the key, the key is that every time yarn install , it's very full, and the CPU is soaring that the computer is about to take off. Originally, I tend to use yarn workspaces to solve mono without lerna , but because of this problem I tried to get on lerna , but the problem did not seem to improve, so I had to give up. This time I really gave me experience with monorepo , which can be regarded as a pain from the flesh, and it also let me know how to choose mono and multi .
OK, if I were asked to write a 5-side difficulty ranking now, I think it would be like this mp > app > www > api > dashboard .
Why is mp listed as the hardest part? Because mp not only has a lot of private goods, but also devtools also have surprisingly many bugs. Sometimes I repair a bug but it doesn’t work well for a long time, but it’s enough to restart devtools. This really makes me vomit blood. And because I used Taro , many new features such as custom-tab-bar did not keep up with it and there was no documentation. I figured it out by myself, but it took a lot of time. Of course, if you use Taro and have the custom-tab-bar requirement, leaa may be the optimal solution for the existing Github solution.
In addition, I had a lot to say about www ( Next.js v9), but as time goes by, these things to say gradually disappear. This kind of "not want to say" is not the kind of "not difficult for those who are not difficult", but because Next.js has too many pitfalls, solving one pit will inevitably lead to several other pitfalls. Moreover, there are no best practices for you to refer to. They are all simple example . Once you want to do some complex functions, this kind of "SSR" that needs to be processed by both the front and back ends does make people feel like "unspeakable hidden". With every change in Next.js version like 8to9, there will be many cliff-like changes. There is no way, zeit's culture is like this, and you can only comfort yourself with "all the unhappiness comes from being not strong enough."
For monorepo , there are many files with "similar file names" in a project. Many times I feel like I'm overwhelmed by files and can easily be interfered when looking for files. Even if I give up using Components/Filter/index.tsx to name the files with Components/Filter/Filter.tsx to find cmd +. p can quickly locate the file itself instead of the directory, but it is also difficult to get rid of this "file hell" feeling.
It was originally said that I should not complain if I could write a summary, but now it seems that there are still some complaints. Anywhere, from Docker to Api to UI/UX , the process of writing leaa has indeed taught me a lot, and I have a deeper understanding of software architecture and opening and closing principles. In the past, I thought that "coding" and "architecture" were actually doing the same thing, but this time I have a deeper understanding.
At present, there are many, many bugs leaa , but this does not seem to prevent people in need from retrieving the code useful to them in leaa through Github. This is also my original intention of writing leaa , above. 2019-09-17 17:01 @ Guangxi Hezhou
From git commit, we can see that this DEV LOG (development log) is only now written. The project was originally called 1d1h, which means one hour a day. I want to gather the previous experience of writing front and back ends in my spare time and do an open source project of Blog -> CMS -> Sohp, including API / Dashboard / Website / Wechat Weapp / React Native (iOS / Android). Because it is a monorepo, similar to interface / entry, these are shared, so it feels that it is a very convenient thing to build a full platform.
In fact, I originally wanted to write this development log earlier, but in the early days, I spent a lot of problems that needed to be solved, and I really couldn't find time to write records. Now I think about it, it really shouldn't be like this. After all, if I recorded a lot of problems before, it was actually invisible wealth. Although I met again, I would definitely know how to solve them, but I couldn't share them to others. But I will review the following logs slowly.
Let me talk about my understanding of Dashboard here. I think a minimum available Dashboard should be included.
These modules can basically be used as blogs after writing them, especially role permissions. If there is a business requirement, it is basically very simple to develop based on such a minimization of Dashboard. I have processed permissions in previous projects many times, but this time it is graphql, which is slightly different from the previous restful, so I still spent some time to tossing.
I have written so much code with Nest.js, but it is not comfortable to consider. The reason for choosing is that I am attracted by his entire paradigm and the support of Typescript that is armed to the teeth. The author @kamilmysliwiec is still very powerful. Some of the packaging implementations of Nest.js are very exquisite. The most important thing is also combined with various technologies and has implemented many business scenarios. This is really great.
React + Antd is a common technology selection on dashboard . However, this time, because hooks are fully launched, including Apollo, the latest hooks beta versions, and Class is almost impossible to see in the entire project. However, after using hooks on a large scale, the code looks really ugly. If the Class code clarity was scored 10 points in the past, hooks could only score 5 points. Of course, the most obvious thing is to earn a code sharing Fn. If it were Class, it would be quite troublesome to share Class Fn.
There is no choice for www part, it can only be Next.js. In fact, I have developed a relatively complete set of React-SSR before, but in order to adapt to the wave, and the @Guillermo God is pushing it up and blowing it every day, I couldn't help but buy Next.js. When I started writing www, I happened to catch up with the release of Next.js v9, which is a new version of the ship that has been rewritten in TS since core. I thought it would be very smooth to use, but I didn't expect it to be a trick...
After all, Antd needs to be integrated, which means that the Client's own pages code needs to use cssModule for less, Antd does not use it, and the Server will throw it when you see less. Therefore, the official withLess plug-in can only manage up to 60%, and the remaining 40% support is insufficient. Originally, like Next.js and CRA, it is like wrapping webpack. I really don’t want you to touch the front-end cancer, and it’s a hassle of stir-frying chicken.
However, I would like to say that a framework will give you several times the convenience in the early stage of the project, so it will cause you several times the trouble in the later stage of the project. This is true for CRA, expo, and Next.js is no exception, both are black boxes. Then I have to write a 100% withPlugin in two hours, or the project will get stuck. I looked through Github and wanted to see if there was a solution, but unfortunately, I couldn't find the relevant code just after v9. It seems that I can only fucking myself. Although I am very familiar with webpack, Next.js added a thin layer of black box to webpack, writing withPlugin has a kind of submerged in an unknown sea of context. It is a very frustrating move, but fortunately, it was finally done in half an hour. I mentioned an issue with my own resolution and quickly closed it when it was not discovered. I hope to help the guys who encounter the same problem when searching for issue. After all, there are still many people who need Next.js + antd withLess, especially in China.
Time flies so fast, and half a month has passed in a blink of an eye. I haven't written anything new to leaa recently. The focus is on the integration of Alibaba Cloud OSS. Want to implement such a function:
The process is quite difficult, involving some interactions between Local and OSS. Moreover, because of the OSS directly, all requests are not passed through the API and become Callbacks waiting for OSS. It is necessary to ensure that DB cannot be moved without completing any step, barely achieving idempotence. In fact, if uploading is done through the API, then the API is processed uniformly and then put to OSS, it will be simple and very large. I mainly worry that when doing certain activities, if uploading files is involved, the concurrency will be very large and the server will not be able to recover. So it is necessary to block OSS first.
Basically www, api and dashboard came to an end. Start miniprogram tomorrow.
When I first sorted out the package, I found that React has been upgraded to 16.9.0. I consoled the next bunch of similar Warning: componentWillMount... I looked at React CHANGELOG and found that it was indeed a major change. A few lifecycle will be discarded in the future version. Since leaa-dashboard depends on antd , it is better to wait for the antd release to eliminate these warnings before upgrading. Currently React is locked in "react": "16.8.6", "react-dom": "16.8.6" .
I made a Leaa Stack Banner and put it on the top of README. The technique used to describe pictures is much better than text. Also mention the name Leaa . This is actually the name of a French actress Léa Seydoux that I like. To avoid the high rate of duplication, I added an extra a behind Lea. However, LEAA most common point on Google is Law Enforcement Assistance Administration a US judicial body (laughs).
I just used lint to find several errors in the project. What is more interesting is packages/leaa-dashboard/src/pages/Permission/PermissionList/PermissionList.tsx L159 Here, printWidth of the project .prettierrc and max-len of .eslintrc.js are set to 120 , but prettier does not report an error and does not format automatically, but eslint told me that it is more than 120.
I had to add eslint-disable-next-line max-len . It feels very likely that one of them used > and the other is >= . However, after I modified the properties of both, I found that this is not the problem. Forget it, add max-len first. At present, there is only one place that is only. If there is not enough specimens, I won’t deal with it. I will deal with this problem in the future.
Although I pay attention to style code, I will use the IDE to write marco with keymap and apply prettier and eslint rules to format. But after the project public, there may be contributors coming in (no, no hhhh), and I think it would be better to plug in code style in git commit .
Usually, a husky is enough for the project, but there are so many monorepo files. Every time git commit all packages, all files will be eslint will inevitably get stuck, so it is necessary to cooperate with lint-staged to minimize eslint processing, and only let the files in git stage run eslint this time.
However, it seems that the official has not given too many suggestions and examples for monorepo. After exploring it, I found that it was not troublesome, but it was not much the same as non-monorepo. In order to decouple from pacakge.json , I also wrote it into a configuration file, roughly like this:
module . exports = {
'packages/**/*.ts?(x)' : [ 'prettier --write' , 'eslint' , 'git add' ] ,
'packages/**/*.(css|less)' : [ 'prettier --write' , 'stylelint' , 'git add' ] ,
} ;I tried it and it was quite fast. It may take some time to know the effect if you have better best practices.
I tried Taro for about one night and it didn't feel very ideal. Why? First of all, what I need is a React to小程序framework, and what I want is ONLY applet. As for why it is ONLY, I will explain in detail later.
After initial use, Taro feels like he is a master. He has a heavy responsibility and needs to be compatible with too many类小程序environments, such as支付宝小程序,今日头条小程序, etc.... And it also needs to consider compatible with RN 's unfriendly yoga CSS engine. The team is still very difficult. I still admire it very much. I must give a thumbs up here. Next, I will talk about my general feelings after a few hours.
Perfect! The same is true for normal web development, there is nothing to say. Supports HRM and supports css module. Don't care about webpack , you can run it just by coming up. However, one thing worth noting is that if you want to be compatible with RN , you cannot use taro-ui or other third-party UI libs. You can only use the built-in @tarojs/component . This restriction seems to be quite stuck. I hope taro-ui will support RN as soon as possible.
It is also very perfect, and there is no bad thing. After running, open the official WeChat debug tools and get off to the road smoothly. The only pitfall is that it is not friendly to monorepo support, of course this is understandable. There are few people using monorepo in China. If you use it, you must customize it as an attitude of "you have the ability to solve any problem on monorepo ." I run under monorepo and I encountered this problem:
can't find module : ../../../node_modules/@tarojs/taro-weapp/
There are also some people in the community who are talking about issues, such as monorepo support. My approach is similar to that of him. They use the nohoist of yarn wokesspaces to do it. However, my solution is to only keep Taro -related modules under sub-package. For other things, it is better to improve and maximize the share modules:
{
"nohoist" : [ " **/@tarojs/** " ]
} I ran it after seeing dev:rn in package.json . The result was good. I saw the prompt that the compilation was successful, but there was no following... Then I went to the official docs and found it a bit complicated. So what is the difference between this and trying to do a set of native RN development alone? And if you rely on Taro , RN version is locked at 0.55.4 , my goodness! This is far from the official version number of 0.60.x You should know that every version iteration of RN is a qualitative leap. If you use 0.60.x , you can also earn Hermes on Android, and the efficiency will be greatly improved. Another thing that makes me worry is that using RN@Taro means that you can only use the UI lib @tarojs/component , which means that you have to give up NativeBase and Shoutem which are relatively high-quality UI libs on RN .
Well... To sum up, if you are not thinking about saving costs and time, and wanting一套代码多处运行, it is recommended to give up RN@Taro . If you want to talk about the best entry time, I think it is at least taro-ui that supports RN . Of course, this cost is too high, and it is very possible that the official will never provide support.
OK, let’s get back to the topic. My original intention of using Taro was to use ONLY for mini programs at the beginning, so I think "everything is OK" for the current situation. leaa-app is still RN or expo , after all, the trick is basically done in the past projects (laughs).
It's so sad to record your experience of using Taro during the day today...
First of all, the more painful thing is that @apollo/react-hooks and react-apollo are not supported! In other words, no official Apollo package can be used! You can't useQuery and don't even allow <Query> . If you use it, you will report hooks to you Invariant Violation: Invalid hook call. The result is that you can write the export apolloClient apolloClient.query() directly. This is really a night before liberation!
I originally thought it was convenient, and I was very happy to run in H5 mode by debugging and apolloClient I didn't expect...小程序mode popped up and said fetch is not found globally and no fetcher passed, to fix pass.... I checked the information and said it was "In a certain upgrade of WeChat mini program, the global fetch was removed"... Fortunately, I immediately found the lib wx-apollo-fetcher written by my predecessor. There are only a few lines of the entire library:
return new Promise(resolve =>
wx.request({
...
complete: ({ data, statusCode, errMsg }) => resolve({...})
}))
Then replace it on HttpLink and become fetch: wxApolloFetcher . I never expected that WeChat would do such a cliff-style update, which is really a sensible operation.
Next is the issue of path alias . The official issues this post was discussed the most intensely. I tried it after reading it, but it still had no solution. The solution here is that the solution is that the solution on小程序side is not, and H5 side is good. This... I'm monorepo after all, and it would become very embarrassing if I can't share the code in @leaa/common package. OK, I won’t use it anymore, bear it.
I thought it was already a torment after experiencing RN development, but this time... Oh, let's not talk about it anymore, I blame the technology I used is too new (bang).
? READING MORE...
