apollographql / apollo-feature-requests Goto Github PK
View Code? Open in Web Editor NEWπ§βπ Apollo Client Feature Requests | (no π please).
License: Other
π§βπ Apollo Client Feature Requests | (no π please).
License: Other
Migrated from: apollographql/apollo-client#424
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
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.
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#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
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#621
createItem
mutationloadMoreItems()
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.
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 },
Migrated from: apollographql/apollo-client#1152
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.
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#1812
Migrated from: apollographql/apollo-client#2052
Migrated from: apollographql/apollo-client#3565
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
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:
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:
TypeError: Failed to fetch
(I would classify this as a "Communication Failure")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
Perhaps also relevant
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".
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.
Migrated from: apollographql/apollo-client#3231
Migrated from: apollographql/apollo-client#3128
Migrated from: apollographql/apollo-client#899
Migrated from: apollographql/apollo-client#3024
Migrated from: apollographql/apollo-client#2987
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
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#3414
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.
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.
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#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
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.
Migrated from: apollographql/apollo-client#2860
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#2222
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.
Migrated from: apollographql/apollo-client#2359
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!
Carry over from
Migrated from: apollographql/apollo-client#1564
Migrated from: apollographql/apollo-client#2735
Migrated from: apollographql/apollo-client#2262
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)
Migrated from: apollographql/apollo-client#2723
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.
README currently has broken "classify" link to:
https://github.com/apollographql/apollo-client/CONTRIBUTING.md#classification
Migrated from: apollographql/apollo-client#2222
Migrated from: apollographql/apollo-client#585
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.
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.
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. πππ
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google β€οΈ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.