apollographql / apollo-feature-requests Goto Github PK

Migrated from: apollographql/apollo-client#3771

Currently you have to use watchQuery to be able to use optimistic UI. Having optimistic UI to work with subscription would be nice. However the watchQuery function doesn't accept a subscription (only query). The subscribe method doesn't listen to cache changes.

Description:

I have a centralized component that services other components in my application besides rendering its own UI (e.g. UndoManager). The render method of my centralized component renders and <Mutation/> with it UI rendered by the render prop. However I would like to have the ability to add the mutate callback to the central components state, so that I can add it to the components state and have it available for external calls from other components in my application.

I need to call setState() outside of the render function, otherwise react complains. I could just do a workaround by updating a variable on this or create a wrapper component reverting to the HOC approach, but a cleaner solution would be for the <Mutate/> component to provide onMount() and onUnMount() callbacks which are invoked on the underlying lifecycle event, so that I could setState in the proper place.

Proposed Solution:

add onMount((mutate) => this.setState(..)) and onUnMount(() => this.setState(..)) to <Mutation/>

Does not change current behavior

In general I think that Apollo team should see which callbacks on <Query/> and <Subscription/> could additionally be made accessible through onMount() and onUnMount() props.

Migrated from: apollographql/apollo-client#1541

I think that request aborts and other things from migated topics like options borrowed from Redux-Saga, for example takeLatest (cancelling previous request if there is new pending) could be easier implemented once race lands into Apollo Links, like mentioned in https://www.apollographql.com/docs/link/composition.html

Scenario

• Fetch 10 items in a list, sorted by Oldest first
• Do a createItem mutation
• The mutation update inserts the new item at the end of the list
• Scroll down and loadMoreItems() gets called:

