在多个 Tauri 进程中松散同步你的 (Zustand) 存储
Below I will explain how you can easily synchronize your React store, that is Zustand (used in the examples), Redux or any store you use, in multiple Tauri processes (windows). If you faced this problem before and want a relatively simple solution, this post is for you.
下面我将解释如何轻松地在多个 Tauri 进程（窗口）中同步您的 React 存储，即 Zustand（在示例中使用）、Redux 或您使用的任何存储。如果您之前遇到过这个问题并想要一个相对简单的解决方案，这篇文章就是为您准备的。
The problem#
问题#
Early in the development of Hopp, we decided to use Zustand for state management. Zustand is a lightweight state management library that is easy to use and has a small bundle size. Also its API is really nice and easy to understand. But there was one problem.
在 Hopp 的早期开发中，我们决定使用 Zustand 进行状态管理。Zustand 是一个轻量级的状态管理库，易于使用且包大小小。此外，它的 API 非常好且易于理解。但有一个问题。
The state of the app is living in the main process of the window. This is great for single-window apps, but what happens in multi-window apps that want to consume the same state?
应用的状态存在于窗口的主进程中。这对于单窗口应用程序来说很好，但在想要使用相同状态的多窗口应用程序中会发生什么呢？
Hopp Multi-window example
Hopp 多窗口示例
At Hopp for example, we run one window for the main control panel of our app, and then have a separate window for screen-sharing and remote control, with some of the state needed for both windows, and of course synced, as this might changed and it needs to be reflected in the other window.
例如，在 Hopp 中，我们为应用程序的主控制面板运行一个窗口，然后有一个单独的窗口用于屏幕共享和远程控制，其中一些状态是两个窗口都需要的，当然是同步的，因为这可能会改变，并且需要在另一个窗口中反映。
To overcome this problem, we needed to make a decision, on whether to keep the state on the backend (Rust), and there is great material in the form of blogposts around this topic, or be creative.
为了解决这个问题，我们需要做出一个决定，是将状态保留在后端（Rust）上，并且有关于这个主题的很好的材料以博客文章的形式存在，还是要发挥创造力。
Literally how I felt when deciding what to do with multi-window state management
在决定如何处理多窗口状态管理时，我的感觉就是这样
While holding the state on the backend sounded solid, I really wanted to avoid losing all the reactivity that comes out of the box with Zustand (or Redux or any other state management library). Besides that, every component would be polluted with async...