Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add redux-requests to Ecosystem.md #513

Closed
wants to merge 1 commit into from
Closed

Add redux-requests to Ecosystem.md #513

wants to merge 1 commit into from

Conversation

idolize
Copy link
Contributor

@idolize idolize commented Aug 14, 2015

redux-requests is a small Redux middleware and reducer I wrote to help avoid the problem of issuing duplicate HTTP requests.

Inspiration

I was inspired by using Marty's fetch API (in that it avoids duplicate HTTP requests), although I was not very satisfied with Marty's approach. Mainly: the Marty fetch API conflates to separate issues:

  1. Avoiding duplicate HTTP requests
  2. Checking local cache

Mart's fetch API uses the "id" to avoid duplicate requests (similar to the "meta.httpRequest.url" here), but it also has all that locally() remotely() stuff to try and manage the local cache, and unfortunately does not give a lot of control over invalidating the cache.

Why add it to the Ecosystem section?

I want this library to be very simple, and do one thing and one thing well (local cache management should be left up to the developer). And I think managing HTTP requests is a very common requirement for Redux developers.

[redux-requests](https://github.com/idolize/redux-requests) is a small Redux middleware and reducer I wrote to help avoid the problem of issuing duplicate HTTP requests.

#### Inspiration

I was inspired by using [Marty's fetch API](http://martyjs.org/guides/fetching-state/index.html) (in that it avoids duplicate HTTP requests), although I was not very satisfied with Marty's approach. Mainly: the Marty fetch API conflates to separate issues:

1. Avoiding duplicate HTTP requests
2. Checking local cache

Mart's fetch API uses the "`id`" to avoid duplicate requests (similar to the "`meta.httpRequest.url`" here), but it also has all that `locally()` `remotely()` stuff to try and manage the local cache, and unfortunately [does not give a lot of control over invalidating the cache](martyjs/marty#354).

#### Why add it to the Ecosystem section?

I want this library to be very simple, and do one thing and one thing well (local cache management should be left up to the developer). And I think managing HTTP requests is a very common requirement for Redux developers.

I also plan to [improve the API](idolize/redux-requests#1) in the near future (probably with an optional helper function).
@taylorhakes
Copy link
Contributor

@gaearon How are you deciding what gets on these lists? I know there are hundreds of 3rd party libraries that aren't listed.

It would be great if there were some sort of standards. Like high quality unit tests for all code and number of github stars? It gets crazy (and useless) if everything under the sun is listed.

@idolize
Copy link
Contributor Author

idolize commented Aug 17, 2015

@taylorhakes Yeah, some guidance here would be appreciated. Perhaps this package is too specific for what is intended with the Ecosystem section, but I think it would be great place to point users in the right direction for common use cases (which I personally believe includes managing HTTP requests).

(Also, I just added unit tests to the project :))

@idolize idolize closed this Aug 31, 2015
@gaearon
Copy link
Contributor

gaearon commented Aug 31, 2015

Hey, sorry for long time no response. Basically I want Ecosystem to be a bunch of stuff we use in the examples, and with fairly stable API. (I'd say redux-form is an exception because it's so popular already and solves a very important need.) I'm very busy now and have no time to play with redux-requests now. If it attracts a large following, we'll definitely add it.

@idolize
Copy link
Contributor Author

idolize commented Aug 31, 2015

@gaearon No problem! I actually closed this issue myself because I realized the real-world example already uses an isFetching concept that largely eliminates the need for this library. I totally understand your desire to keep the Ecosystem section small and focused, and this library was already added to awesome-redux anyway.

Keep up the good work!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants