3 ms·

Have you seen the actual code of the mutations? https://github.com/facebook/relay/blob/master/examples/todo/js/mutations/ChangeTodoStatusMutation.js https://gi

by _mikz 11y ago

Have you seen the actual code of the mutations? https://github.com/facebook/relay/blob/master/examples/todo/js/mutations/ChangeTodoStatusMutation.js https://github.com/facebook/relay/blob/master/examples/todo/... It is ... massive!

joelgrus 11y ago
Yeah, as someone who knows a fair amount of JS but almost nothing about React, that todomvc implementation does not particularly scream "this is the framework you want to learn".
yazaddaruvala 11y ago
One thing I think is a poor design choice on the part of the implementer of this example: Note: Not a design choice of Relay Is that each Mutation file is redundant. Each Mutation file corresponds one - one with a component file. I think it does a big disservice to React itself (specifically JSX), which advocates for collocating View and Template because of cohesion. Maybe its subjective.. and I can surely see the reasons for separating them, but I hope yungsters is reading this and collocates the mutations.
- underwater 11y ago
  Mutations are global, not view specific. They can be triggered by multiple views, and are smart enough to only refetch the data that is currently being shown. For Facebook we can write a single "like" mutation and share it between comments, posts, photos, etc.
underwater 11y ago
The API for mutations is one of the things we were least happy with, but we thought it was better to ship and iterate rather than get stuck on wanting to perfect everything out of the gate. Hopefully we can remove most of the boilerplate over time. That said, mutations in Relay are very powerful. This one does an optimistic update and handles inserting both the optimistic update and server response into the graph at the correct place. The fat query means that we can use the same mutation everywhere -- even across indifferent apps -- Relay only refetches the fields from the fat query that are used by the current view.
dvlsg 11y ago
Yeah... That's not something I would enjoy working with. It's a nice idea, I'll add my hopes that some of the boilerplate will get removed, but I can't see myself working with this on a production app any time soon.
tracker1 11y ago
Of course... but I think the guys at Facebook are right in that getting something out is better than just talking about it alone. Also, the community will probably come up with something that's a bit more lean/understandable in the end. Look at the progression of flux talks, to a desire for isomorphic js (with flux), to fluxible app from yahoo, flummox, fluxor, alt.. and finally we get Redux, which is actually quite lean and a fairly clean abstraction with almost no boilerplate. Though arguably you can do a lot of it with RxJS alone. I wouldn't surprise me that within two years we see something similar happen regarding Relay and GraphQL... for that matter, it wouldn't surprise me to see implementations that target specific database back ends easily. IE, you establish your object schemas, associate them to your db collections/tables, and establish filters based on client permissions. API/Service toolkits for data access using the protocol in question not the specific implementation necessarily.

by _mikz 11y ago

joelgrus 11y ago

Yeah, as someone who knows a fair amount of JS but almost nothing about React, that todomvc implementation does not particularly scream "this is the framework you want to learn".

yazaddaruvala 11y ago

One thing I think is a poor design choice on the part of the implementer of this example: Note: Not a design choice of Relay Is that each Mutation file is redundant. Each Mutation file corresponds one - one with a component file. I think it does a big disservice to React itself (specifically JSX), which advocates for collocating View and Template because of cohesion. Maybe its subjective.. and I can surely see the reasons for separating them, but I hope yungsters is reading this and collocates the mutations.

underwater 11y ago
Mutations are global, not view specific. They can be triggered by multiple views, and are smart enough to only refetch the data that is currently being shown. For Facebook we can write a single "like" mutation and share it between comments, posts, photos, etc.

underwater 11y ago

The API for mutations is one of the things we were least happy with, but we thought it was better to ship and iterate rather than get stuck on wanting to perfect everything out of the gate. Hopefully we can remove most of the boilerplate over time. That said, mutations in Relay are very powerful. This one does an optimistic update and handles inserting both the optimistic update and server response into the graph at the correct place. The fat query means that we can use the same mutation everywhere -- even across indifferent apps -- Relay only refetches the fields from the fat query that are used by the current view.

dvlsg 11y ago

Yeah... That's not something I would enjoy working with. It's a nice idea, I'll add my hopes that some of the boilerplate will get removed, but I can't see myself working with this on a production app any time soon.

tracker1 11y ago

Of course... but I think the guys at Facebook are right in that getting something out is better than just talking about it alone. Also, the community will probably come up with something that's a bit more lean/understandable in the end. Look at the progression of flux talks, to a desire for isomorphic js (with flux), to fluxible app from yahoo, flummox, fluxor, alt.. and finally we get Redux, which is actually quite lean and a fairly clean abstraction with almost no boilerplate. Though arguably you can do a lot of it with RxJS alone. I wouldn't surprise me that within two years we see something similar happen regarding Relay and GraphQL... for that matter, it wouldn't surprise me to see implementations that target specific database back ends easily. IE, you establish your object schemas, associate them to your db collections/tables, and establish filters based on client permissions. API/Service toolkits for data access using the protocol in question not the specific implementation necessarily.