What makes Riverpod specifically made for network request

[stephane-archer]

• What advantages would there be in tightly coupling Riverpod to an HTTP client rather than maintaining its flexibility, allowing users to adapt it to their specific implementations or use cases?

• Are there any features or functionalities in Riverpod that are inherently network-specific and wouldn’t make sense for other types of resources?

[rrousselGit]

Riverpod isn't tightly coupled to HTTP. They are just the main focus.
Kind of like how Flutter is mostly about mobile/material, but support other stuff too.

Strictly speaking there's nothing that's HTTP specific, as you can always think of a use case outside of HTTP for them.
But many features are designed with HTTP in mind, like AutoDispose or the upcoming offline persistence. Its fairly implied the name of the second feature. "Offline persistence" implies some "Online' state

[rrousselGit]

Riverpod talks about HTTP directly, because many users have asked for concrete examples.
I wanted to add really specific usage, instead of abstract ones, to satisfy those requests.

You'll also find that there are lots of HTTP related feature requests.

[stephane-archer]

@rrousselGit, is there anything Riverpod could do if it was tightly coupled to HTTP, for example, by shipping with its own HTTP client?

Offline only means "not accessible" for a resource, it is useful for http requests but not only.

I'm looking forward to test this "Offline persistence" feature but I will probably use it with SMB shared folders or USB sticks, not http request. the fact that Riverpod is not coupled to http allows your users to use it in other ways that might surprise you.

http state is a tricky and popular resource to manage, so it pushes Riverpod in the right direction but I think the separation between Riverpod and the type of resource it manages allows great flexibility.

[rrousselGit]

is there anything Riverpod could do if it was tightly coupled to HTTP, for example, by shipping with its own HTTP client?

A lot, yes.
For starter, it enables Riverpod to react to the status code of the HTTP request, and to read the HTTP header.

This can enable things like "detect when the connection failed" or "determine for how long a provider should be cached based on max-age in the header"

http state is a tricky and popular resource to manage, so it pushes Riverpod in the right direction but I think the separation between Riverpod and the type of resource it manages allows great flexibility.

That's not at risk. There's no plan to have Riverpod only work with HTTP.

[stephane-archer]

For starter, it enables Riverpod to react to the status code of the HTTP request, and to read the HTTP header.
This can enable things like "detect when the connection failed" or "determine for how long a provider should be cached based on max-age in the header"

I wouldn't consider status code or HTTP header to be reliable. APIs have often their interpretation of these values. it's not uncommon to receive a 404 instead of a 400. I think it's great that the users have control over how they want these values to be used. the users can give max-age to Riverpod if it knows it and knows it is reliable. allowing the broader flexibility for HTTP and other use case. You often can't change the API and only use it.

[rrousselGit]

We're talking about making it simple to do the right thing (so a properly designed API). This doesn't remove the ability for folks to do stuff by hand, at the cost of more work.

[stephane-archer]

@rrousselGit In my experience properly designed APIs are not so common sadly.

Considering a properly designed API this is more about simplicity for the users rather than something that can not be achieved without coupling Riverpod and an HTTP client?

The separation allows great flexibility but might be more verbose for the user. Is this your primary motivation regarding including an HTTP client in Riverpod?