Making Redux optional by offering custom data-storage locations

[antitoxic]

In my point of view apollo client is getting data and putting it in a plain object. Currently this object is redux' store. But I don't see a reason why it can't be just a plain object.

I imagine:

new ApolloClient({ storageHandler: function(newData) {....... return EntireStorage} })

I understand that redux is chosen for its nice devtools but ultimately apollo-client can work without it which will make it more flexible.

[abhiaiyer91]

So what about managing query state, mutations and results ? Have you read the code for the QueryManager? Why add more code to modify how those pieces of data work just to put your data in a diff object?

[stubailo]

@antitoxic I was thinking we could just do #255, that would get us to 95% of the goal.

Rewriting the whole library to allow plugging in something instead of Redux is probably not going to happen, but I was thinking refactoring to allow someone to build that very easily is a good goal!

[antitoxic]

@stubailo agreed.

@abhiaiyer91 do you require all people that submit issues to have read the
code? Not very friendly, not friendly at all.

On Mon, 30 May 2016, 02:56 Sashko Stubailo, [email protected]
wrote:

@antitoxic https://github.com/antitoxic I was thinking we could just do
#255 #255, that
would get us to 95% of the goal.

Rewriting the whole library to allow plugging in something instead of
Redux is probably not going to happen, but I was thinking refactoring to
allow someone to build that very easily is a good goal!

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
#256 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AAP9fFWL9R5-HxvChL_L86pkXOpmRCpVks5qGieYgaJpZM4IpYPE
.

[abhiaiyer91]

Lol. @antitoxic I think you read my comment the wrong way. I was merely poking you for more reasoning. I don't know if what you are suggesting is right or wrong, only to explore if you have thought deeply about what you are proposing.

[stubailo]

To be fair, QueryManager only plugs into redux in 2 ways: getState and dispatch. So if you can make a Redux shim on top of whatever data storage solution, then it should basically just work.

[antitoxic]

Lol. @antitoxic I think you read my comment the wrong way. I was merely poking you for more reasoning. I don't know if what you are suggesting is right or wrong, only to explore if you have thought deeply about what you are proposing.

Poking is much less preferred than asking "have you though about it in depth and in what scenario". Anyway:

So what about managing query state, mutations and results ?

What about them? Redux is just an immutable object exposing 2 main API points - dispatch and getstate.

Have you read the code for the QueryManager?

No.

Why add more code to modify how those pieces of data work just to put your data in a diff object?

Because redux is not the only thing existing for keeping state (mobx, SAM, etc..). I'm trying not to use redux and cut down on boilerplate in my apps. I need graphql and apollo seem like a good client (i'm evaluating this). However in order to hook Apollo store to my own logic of state-keeping I'm doing kind of hacky wiring - I'm launching a redux store, writing a reducer that listens for APOLLO_QUERY_RESULT and APOLLO_QUERY_STOP (undocumented stuff) and merging the data in my own state-keeping.

Which is making me wonder is it possible for me to keep only the actual data return from the graphql server in my state? Could I initialize Apollo client with the return of a query which looks like this:

{
  "query": "{ all: allFilms { totalCount } }",
  "data": {
    "all": {
      "totalCount": 6
    }
  }
}

instead initializing Apollo client with its store data object which is something like:

{
  "queries": {},
  "mutations": {},
  "data": {
    "ROOT_QUERY.allFilms": {
      "totalCount": 6
    },
    "ROOT_QUERY": {
      "allFilms": "ROOT_QUERY.allFilms"
    }
  }
}

So I'm opening #258

I was thinking we could just do #255, that would get us to 95% of the goal.

That's a good option.

[aleksandrenko]

You can go and just use graphql without apollo and do it like you want.
Or you can do an abstraction over the redux and making like you want ... I see no real issue there.
The project is still in it's infancy if you want i'm sure you can contribute the change you wanna see.

[antitoxic]

@aleksandrenko :) The issue has been closed. Mainly because @stubailo mentioned there is a limitation but it will be overcome when the normalization is extracted, which actually will solve a lot of other things and also, in the redux' issue about Relay there already community gathering to contribute to that.

"infancy" or "just make an abstraction" are not solutions. Any package could be abstracted out. I'm already doing abstractions with apollo client for other things (discussed in slack). I'm trying to keep them below the threshold which will cause me to switch to another package. If I have to continue abstracting or digging into TypeScript I will have no reason not to just butcher Relay and use it because its roadmap shows a lot of useful stuff coming. So I think submitting issues about apollo client and discussing problems is quite enough.