更具体地说,我询问了国家管理以及向Firestore阅读和写作的最佳实践。在开始设置并为我正在使用的网站进行布局后,我开始想知道这一点。我目前对Firestore的了解是,从集合或文档中获取数据的最基本方法是使用GET( )方法是接收一次读取或使用OnSnapShot()接收文档的实时数据流。由于这些不同的方法,这使我想到了设置组件和状态逻辑的最佳方法。
-
您最初可以调用get()方法并将其设置为等于组件状态。然后,您可以使用该状态将数据传递给组件和儿童。要编写/删除数据,您可以同时写入/删除状态和Firestore文档。这似乎具有有限阅读的好处,但更多的写作。它似乎还增加了组件状态和实际文档之间的DESANC的可能性。
-
为了减少写入的数量,是否可以继续写入/删除该州,而不是同时使用Firestore文件?相反,一旦组件卸下后,您是否可以使用使用效应返回函数来编写/删除状态和文档之间的差异?此选项似乎有限的读取,有限的写作,并且具有单一的数据来源(状态)。但是,卸载文档写入的逻辑可能更复杂。
-
似乎也可以使用onSnapShot()方法删除并发写入/删除状态,并仅将它们放在文档上。似乎每次都可以直接从该文档中聆听文档的更改并更新状态。此选项似乎具有简单的状态逻辑的好处,并且国家与文件之间没有脱节。但是依次似乎会导致很多读写和写作。
我没有发现太多的信息直接讨论这些想法,我对处理与上述示例相关的数据流和州管理的当前最佳实践感到好奇。任何帮助将不胜感激!
More specifically I'm asking about best practices for state management and reading and writing to firestore. I started to wonder about this after starting to set up and layout my data model for a website I'm working on in. My current understanding of firestore is that the most basic ways to get data from a collection or document is using the get() method to receive a one time read, or using onSnapshot() to receive a a real-time data stream of the document. Because of these different methods, it got me thinking about the best way to set up my component and state logic.
-
You could initially call the get() method and set it equal to component state. You could then use that state to pass data to the component and children. To write/and remove data you could concurrently write/remove both to the state and to the firestore document. This seems to have the benefit of limited reads, but more writes. It also seems to add to the possibility of desync between the component state and the actual document.
-
To reduce the amount of writes, could it be possible to continue the write/remove to the state, but not the firestore document concurrently? Instead, could you use a useEffect return function to write/remove the difference between the state and the document once the component unmounts? This option seems to have limited reads, limited writes, and having a single source of truth for the data (the state). But, the logic for the unmount document write could be more complicated.
-
It also seems possible to use the onSnapshot() method to remove the concurrent writes/remove on the state, and have them solely on the document. It seems to be possible to listen to the changes to the document and update the state from that document directly each time. This option seems to have the benefits of easy state logic and no desync between the state and the documents. But in turns it seems like this would cause a lot of reads and writes.
I haven't found too much information discussing these ideas directly, and I was curious on what were the current best practices in dealing with data flow and state management related to the above examples. Any help would be greatly appreciated!
发布评论
评论(2)
创建上下文对于应用程序,
首先,我们将为Firestore Access和Firestore访问和上下文创建一个上下文使用其提供商包装应用程序
authProvider
,我们将创建一个hookuseauth
访问必要的方法或访问firestore -db,让我们从创建上下文开始
,对于挂钩,我们将简单地做 -
现在我们已经创建了已准备好下一步的挂钩
:在您的登录屏幕中使用
signin
以进行严格访问,签名
与
”以下面的组件(PS使用
React> React> React> React-Router-dom
路由),可以从 数据,现在我们将从我们的组件(路由)上访问firestore(路由
)很乐意在评论中解决您的疑问:)
creating the context for the app
first we'll create a context for the firestore access and wrap the App with its provider lets call it
AuthProvider
and we'll create a hookuseAuth
to access necessary methods or accessing firestore-dblet's start with creating the context as -
now for the hook we'll simply do -
now that we've created the hook we are ready for the next step
NOTE: make use of
signin
in your login screen for strict access, andsignout
getting along with
react-router-dom
wrap all your routes that needs acces to firestore data with below component (p.s use
react-router-dom
for route)now we'll access firestore from our hook on components(routes) as
I'll be more than happy to address your doubts in comments :)
我也正在用React Web应用中的Firestore管理服务器端状态的最佳方法 - 尤其是鉴于公告并发react 。
我最终写了自己的国家管理库。
您可能需要查看@gmcfall/react-firebase-state
。它使用听众来确保数据是新鲜的,并且面对许多渲染周期和多个安装/卸载周期,它具有弹性。
你写的
我的经验恰恰相反。我必须更少去服务器的旅行,以确保我的数据是新鲜的。该解决方案的关键是要从持有服务器端状态的本地高速缓存中拥有组件“租赁”数据。但是,当数据索赔数量为零时,实体不会立即被驱逐出缓存。这样,如果用户短暂地远离组件,然后返回,或者同时渲染启动,则数据仍然存在,并且保证它是最新的。
I, too, was wrestling with the best way to manage server-side state from Firestore in a react web app -- especially in light of the announcement about Concurrent React.
I ended up writing my own state-management library.
You might want to check out @gmcfall/react-firebase-state
. It uses listeners to ensure that data is fresh, and it is resilient in the face of many render cycles and multiple mount/unmount cycles.
You wrote that
My experience is just the opposite. I have to make fewer trips to the server to ensure that my data is fresh. The key to this solution is to have components "lease" data from a local cache that holds server-side state. But entities don't get evicted from the cache immediately when the number of claims on the data goes to zero. This way, if the user navigates away from the component briefly and then returns, or if concurrent rendering kicks in, the data will still be there, and it is guaranteed to be up-to-date.