代码组织
代码组织
Rails 风格
在文档，示例项目和许多教程中找到的默认组织有时称为
这种方法的成本是可伸缩性。在示例的最末端，截止到
Domain 风格
您会发现域样式或基于功能的组织的多种变体。通常，这些变体的每个目标都是将相关代码分组在一起。假设您的应用程序具有订阅工作流程以注册新客户。例如，基于域的模式不是将相关的组件，动作和缩减器分布在多个目录中，而是主张将它们全部放在一个订阅目录中。
单个容器组件可以从多个域中提取状态以在结帐过程中呈现页面的情况并不少见。例如，如果用户将商品添加到他们的购物车中，则您可能会在产品页面，标题和购物车侧栏中看到更新。您可以采取哪些措施来更好地组织共享数据？
一种可选的域样式模式是将容器和组件保留在
最大的胜利就是能够在一处找到更多您需要的东西。例如，如果您已购买了用于将新功能添加到
您会发现此方法仍然需要权衡取舍，并且您应该了解，并非每个应用程序都有一个答案。这种模式的潜在弱点之一是围绕构成域或特征的内容缺乏确定性或清晰度。有时您会争论一些新功能是属于现有目录还是应该创建一个新功能。在开发人员的工作中添加更多这样的决策和开销是不理想的。
Ducks
在您问之前
const FETCH_STARTED = "parsnip/tasks/FETCH_STARTED";
const FETCH_SUCCEEDED = "parsnip/tasks/FETCH_SUCCEEDED";
const FETCH_FAILED = "parsnip/tasks/FETCH_FAILED";
const CREATE_SUCCEEDED = "parsnip/tasks/CREATE_SUCCEEDED";
const FILTER = "parsnip/tasks/FILTER";
const initialState = {
tasks: [],
isLoading: false,
error: null,
searchTerm: "",
};
export default function reducer(state = initialState, action) {
switch (action.type) {
case FETCH_STARTED:
return { ...state, isLoading: true };
case FETCH_SUCCEEDED:
return { ...state, tasks: action.payload.tasks, isLoading: false };
case FETCH_FAILED:
return { ...state, isLoading: false, error: action.payload.error };
case CREATE_SUCCEEDED:
return { ...state, tasks: state.tasks.concat(action.payload.task) };
case FILTER:
return { ...state, searchTerm: action.searchTerm };
default:
return state;
}
}
export function fetchTasks() {
return { type: FETCH_STARTED };
}
export function createTask({ title, description, status = "Unstarted" }) {
return (dispatch) => {
api.createTask({ title, description, status }).then((resp) => {
dispatch(createTaskSucceeded(resp.data));
});
};
}
export function createTaskSucceeded(task) {
return { type: CREATE_SUCCEEDED, payload: { task } };
}
export function filterTasks(searchTerm) {
return { type: FILTER, searchTerm };
}
您会发现需要权衡的优势。其中最明显的是，根据定义，这些模块文件将比它们替换的任何单个文件大。较大的文件与