Lazy loading for remote objects is not supported about redux-object HOT 8 CLOSED

This might be a good example https://github.com/apollographql/apollo-client/blob/master/src/transport/networkInterface.ts.

The idea is that instead of hard-coding certain networking implementation, you define a protocol, which is used by redux-object to emit network requests. So it would call a certain method (something like performNetworkRequest, with should return a promise). All redux-object knows is that the method has this name and it should return the promise. Implementation of this method is done by the user depends on required business logic (for example, authentication token should be added, the endpoint should be built and so on and so forth) and passed along as a build parameter for example.

from redux-object.

@gnapse this is a very tough question.

Unfortunately, I am not actively using this at the moment (a couple of projects are live and don't use this feature, and professionally, I had to switch back to iOS recently). Nevertheless, I am still interested in maintaining but I don't believe much that it is possible to develop something good if you are personally not using it. Being said, you would have to drive this thing but I can help with some ideas, docs update, sample updates, and so on.

My preferences: this should be a feature and not a breaking change. Regarding implementation details, I would prefer to mark it as an experimental feature, so we can have some time to test it in a wildlife and let it naturally to evolve. Feel free, to implement it in a way that would work best for you.

from redux-object.

@yury-dymov I created a library (in the context of a private project, but I may eventually be released once it gets more mature) that works as a json-api reducer for redux, and this library internally relies on both redux-object and json-api-normalizer to do its job. It uses json-api-normalizer upon receiving any successful response from the backend, to store the normalized version of it in the store (emitting the appropriate actions that are handled by a reducer). Then it exposes a couple of convenience functions buildObject and buildList which are basic wrappers around redux-object's build function.

I was seriously considering forking build from this repo, but mostly to modify the internal buildRelationship so it can accept an option, perhaps called lazyLoading, which, if true, would make the built object's relationship property to be a function, that would return a promise and launch the api requests to fetch it. Something like this:

const company = build(store, 'companies', '1', { lazyLoading: true });
const employees = company.employees().then((relationships) -> {
  // Do whatever you want with relationships here, or even use this callback
  // only as a signal that they are loaded in the data store.
});

Also, if the data is already there, this function would still return a promise that resolves immediately, so access to related data is seamless regardless of if it was loaded already or not.

I'm not sure though yet, if that would be a good model, so suggestions are welcome. I understand that I can't ask this library to provide that, because it does not have, and it shouldn't have, all the parts necessary to perform ajax requests and everything, hence my suggestion below.

I'd very much prefer to keep using build off this repo, so perhaps a good option would be that build would accept a config option that would make it return the built object with relationship properties being a promise that would resolve if the data is there, and would be rejected if the data is not there.

Perhaps something like this:

const company = build(store, 'companies', '1', { lazyLoading: true });
const employees = company.employees().catch((link) => {
  // fetch them yourself and return the ajax promise here
  return fetch(link);
});
employees.then((employees) => {
  // Here you get the employees regardless
});

Note how you pass the link to the related objects to the rejected promise catch callback.

What do you think?

from redux-object.

Hey, @gnapse

This sounds very interesting :)

For the lazy loading, I like a lot NetworkInterface concept, which is used in both Relay and apollo-client.

I guess we can either pass NetworkInterface implementation class instance as a build parameter or perform a global setup somehow beforehand. In this case, if we would face a lazy loaded object, we can check if build function has an access to such NetworkInterface and if yes, follow your logic. Of course, we still may control if we would like to have such behavior with a configuration option.

I don't mind to extend redux-object in this way. It would be still quite lightweight as we only need to define NetworkInterface protocol and extend existing package only a little bit.

Let me know if you agree with such approach, and I will help with pleasure.

from redux-object.

@yury-dymov Can you link to more info online about what this NetworkInterface concept is, as well as what to this apollo-client you mention? I don't know anything about any of these, so I'm not following your suggestions entirely. I know what Relay is, but I haven't used it, so I'll dig around a bit. But it would be nice if you can link to some resource about this NetworkInterface concept at least. That name itself is not very google-friendly, too generic to find anything about this particular use.

from redux-object.

Got it, looks good. I'm all for it. How exactly do you envision these concepts applied to build? Can you sketch out a sample use of build with this feature implemented?

from redux-object.

Ok, I'll sketch something and run it by you.

from redux-object.

This feature will be out of scope for this library to keep things simple and lightweight.

from redux-object.