Question

我目前正在使用 React 和 Firebase 开展一个项目，目前我将新数据写入 Firestore 的逻辑直接在我的组件中。我现在也在集成 Redux，为此我使用 react-redux-firebase。我现在的问题是，把这个逻辑放在哪里最好，因为它让我的组件安静膨胀。

在react-redux-firebase的documentation中，他们也直接把它放在组件中，但是他们的逻辑很简单，我的有点复杂，就像这个handleSubmit：

const handleSubmit = async (e) => {
    e.preventDefault();
    setDisabled(true); //disable button to prevent multiple sbumits
    setLoading(true);

    try {
      const docRef = await firestore.collection("goodies").add(newGoodieData); // create new event
      await firestore.collection("goodies").doc(docRef.id).update({
        // add eventId to event doc
        id: docRef.id,
      });

      if (image) {
        const imageName = docRef.id + "." + image.name.split(".").pop(); //create image name with eventID and file extions

        const imageRef = storage.ref().child("goodie_images/").child(imageName); //create imageRef

        const imageSnapshot = await imageRef.put(image); //upload image to storage

        const downloadUrl = await imageSnapshot.ref.getDownloadURL(); //get image download-url

        const imagePath = imageRef.fullPath; // get image storage path

        await firestore.collection("goodies").doc(docRef.id).update({
          //update event with imageUrl and imagePath
          image: downloadUrl,
          imagePath: imagePath,
        });
      }
      setDisabled(false);
      setLoading(false);

      dispatch(showSuccessToast(`Created new goodie "${newGoodieData.name}"!`));
      history.push("/goodies");
    } catch (error) {
      dispatch(showErrorToast("Ops, an error occurred!"));
      console.error(error.message);
    }
  };

Answer 1

这完全是我的习惯，但我使用如下结构。一般来说，组件和页面（即反应组件）名称是首字母大写：

src
|-blocks
|-components
|-css
|-navigation
|-pages
|-services
|-App.js
|-constants.js
|-index.js

块

这些是我的特定于应用程序的组件，以及一些更大的特定于应用程序的功能。

|-blocks
  |-Block1
  | |-index.js
  | |-aSubModule.js
  |-Block2
  | |-index.js
  | |-aSubModule.js
etc, etc

组件

这些是“通用”组件 - 即可以作为模块发布，或者从外部模块定制。这些不是特定于应用程序的。类似于“块”的结构

|-components
  |-ComponentThatDoesThisThing
  |-ComponentThatDoesThatThing
etc, etc

CSS

顾名思义...

导航

页眉、页脚、导航菜单。还有导航辅助功能（例如包装页面链接等）

|-navigation
  |-Header
  |-Menu
  |-Footer
etc, etc

页面

我所有的反应页面和子页面，无论需要什么深度。页面下方的所有内容都特定于应用程序

|-pages
  |-Users
  | |-Home
  | | |index.js
  | | |-etc,etc
  | |-Account
  | |-Bio
  | |-etc,etc
  |-Owners
  | |-Home
  | |-Account
  | |-Bio
  | |-etc,etc
  |-index.js

更直接地解决您的问题：

服务

|-services
  |-reduxEnhancers
  |-reduxMiddleware
  |-reduxRootReducers
  |-slices
  |-configureStore.js
  |-firestore.js

与教程没有太大区别。但这就是我的切片中的内容 - 或多或少对应于 redux 状态切片：

切片

|-services
  |-slices
    |-UserSlice
    | |-actions
    | | |-index.js
    | |-reducer
    | | |-index.js
    | |-business
    | | |-index.js
    | |-index.js
    |-OwnerSlice
    | |-actions
    | | |-index.js
    | |-reducer
    | | |-index.js
    | |-business
    | | |-index.js
    | |-index.js
    |-KitchCupboardSlice
    | |-actions
    | | |-index.js
    | |-reducer
    | | |-index.js
    | |-business
    | | |-index.js
    | |-index.js
    |-etc,etc slices
    |-index.js

重要说明：大多数 Redux 教程都展示了 Redux 切片与 React 组件具有相同的分支结构。一般来说，情况并非如此，我还没有找到一个甚至有用的案例。数据的树状结构并不一定像页面和 React 组件的树状结构——按照数据希望你的方式来划分你的 Redux 存储，而不是用户的方式- 面向 React 希望你这样做。本论坛更重要的是：让数据的 FIRESTORE 结构为您提供指导。

正在使用中：

|-services
  |-slices
    |-UserSlice
    |-index.js

...例如，从 actions、reducer 和 business 导入然后导出所有公共/导出符号。

|-services
  |-slices
    |-UserSlice
     |-reducer

...reducer 使用 store.injectReducer 将自己添加到 Redux 存储中，使用

中定义的符号和常量

|-services
  |-slices
    |-UserSlice
     |-actions

...actions，它还创建特定的 Redux 操作和辅助样板（操作、选择器等）。

帮助分离责任：

|-services
  |-slices
    |-UserSlice
     |-business

...business 子目录包含您提到的 BUSINESS 逻辑 - React 组件可能需要调用的任何逻辑，这些逻辑并非特定于 React 模块的显示和状态方面。这也是我定义对 firestore 或任何其他外部服务或获取的任何访问的地方 - React 组件不应该关心这是如何完成的。

为了更方便地访问所有这些不同的导出，我使用

|-services
  |-slices
    |-index

...从所有切片中导入然后导出所有公共/导出的符号。更容易导入到各种 React 组件中，而无需担心 slices

的底层结构发生变化

正如我所说，完全是我的特质，但它有助于分离责任。

我应该把将新数据写入 Firestore 的逻辑放在哪里？

1 个答案: