对话框是前端开发和应用程序中非常常见的接口模式。作为独立窗口的对话框通常用于信息显示，输入信息或更多其他功能。，在某些情况下的对话框中会有一些麻烦。例如：
如果要在多个子组件（a，b）中控制对话框（C）的显示阴影，则必须在“共同父”组件中声明此对话框。
如果需要将参数传递到对话框（c），我们通常会使用道具，这意味着状态的管理必须是儿童组件（a，b）或更高级别的管理和维护级别的母体组件，但实际上，这些方法可能只需要在子组件A或B中维护。在这种情况下，我们需要自定义事件以返回状态，这更麻烦。
一个显示对话框，对话框可能只是指示副本不同，并且在不同位置需要多次需要定义。例如，系统中通常使用的对话框和失败的对话框。
我们通常定义一个通用组件，在父组件中定义，然后在使用时唤起它，但是如果我们需要在不同页面上使用它，则需要在不同的页面组件中使用该定义。
这些方案用于实际开发中，尽管可以正常使用，但我们基本上是在我们的开发中完成的。但是，隐藏了一些小问题。
如果与Mysalesorders相同级别的组件也访问此对话框（C）？或，MySalesorders下方的深层孙子组件也应该是对话框（C）？前者意味着该代码需要重建，并且Mysalesorders组件的父部分继续改善；后者意味着业务逻辑处理更加复杂，需要通过恢复自定义事件的层来完成。
需要在不同的地方多次引入相同的组件。系统添加了大量的重复代码。代码很快就会肿，难以理解和维护。
对于上诉问题，本质是：我们应该在哪里定义日常项目中的对话框？如何与对话框进行交互？
从另一个角度查看对话框。实际上，对话框本身是一个-to -One或一个-to -to -Many UI模式。从对话框的透视图中，对话框本质上是一个窗口，独立于完成独立函数的其他接口。“
如果您从视觉角度开始，您会发现当您使用对话框时，您将不在乎它弹出的哪个特定组件，而您只会关心盒子本身的内容。例如，一个对话框可以在组件A中单击成功和故障，也可以通过组件或其他组件订购。对话框的本质确定其独立于每个组件。
尽管该对话框在开始时的实现非常高，但在整个应用程序的持续开发和演变中可能会不断变化。因此，当定义对话框时，其定位基本上等同于使用唯一的URL路径定义页面。前者由POP -UP层实现，后者是页面的切换。对于页面级别的UI开关，我们很容易理解，也就是说，即定义整个路线。因此，如果我们以相同的方式考虑对话框，实际上是管理对话框全局，然后通过全局机制管理这些对话框。此过程与页面的切换非常相似URL，因此我们可以为每个对话框定义一个全局唯一的ID，然后通过此ID显示或隐藏一个对话框，然后将参数传递给其。
基于这个想法，我们可以尝试使用全球状态管理设置对话框。
代码实施主要是反应项目。
redux -reducer存储Redux的存储存储，以存储每个对话框的状态和参数。
Redux -Action处理对话框显示以隐藏两个动作，分别用于显示和隐藏对话框。
Hook -useCommonModal定义了一个钩子，该钩子被封装以存储其内部包装中的操作，以实现对话框状态的状态管理的逻辑重复使用。
创建对话框 - 容器模块创建对话框时，请使用容器模式。当对话框不可见时，它将直接返回null，以免呈现任何内容；并确保即使页面上的页面在页面上定义，也不会影响pageperformance。
对话返回价值处理通常是在实际使用中。打开对话框以进行操作后，可能有必要将返回值返回给呼叫者。有两种参考方法：
运行实例全局模式
共享使用对话框的实用方法：使用全局状态管理对话框。解决上述对话框中遇到的问题。从UI模式的角度来看，核心思想是从UI模式的角度来看。对话框也可以用作单独的页面。对话框的显示可以在全球状态下进行管理。因此，这是一种以全局方式管理对话框的非常合理的方法。因此，组件的语义更加清晰，并且代码更易于理解和维护。
对于对话框的定义，您实际上可以区分场景。系统中的模块下的业务对话框只需要在此业务模块的根部组件下定义。对于可以使用的公共对话框全局，可以在整个系统的根部组件中定义，并且可以在任何地方使用系统。定义位置确定对话框组件的辐射的广度。
当然，此全局状态管理对话框方法仅增强了原始对话框操作并解决方案中的一些问题，但是对于一些简单的对话框，我们仍然可以管理，管理和管理和管理和管理和控制。每个人都可以根据场景定义要使用的方法。