The resources
Github.com/phodal/clea…
Github.com/bespoyasov/…
Github.com/falsy/react…
www.cnblogs.com/yjf512/arch…
The way to clean architecture
preface
Personal ability is limited, if there is a mistake please correct.
There are still quite a few problems with my implementation architecture:
-
Dependency injection is not used
-
Each module relies on abstraction
-
Division of responsibilities
-
The toughest test (😓 is too busy)
As you read this article, I’m assuming you’ve read phodal Clean Frontend Architecture
And understand uncle Bob’s neat architecture
domain
Let’s take a look at the directory structure first. The directory structure is clean-frontend
├─ SRC ├─ Code ├─ Domain ├─ Features ├─ Pages ├─ Presentation ├─ Router ├─ StoresCopy the code
Phodal article mentioned, here I do repeat.
The router: routing
Stores: state management
So let’s look at domains
├ ─ domain ├ ─ admin │ ├ ─ adapter/ / adapter│ ├ ─ model/ / model│ ├ ─ repositories/ / container│ │ └ ─ mapper// Field mapping│ └ ─ usecase/ / use cases
Copy the code
Basically the same, except for one more adapter. Because in the phodal architecture, I always wondered why there was no Adapter.
I think angular services take on the responsibilities of the Adapter.
model
Entity Is the type returned to us by the interface when we request it.
The model is the data type that our UI will use, and the type is slightly different from entity.
repositories
I prefer to call it an interface repository, which is responsible for requesting apis
The Mapper is responsible for converting the entity requested by the interface into the Model data required by the UI.
adapter
Let’s look at another sentence:
The purpose of this layer of software architecture is to transform data, transforming the data structures that are convenient for the user instance and entity layer into the data structures that are most convenient for external structures (such as databases or the Web). For example, the MVC structure of the GUI, the representation, the view, and the controller all belong to this structure. This layer probably passes the data structure to the user instance layer through the controller and returns the data to the representation, the view.
Simply put, data can be passed to the UI layer through adapter.
Mapper under Tips: Repositories is also an Adapter.
So we can encapsulate react hooks as Adapters.
For the rest, we can write business code directly using phodal’s rules.
usecase
Responsible for calling the and mapper map.
Layers of dependencies
presentation <- adapter <- usecase <- repositories <- model
adapter
In my architectural design, the Adapter is just a generic hook.
The Adapter combines with the React Context
When I’m using the context, I’m used to throwing all the methods into the context at once.
Try putting only state in context. Some business functions can be placed in Adapter. Providers only need to expose state and set methods.
export const UserProvider = ({ children }) = > {
const [user, setUser] = useState<UserModel>()
const [activeId, setActiveId] = useState<string> ()const [userAction, setUserAction] = useState<UserActionDetail>({} as UserActionDetail)
const value = useMemo(
() = > ({
user,
activeId,
userAction,
updateUser: setUser,
updateUserAction: setUserAction,
updateActiveId: setActiveId
}),
[user, userAction, activeId, setUser, setUserAction, setActiveId]
)
return <UserContext.Provider value={value}>{children}</UserContext.Provider>
}
Copy the code
export const useGetUserActionListAdapter = () = > {
const { activeId, updateUserAction, updateActiveId } = useUserContext()
const handleSomeThinkg = userAction= > {
updateUserAction(userAction)
updateActiveId(0)}}Copy the code
Use this method in the corresponding Adapter, and finally use our custom hooks in the page.
At the end
The structure is just a blank room, the house decoration is not good-looking, decide all this or “design team”, “decoration team” and so on. Don’t start with clean architecture, because clean architecture is not a silver bullet!
github