loadMoreItems: () => {
  const lastId = items[items.length - 1].id
  return fetchMore({
    variables: { after: lastId, first: 5 },

Problem behavior: At this point the lastId is the id of the new item, and the server returns no more items.

Desired behavior: Whereas I want to be calling fetchMore() with the id of the last item that was fetched from the server in the listItems() query (or in a previous fetchMore()).

This issue is not specific to Oldest sort order—it happens when any item is added to a list in which, given the current sort order, it falls after the current cache items.

Possible solution

There are a number of ways in which this could be solved. One is being able to determine whether an item was inserted by a mutation update, for instance with the addition of an __addedByMutationUpdate field, in which case loadMoreItems() would be fixed by:

import { findLast } from 'lodash'

const findLastItemNotAddedByAMutationUpdate = (items) => {
  return findLast(items, item => !item.__addedByMutationUpdate)
}

loadMoreItems: () => {
  const lastId = findLastItemNotAddedByAMutationUpdate(items).id
  return fetchMore({
    variables: { after: lastId, first: 5 },

README currently has broken "classify" link to:

https://github.com/apollographql/apollo-client/CONTRIBUTING.md#classification

Hi awesome Apollo team,

Currently, the docs for Apollo Client API is a sub set of the docs for React/Angular/Vue integration. It is also not comprehensive and lacks a dedicated guide with proper vanilla JS examples without integration with view layers. This is very important especially for library authors who want to build on top of Apollo Client API, and also for those who do not want to use the integration parts.

Therefore, I would like to suggest to dedicate 1st-citizen docs for Apollo Client API with a proper guide and examples, similar to what you have for Apollo Server.

Thank you for your fantastic framework and work!

Migrated from: apollographql/apollo-client#3414

Migrated from: apollographql/apollo-client#2052

Migrated from: apollographql/apollo-client#585

GraphQL Server is returning the "null" value if a given property in the query is not in the response. This is so far ok - but if you use ES6 destructuring you will go into trouble.

So it would be nice to have an easy-to-use override of all responses from the query before these will get into the store. With this function it would be able to easy override "null" with "undefined".

How to reproduce the issue:

const data = proxy.readQuery({query: gql`{ notInTheStore }`})

Intended outcome:

Returns null

Actual outcome:

Throws an error: ERROR Error: Uncaught (in promise): Error: Can't find field notInTheStore on object (ROOT_QUERY) undefined.

Migrated from:
apollographql/apollo-client#2007
apollographql/apollo-client#1542

I have the need to be able to set the channel name dynamically based on the subscription parameters / variables. Currently the subscription resolver looks like

subscribe: () => pubsub.asyncIterator(<calculated_channel_id >)

I would like the method signature to be alligned more with other resolvers, but at least provide access to the context and variables:

subscribe: (variables, ctx) => pubsub.asyncIterator( function(variables, ctx) )

This Feature Request should not change the current behavior for subscription resolvers that use hard-coded channel names.

Migrated from: apollographql/apollo-client#424

Migrated from: apollographql/apollo-client#3397

This isn't so much a feature request as an observation that the IntrospectionFragmentMatcher seems to work without providing types explicitly, which runs counter to the documentation. Details in the original issue, which has been closed.

Migrated from: apollographql/apollo-client#424
and
Migrated from: apollographql/apollo-client#2460
and
apollographql/apollo-client#307

Please vote with 👍, if this feature request important for you.

Migrated from: apollographql/apollo-client#2735

Migrated from: apollographql/apollo-client#3386

I'd like to display different error messages to the end user depending on the type of error that's occurred; I've split them into these general categories:

• Communication Failure (can't talk to the server at all)
• Outage (The server is responding with something like a 504)
• Exception (The server responds with 500, or a 400 we don't know how to handle, or parsing the results raises an error, etc - basically, it's a bug, there's no actionable steps for the user, and we need to fix it)

Apollo's networkError / graphQLErrors distinction is really throwing a wrench in this because I've seen networkError used to handle any of the following cases:

• Fetch's painfully generic TypeError: Failed to fetch (I would classify this as a "Communication Failure")
• Query is rejected by the server with a 400 because the query has unsupported fields (I would classify this as an "Exception")
• "the application attempted to write an object with no provided id but the store already contains an id of [ID] for this object" (basically I forgot to query an object's unique ID and the cache doesn't know what to do with that - I would classify this as an "Exception")

There's really not a way I can single out the "communication failures" because, at least coming from Fetch, they're too generic, and I want "generic" and unexpected errors to be classified as Exceptions.

Suggested resolution:

If possible, I would like networkError to be used exclusively for network errors, as the name suggests - other kinds of errors could go into linkError or something like that.

Version

• [email protected]

Perhaps also relevant

• apollographql/apollo-client#2492

Migrated from: apollographql/apollo-client#3396:

I have a lot of large read-only queries that I am using fetchPolicy='no-cache', but through the vue-apollo bindings the getCurrentQueryResult function is used in certain contexts that do a lot of unnecessary work / exceptions being thrown and caught that show up in my profiling analysis.

At this line, it should be safe to no execute this.dataStore.getCache().read(...) if observableQuery.options.fetchPolicy = 'no-cache' since our store will never contain this query.

Probably short-circuiting the function and returning: return maybeDeepFreeze({ data: {}, partial: true }); would be best.

https://github.com/apollographql/apollo-client/blob/9ac90e0c1729d11a41663c9a7032200369f3305d/packages/apollo-client/src/core/QueryManager.ts#L976

Migrated from: apollographql/apollo-client#2987

Decide what pieces of data should be mutable and document it. Eg results from read* or the first arg to updateQuery.

Migrated from apollographql/apollo-client#3199 (comment)

Hi,

Not every suggestion is a feature request. Where should the other suggestions of improvement go? Maybe change this repo's name to "Suggestions" or "Ideas"?

There is no note of this new repo anywhere in the apollo-client repo at first glance. So, I'll bet any new contributors will be posting suggestions there, as is "normal" and the dev team be constantly chasing them to make their suggestions here. And I'll bet even if you make note of this in the README.md of the core repos, the devs will still falsely report suggestions in the core repos. Having to scold them into doing the right thing the next time, in the end, is unnecessary work and friction.

This "separation" of ideas from issues can be done smartly with Github's labeling feature in the core repos. That is what labeling was meant to do. Yes, it means a little bit more work for the dev team to categorize and prioritize and filter issues to find what they are looking for. But in the end, it will be less work than trying to uphold the rule of having contributors go to a different repo to add their ideas. It's a poor change IMHO. Sorry..... 😄

Scott

Migrated from: apollographql/apollo-client#2712

Quoting myself:

About the potential behavior changes... in what kind of use-cases would it be preferable to watch the store, instead of watching the result for a public API ? From the consumer point of view it seems that the difference between store and result is very thin if not non-existent.

If there aren't any strong use-cases for a public API to watch the store, then I'd say the behavior should change to always watch the results instead. Making the store even more transparent for the consumer for most common use-cases.

This discussion should be about whether watchQuery should watch the store (as of now) or the result, and also whether it should notify subscribers with obsolete and incorrect results when notifying of loading status.

It seems @hwillson was open to changing this behavior in next major release.

If they mean different things, it would be helpful to introduce that somewhere in the docs. If they mean the same thing, let's standardize on one term? Store is more familiar than cache to Reduxers. But outside of Redux context, I think store has more of a persistent connotation than cache (it's where you store data—like, permanently), and Apollo's store is usually not persistent.

Migrated from: apollographql/apollo-client#2723

Migrated from: apollographql/apollo-client#2563

It's generally an antipattern to use exceptions for ordinary control flow. They're more difficult to reason about; they incur multiple expensive stackwalks throughout their lifecycle; and, most importantly, they're annoying as hell when debugging.

The final point is most relevant here. Many JavaScript app frameworks include top-level exception handlers, which then require you (as a developer) to break on all exceptions when debugging an issue. (The top-level handlers handle all exceptions, which makes breaking on unhandled exceptions useless.) Unfortunately, Apollo Client presently relies upon exceptions to signal cache misses, which can be quite noisy for these debugging scenarios.

Carry over from

apollographql/apollo-client#819

Migrated from: apollographql/apollo-client#899

Migrated from: apollographql/apollo-client#161

I'm not 💯% sure, but maybe it should be implemented in both, Apollo Client for error messages and react-apollo to show them on field and/or form base.

Please vote with 👍, if this feature request important for you.

For example, when I'm using WatchedMutationLink to update the cache instead of the update function, I'd like my optimisticResponse objects to go through the link.

https://github.com/haytko/apollo-link-watched-mutation/issues/4

Migrated from: apollographql/apollo-client#3340

Intended outcome:

I wanted to pass a ssr-generated initial state to InMemoryCache. Something like this:

new ApolloClient({
  uri: '...',
  initialState: window.__APOLLO_STATE__,
});

Actual outcome:
The current apollo-boost client only accepts the cacheRedirects option for the InMemoryCache

Version

• [email protected]

I want to send a request to this server via Apollo and get a query :

const client = new ApolloClient({
link: new HttpLink({
uri:'http://mfapat.com/graphql/mfaapp/'}),
cache: new InMemoryCache()

})

const FeedQuery = gql
query{
allFmr{
fmrId,
name,
studio,
bedRm1,
bedRm2,
bedRm3,
bedRm4
}
}
` But I'm facing this error message:

Unhandled (in react-apollo:Apollo(FMRScreen)) Error: Network error: Unexpected token < in JSON at position 1

at new ApolloError (http://localhost:8081/index.bundle?platform=android&dev=true&minify=false:109336:32)
at ObservableQuery.currentResult (http://localhost:8081/index.bundle?platform=android&dev=true&minify=false:109447:28)
at GraphQL.dataForChild (http://localhost:8081/index.bundle?platform=android&dev=true&minify=false:103192:66)
at GraphQL.render (http://localhost:8081/index.bundle?platform=android&dev=true&minify=false:103243:37)
....

But I can easily open "http://mfapat.com/graphql/mfaapp/" in my browser and get a query. Does anyone know where the problem is?

Intended outcome:

Actual outcome:

How to reproduce the issue:

Version

• apollo-client@

Migrated from: apollographql/apollo-client#1812

Migrated from: apollographql/apollo-client#3231

Migrated from: apollographql/apollo-client#3715

I propose adding the 3rd party apollo link to the docs as discussed in the original issue, or adding that 3rd party link to the core

This features comes from the now closed issue: apollographql/apollo-client#3564. I'll paraphrase the original author as he's quite precise in its request:

I've got stuck with a rather common situation with mutations and cache.
In my case I have a query tasks(filters: $filters). It gets fetched and cached several times with different filters. Then I run a mutation createTask(input: $input). It looks like I can't update my cache manually in this case because I don't know for which filters I should update the cache unless I implement all task filtering logic inside of the update function. Additionally I've got another query that fetches the number of tasks opened which should also be updated.
I've seen some issues in the repo and stackoverflow regarding the problem, but no solution found except for running client.resetStore(). Still it clears all the data and makes the app fetch it all right after. Possible solution that I see is providing a method for partial cache clear based on query names (may become a more abstract one keeping the idea), so that clearing tasks would clear all the tasks cache variants.

Migrated from: apollographql/apollo-client#1564

Hi all! Once summer vacations are out of the way, we'll be hashing out the Apollo Client 3 roadmap. We have an approximate idea of the new features / functionality we want to get in place for AC 3 (based on open feature requests from the community, breaking changes required to work with new versions of 3rd party libraries, and a few additional ideas of our own). Once we have a draft of the v3 roadmap ready, we'll share it here for feedback. It's going to be an exciting release! 🚀

UPDATE (2020-04-27): The most up to date roadmap can be found here. We're aiming for an AC 3 RC in May 2020.

Ported from: apollographql/apollo-client#585

It'd be great if we had support for custom scalars in Apollo Client. A pretty crucial feature would be for custom scalars to be provided by native code. apollo-link-state users would particularly benefit from this.

The canonical example is Date objects (from ISOString or Unix Timestamp "raw" formats), but it would be valuable to vend other complex objects from a local object pool in certain circumstances beyond just dates.

In the original thread there was a reference that maybe a library-provided semi-static list of common scalars might be an acceptable compromise, but immediately, people would want momentjs dates instead of JS Dates.

Migrated from: apollographql/apollo-client#2484

Currently, the InMemoryCache is a great start, but people often need more control. A specific feature that is desired is the ability to have a defined serialization format, so that things like apollo-cache-persist could strip certain "sensitive" data before serializing to disk. Other examples of data that may not be wanted in a disk cache: "App Navigation State"

It would be great if we could have documentation for custom cache implementations to rely on, so variants of the InMemoryCache can be used.

Migrated from: apollographql/apollo-client#3128

Migrated from: apollographql/apollo-client#1152

Migrated from: apollographql/apollo-client#2222

Migrated from: apollographql/apollo-client#2222

Coming from relay, I miss possibility to delay sending of the mutation to the server and apply only optimistic update until there is good time to commit it to server. Typical use case is filling the form. Now its necessary to keep the input values in the component state (or apollo store, but separately from server schema). Idea of including debounce options within apollo was already discouraged.

There was similar discussion in Relay, which also had similar direction that debouncing should not go to the core. But there was good api for it in relay classic and its also somewhat possible with modern api

Using this api its possible to quickly updating UI changes (like writing in input) and commit or rollback at the end. With every input change I could basically apply new optimistic change and rollback the previous one and at the end just commit the last version.

To make more clear how the api could look like - having either option for store.mutate method or separate method (like store.localMutate) that would return object with rollback and commit methods.

Have not spent time with apollo client internals yet, so any feedback on how this is desirable and feasible to implement with current code base are hugely welcomed.

Looking forward to discussion.

• has-reproduction
• feature
• docs
• blocking
• good first issue

Migrated from: apollographql/apollo-client#2359

Migrated from: apollographql/apollo-client#2262

Migrated from: apollographql/apollo-client#3565

Migrated from: apollographql/apollo-client#2860

Migrated from: apollographql/apollo-client#621

Migrated from: apollographql/apollo-client#3024