在线时间:8:00-16:00
迪恩网络APP
随时随地掌握行业动态
扫描二维码
关注迪恩网络微信公众号
开源软件名称(OpenSource Name):arackaf/micro-graphql-react开源软件地址(OpenSource Url):https://github.com/arackaf/micro-graphql-react开源编程语言(OpenSource Language):JavaScript 99.4%开源软件介绍(OpenSource Introduction):micro-graphql-reactThe current version is 0.4.0-beta, but the beta is only because of the React Suspense stuff which itself is still in beta. The non-Suspense code in the latest version should be considered stable and safe. A light (2.8K min+gzip) and simple solution for painlessly connecting your React components to a GraphQL endpoint. Like any other GraphQL React client, there are simple hooks which query and mutate data from your GraphQL endpoint. Where this project differs is how it approaches cache invalidation. Rather than adding metadata to queries and forming a normalized, automatically-managed cache, it instead provides simple, low-level building blocks to handle cache management yourself. The reason for this (ostensibly poor!) tradeoff is because of my experience with other GraphQL clients which attempted the normalized cache route. I consistently had difficulty getting the cache to behave exactly as I wanted, so decided to build a GraphQL client that gave me the low-level control I always wound up wanting. This project is the result. Full docs are here The slides for the GraphQL Texas talk I gave are here The rest of this README describes in better detail the kind of cache management problems this project attempts to avoid. Common cache difficulties other GraphQL clients contend withCoordinating mutations with filtered result setsA common problem with GraphQL clients is configuring when a certain mutation should not just update existing data results, but also, more importantly, clear all other cache results, since the completed mutations might affect other queries' filters. For example, let's say you run tasks(assignedTo: "Adam") {
Tasks {
id, description, assignedTo
}
} and get back [
{ id: 1, description: "Adam's Task 1", assignedTo: "Adam" },
{ id: 2, description: "Adam's Task 2", assignedTo: "Adam" }
]; Now, if you subsequently run something like mutation {
updateTask(id: 1, assignedTo: "Bob", description: "Bob's Task")
} the original query from above will update and now display [
{ "id": 1, "description": "Bob's Task", "assignedTo": "Bob" },
{ "id": 2, "description": "Adam's Task 2", "assignedTo": "Adam" }
]; which may or may not be what you want, but worse, if you browse to some other filter, say, This library solves this problem by allowing you to easily declare that a given mutation should clear all cache entries for a given query, and reload them from the network (hard reset), or just update the on-screen results, but otherwise clear the cache for a given query (soft reset). See the docs for more info. Properly processing empty result setsAn interesting approach that the first version of Urql took was to, after any mutation, invalidate any and all queries which dealt with the data type you just mutated. It did this by modifying queries to add tasks(assignedTo: "Adam") {
Tasks {
id, description, assignedTo
}
} and get back {
"data": {
"tasks": {
"__typename": "TaskQueryResults",
"Tasks": []
}
}
} It's more or less impossible to know what the underlying type of the empty Are these actual problems you're facing?These are actual problems I ran into when evaluating GraphQL clients, which left me wanting a low-level, configurable caching solution. That's the value proposition of this project. If you're not facing these problems, for whatever reasons, you'll likely be better off with a more automated solution like Urql or Apollo. To be crystal clear, nothing in this readme should be misconstrued as claiming this project to be "better" than any other. The point is to articulate common problems with client-side GraphQL caching, and show how this project solves them. Keep these problems in mind when evaluating GraphQL clients, and pick the best solution for your app. |
2023-10-27
2022-08-15
2022-08-17
2022-09-23
2022-08-13
请发表评论