Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pagination with Lenses: Replacing the verbose deep object spreading #14

Closed
wants to merge 2 commits into from

Conversation

Projects
None yet
3 participants
@rwieruch
Copy link
Member

commented Apr 3, 2018

Since there is no best practice yet how to update paginated data in Apollo client (Is there? [0][1] If there is one, please tell me! :)), I replaced the deeply nested object spreading with Ramda's lenses. It makes the updating of the deeply nested immutable data structure concise again.

[0] As I read somewhere else, Apollo comes with its own kind of ImmutableJS library? I would love to avoid using yet another immutable library in the future. That's why I didn't use it in this project in the first place.

[1] As I know, the updateQuery property will go away eventually. (Am I correct?) I would hope that there is some way to use the Apollo client/cache directly in the pagination update mechanism.
Then it would be possible to use readQuery/writeQuery or even readFragment/writeFragment (for deeply nested structures) on the client instead. It should be similar to the update option in my opinion. Not sure about the plans of the Apollo team, but maybe it becomes merged with the update option eventually.

I would be curious what you all think about this PR :)
cc @peggyrayzis

@dyst5422

This comment has been minimized.

Copy link

commented Apr 3, 2018

I personally prefer the deep spread syntax. I think that lenses for a case where they are so short lived are an unnecessary abstraction that makes understanding the code more difficult. Now if you had tens of places where you were using the same lenses... or perhaps all over your application, I can understand the appeal.

Also, I would argue that the standard practice for non-mutative object updates IS the spread syntax, even in deeply nested cases.

@rwieruch

This comment has been minimized.

Copy link
Member Author

commented Apr 4, 2018

Hey @dyst5422 Thank you for your opinion! 👍 I agree that the spread syntax is more common for people and intuitiv to read on first sight. But when it comes to deeply nested immutable data structures, where you have to keep all the above levels of data intact, the spread syntax tends to be very verbose. I actually had people complaining about this syntax regarding this repository. That's why I was looking for an alternative approach.

I would love to find an alternative for it without using yet another ImmutableJS derivate library :)

@dyst5422

This comment has been minimized.

Copy link

commented Apr 4, 2018

I think simple immutability-helpers (https://www.npmjs.com/package/immutability-helper) is the most common utility for doing this, though the syntax is a bit heavy handed.

const updated = update(this.state, {
  somefield: {
    innerField: { $set: 'value' },
  },
}),

I'm partial to https://github.com/kube/monolite as a typescript user.

const updated = (this.state, state => state.somefield.innerfield)('value')

I think if you can use the language native options though, you are going to be better off long term.

@coryhouse

This comment has been minimized.

Copy link

commented May 17, 2018

I'd recommend trying immer.

@rwieruch

This comment has been minimized.

Copy link
Member Author

commented May 18, 2018

Hey @coryhouse Excited to see you here! I heard about immer, but never tried it myself. I will check it out 👍

@coryhouse

This comment has been minimized.

Copy link

commented May 18, 2018

@rwieruch - Yesterday, I spent my entire flight from London to the US going through your excellent post on Vanilla GraphQL. Superb. Thanks so much for sharing! 👍

@rwieruch

This comment has been minimized.

Copy link
Member Author

commented May 18, 2018

Wow, thank you @coryhouse If you want to dig deeper into it, there is another follow up post about transitioning to Apollo Client.

However, at the moment, I am writing up an article on how to build your own simple GraphQL client in React. Publishing this one, I hope to get more people jumping on the GraphQL bandwagon to contribute to the ecosystem :) It's a new field, but I hope there will be more players on this field in the future! :)

Thanks again for your feedback! Means a lot to me :)

@coryhouse

This comment has been minimized.

Copy link

commented May 21, 2018

@rwieruch - Excellent! Thanks for the links. Looks like I have more reading to do! :)

@rwieruch rwieruch closed this Nov 1, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.