apollo-link-state
apollo-link-state copied to clipboard
Plain object type ?
Hi,
I'm wondering if there is anything like an Object type for plain objects, just like you have Int, String, Boolean ?
I'm storing a "session" field in my local apollo state, containing a loggedIn
boolean and a currentUser
object :
function mutate(cache, payload) {
cache.writeData({ data: payload })
}
const localState = {
resolvers: {
Mutation: {
updateSession(_, { loggedIn, currentUser }, { cache }) {
mutate(cache, {
session: {
__typename: 'Session',
loggedIn,
currentUser
}
})
return null
}
}
},
defaults: {
session: {
__typename: 'Session',
loggedIn: false,
currentUser: null
}
}
}
// Then :
withClientState({
cache,
...localState
})
I wanna mutate this state just after login :
const login = gql`
mutation($email: String!, $password: String!) {
login(email: $email, password: $password) {
_id
email
name
token
}
}
`
const updateSession = gql`
mutation($loggedIn: Boolean!, $currentUser: CurrentUser!) {
updateSession(loggedIn: $loggedIn, currentUser: $currentUser) @client
}
`
// ... then when submitting login form :
this.props.login({
variables: {
email,
password
}
}).then(({ data: { login } }) => {
localStorage.setItem('liveql-token', login.token)
this.props.updateSession({
variables: {
loggedIn: true,
currentUser: {
__typename: 'CurrentUser',
...pick(login, ['_id', 'email', 'name'])
}
}
})
})
Look at the mutation type def for $currentUser
: what type should I write ?
I found out that it works with any type, but I'm afraid that this behaviour will break in future release since there's nothing in the doc about this (or, is there ?)
Thanks a lot for your insight. Olivier
+1
Seems like there is one pull request adding Customs obj types. https://github.com/apollographql/apollo-link-state/pull/197
@ostrebler I was able to pass object as variable to mutation in this example https://codesandbox.io/s/ll7xvxq0xq
const setUserMutation = gql`
mutation setUser($user: User) {
setUser(user: $user) @client
}
`;
In this mutation, user is an object and it can have any number of properties and properties can be of any type. User type is not defined anywhere. so type checking for user will not be done.
@client
doesn't do any type validation, the contract is that you hand it a User
, but it doesn't need to understand what a User
is in order to pass it along. There is no runtime type validation being done by Apollo here If you gave it something incompatible, the crash will occur inside your setUser
resolver.
Anyway is there any serious plan in near future to store in @client any arbitrary data type? Like React component, any JSON data structure, function, etc...? Without this there is no way get rid of Redux which is capable to store really anything...
My intention is to have only one state manager, I like redux, but if we have Apollo I prefer make everything in Apollo ;)!
+1 on an arbitrary data type, for example a JSON dump of translations, which we don’t need to stringify and parse each time
+1
+1
+10000
+20181031
@hwillson Hello!
Anyway is there any serious plan in near future to store in @client any arbitrary data type? Like React component, any JSON data structure, function, etc...? Without this there is no way get rid of Redux which is capable to store really anything... My intention is to have only one state manager, I like redux, but if we have Apollo I prefer make everything in Apollo ;)!
Do you have a plan to integrate plain objects in the local storage?
This is something that would be incredibly useful. I'm implementing redux which seems like a lot of overhead for this one feature.
@hwillson has this been added to AC 2.5? thanks
I ended up storing the object as a JSON string. Seems a bit unnecessary and I wonder how sustainable that would be with large amounts of data but it's working fine for my current use case.