nilan
04/12/2017, 9:13 AMartyom
04/12/2017, 9:15 AMputuyoga
04/12/2017, 9:17 AMartyom
04/12/2017, 9:31 AMadam.hoscilo
04/12/2017, 10:34 AMwallslide
04/12/2017, 11:40 AMartyom
04/12/2017, 11:41 AMbrad.barnes
04/12/2017, 11:49 AMartyom
04/12/2017, 1:16 PMartyom
04/12/2017, 2:20 PMartyom
04/12/2017, 2:54 PMnickccm1122
04/12/2017, 2:55 PMaaronkchsu
04/12/2017, 3:10 PMaaronkchsu
04/12/2017, 3:10 PMartyom
04/12/2017, 6:40 PMvacom
04/12/2017, 7:33 PMsvrcekmichal
04/12/2017, 7:48 PMnilan
04/12/2017, 7:49 PMsvrcekmichal
04/12/2017, 8:14 PMIn short, Relay lends itself well for large-scale applications that have complex data requirements and many dependencies between different parts of the application where maintaining these dependencies by hand would be very tedious and error-prone. Apollo on the other hand provides a much more lightweight and flexible approach that works in any environment. Many tasks such as keeping the local cache consistent can also be achieved with the Apollo Client but require more manual work and bookkeeping.
I can't agree more with this sentence, because when we started to build are first application I've heard so much stuff about complexity which relay brings that I didn't even tried it and only used Apollo. And apollo was in the process of building, it was changing quite often, but it didn't mattered that times. The problem for me is mentioned above. It's great for small applications, but when we were getting to more complex stuff it expected from us too much work to do on our side. But what I want to talk is few sentences in article which should probably be better explained to people.
In Relay, every object is expected to have a unique ID which is why every model type needs to implement the Node interface
I would mention that, yes, it's expected, but it's not must. The reason of the global node id is for better graph traversing and reducing how much would relay query from server. In article you mention that it's for effective fetch after mutation, but it's also for effective fetch when fragment variables changes like load more edges of connection or some modal become visible etc.
mutation needs to be defined as a subclass of the Relay.Mutation class
There is also low level API for modeling mutation, can be seen here: https://facebook.github.io/relay/docs/api-reference-relay-graphql-mutation.html#content It's prepared for relay 2 to reduce learning curve of mutationssvrcekmichal
04/12/2017, 8:16 PMsvrcekmichal
04/12/2017, 8:18 PMzth
04/12/2017, 8:46 PMzth
04/12/2017, 8:46 PMzth
04/12/2017, 8:46 PMzth
04/12/2017, 8:47 PMzth
04/12/2017, 8:47 PMartyom
04/12/2017, 10:16 PMmel
04/13/2017, 12:44 AMtrphthinh1712
04/13/2017, 3:11 AMtrphthinh1712
04/13/2017, 3:12 AM