While structure of many GraphQL entires often take on a edge/node hierarchy this structure is not always desirable and in many cases is not used. And while documentation today is far better than it was 6 months ago and continues to improve, I have yet to find a method of properly implementing updates/optimizedUpdates that do not depend upon the Edge/Node structuring.
The issues I run into stem from the lack of a LinkedRecord, as none exists from the payload. So what exactly am I passing then to the ConnectionHandler to update the UI? I think the updater is a great feature and would like to take advantage of it.
This has been questioned before by another on SO, I have yet to see any solutions to address it here nor there unfortunately.
Was able to solve my problems after doing a lot of reading and playing around in the inspector. This is definitely a documentation issue, but once you get the hang of it, the updater is really great.
@scotmatson could u comment how did u solve this?
or could u send a PR to improve the docs?
Sure @sibelius
I'm not using the optmistic updater, simply because I don't like the thought of updating the UI with potentially false data so this is directed specifically at the updater.
I think there are a lot of cases where people are not using the Edge/Node hierarchy with React Relay and examples to address this have not been adequate. It seems any time I run into trouble it is due to this scenario. Case in point, using createRefetchContainer expects a user to have infinite scrolling/cursor-based pagination but I had to play around with it to devise a more traditional solution that utilized limit/offset-based pagination.
Improvements in the documentation to highlight the flexibility of Relay as not just being a Facebook solution but a client-side GraphQL solution will help keep people contributing and adopting this platform. TBH this had me considering refactoring and moving to Apollo for awhile.
That said, the incredibly simple solution to use the updater is as follows.
updater: store => {
const newSubmission = store.getRootField('uploadFileFromForm');
const root = store.getRoot();
const allSubmissions = root.getLinkedRecords('allSubmissions');
const newAllSubmissions = [...allSubmissions, newSubmission];
root.setLinkedRecords(newAllSubmissions, 'allSubmissions');
And the schema that goes with it,
const mutation = graphql`
mutation CreateSubmissionMutation(
$submitterEmail: String!,
$clientName: String!,
$dataURL: String!,
$filename: String!,
$comments: String,
$zenNumber: String
) {
uploadFileFromForm(
submitterEmail: $submitterEmail
clientName: $clientName
dataURL: $dataURL
filename: $filename
comments: $comments
zenNumber: $zenNumber
) {
id
zenNumber
submitterEmail
clientName
basename
extension
comments
status
sha256
}
}
`;
This implementation is being used in an internal data store that is accessible through a corporate VPN, so authentication and user identity are not features we wanted at this time. It has a simple schema, no viewer layer, no edges, no nodes. In this mutation the user is uploading through GraphQL (to do this I had to convert the file to a dataURL, which would be a another great example to put in the documentation).
Relay can certainly get far more complex, and I love that about it, but sometimes you don't need that complexity.
On a side note, the backend in this case is Java-GraphQL, which is interesting to use, I'm a bit more comfortable with Graphene, so it was nice to see another way of implementing server-side solutions.
Most helpful comment
Sure @sibelius
I'm not using the optmistic updater, simply because I don't like the thought of updating the UI with potentially false data so this is directed specifically at the updater.
I think there are a lot of cases where people are not using the Edge/Node hierarchy with React Relay and examples to address this have not been adequate. It seems any time I run into trouble it is due to this scenario. Case in point, using createRefetchContainer expects a user to have infinite scrolling/cursor-based pagination but I had to play around with it to devise a more traditional solution that utilized limit/offset-based pagination.
Improvements in the documentation to highlight the flexibility of Relay as not just being a Facebook solution but a client-side GraphQL solution will help keep people contributing and adopting this platform. TBH this had me considering refactoring and moving to Apollo for awhile.
That said, the incredibly simple solution to use the updater is as follows.
And the schema that goes with it,
This implementation is being used in an internal data store that is accessible through a corporate VPN, so authentication and user identity are not features we wanted at this time. It has a simple schema, no viewer layer, no edges, no nodes. In this mutation the user is uploading through GraphQL (to do this I had to convert the file to a dataURL, which would be a another great example to put in the documentation).
Relay can certainly get far more complex, and I love that about it, but sometimes you don't need that complexity.
On a side note, the backend in this case is Java-GraphQL, which is interesting to use, I'm a bit more comfortable with Graphene, so it was nice to see another way of implementing server-side solutions.