Relay/Apollo 片段应该有多细？
How granular should Relay/Apollo fragments be?
我在我的应用程序中使用 GraphQL + Relay，发现我用 createFragmentContainer 包装了几乎每个组件，包括那些在 DOM 层次结构中非常低的组件（通常是功能组件）。
这是使用片段的正确方法吗？我想知道何时将组件包装在片段容器中的准则是什么？当它只需要一个字段时包装一个组件似乎是多余的，我可以通过道具从父级传递该数据。
我正在使用 Relay，但我认为这些概念也与 Apollo 相似。
是的，是的。与其查询根组件上的所有数据并将其作为道具传递给其他人，不如创建片段容器，并且每个组件都查询自己的数据。并且由于中继数据屏蔽，这些来自片段的数据只能在需要它的组件内部看到。
也许这是一本好书：https://medium.com/entria/relay-apollo-anti-pattern-d9f4dea47738
Data Masking：https://facebook.github.io/relay/docs/en/thinking-in-relay.html
希望对您有所帮助:)
这是我在 Relay 团队工作的同事 Jan Kassens 的回答：
If splitting out components makes sense to you, you should go for it. I find smaller modules generally help making code more understandable.
Now, a Button component probably doesn't have to have a fragment attached to it, but if it's a "Like Page" button with a mutation and maybe label specific to the page, I think it makes total sense to make that it's own fragment container.
As with so many things in engineering, there's probably trade offs in splitting out too much, but we've spent a lot of thought on making fragment containers as lightweight and efficient as we can so you shouldn't think too hard about introducing overhead.
我在我的应用程序中使用 GraphQL + Relay，发现我用 createFragmentContainer 包装了几乎每个组件，包括那些在 DOM 层次结构中非常低的组件（通常是功能组件）。
这是使用片段的正确方法吗？我想知道何时将组件包装在片段容器中的准则是什么？当它只需要一个字段时包装一个组件似乎是多余的，我可以通过道具从父级传递该数据。
我正在使用 Relay，但我认为这些概念也与 Apollo 相似。
是的，是的。与其查询根组件上的所有数据并将其作为道具传递给其他人，不如创建片段容器，并且每个组件都查询自己的数据。并且由于中继数据屏蔽，这些来自片段的数据只能在需要它的组件内部看到。
也许这是一本好书：https://medium.com/entria/relay-apollo-anti-pattern-d9f4dea47738
Data Masking：https://facebook.github.io/relay/docs/en/thinking-in-relay.html
希望对您有所帮助:)
这是我在 Relay 团队工作的同事 Jan Kassens 的回答：
If splitting out components makes sense to you, you should go for it. I find smaller modules generally help making code more understandable. Now, a Button component probably doesn't have to have a fragment attached to it, but if it's a "Like Page" button with a mutation and maybe label specific to the page, I think it makes total sense to make that it's own fragment container.
As with so many things in engineering, there's probably trade offs in splitting out too much, but we've spent a lot of thought on making fragment containers as lightweight and efficient as we can so you shouldn't think too hard about introducing overhead.