Suggestion: Optionally return array of results about redux-object HOT 12 CLOSED

1. I can add another function to fetchAll objects of desired type
2. Supporting array of ids is a nice feature, I don't mind implementing it soon.

Sounds good?

from redux-object.

I pulled a fork and implemented this here:
https://github.com/SirLamer/redux-object/blob/master/src/redux-object.js

I was going to test it for a bit and then submit as a PR. This also implements the "eager loading" from my other suggestion and removes the "no remote lazy loading" error which blocks some usage cases.

I implemented it with the same build() function taking all input types, but the arrayed response certainly could be a separate method.

from redux-object.

Cool, I just reviewed your commits and everything seems quite good. Cross-env is a nice addition as well :) Feel free to finish your stuff and I would be very happy to merge that.

My 5 cents:
Instead of removing "no remote lazy loading" I would suggest to add another option, which would suppress this error and extend error message in a way: "you can disable this error by providing following option". This would help people to better understand that library doesn't support certain things and also to join the discussion on the GitHub if they have some ideas, how things can be improved.

from redux-object.

Should you be holding their hands, though? Including that message increases the package size by a lot.

For instance, I had a near identical experience of confusion when I couldn't figure out why Vue was failing to retrieve the relationship values. It turned out to be because you use a getter property to (local) lazy load the values when called on as the default. I came here, read the code and learned about it. Should you be including error messages for this case as well?

I'm just cautioning that you're making an assumption about how the package will be used because of feedback from one guy.

from redux-object.

Somewhat unrelated... can I ask how you are auto-building the dist folder for the repo? I am just trying to learn this detail and I see you are doing that.

I do have TravisCI integrated in to my fork of this project and it runs and passes, I just cannot determine how you are causing the /dist folder to be included in the the package distribution while absent from the project due to its .gitignore exclusion. Thanks. ;-)

from redux-object.

I am lazy :) I run npm run build locally after travis reports that everything fine and follow it with npm publish. .npmignore controls, what should be published on npm and .gitignore — what on github. Travis uses this file https://github.com/yury-dymov/redux-object/blob/master/.travis.yml to build the stuff and run tests for all supported environments

from redux-object.

OOOOHHHHHHHHHH okay... I just thought you have more wizardry going on than that. ;-)

That affects how one would take a fork and use their own branch in another project, however I'll just remove the ignore condition on my forked copy for now.

from redux-object.

So do you want the 'links' loading error back in before I submit a PR?

from redux-object.

Yes but I want also to have an option to suppress this error. I can do that myself after you submit your PR though :)

from redux-object.

Okay I will keep it in. I'll have to include a suppression option in order to continue to be able to use this myself.

Between this and the eager loading, this is very near making the case for converting this to a class object which allows for global/default options as constructor input. ;-)

from redux-object.

Makes sense. We might also some time later provide networkInterface as a constructor option and implement remote loading.

from redux-object.

Closed via #9

from redux-object.