I think that this value chart maps out a more useful default for the lazy prop:
Method
Default value
GET, HEAD, OPTIONS
false
POST, PUT, PATCH, DELETE
true
Although consumers may be unaccustomed to a prop having a "dynamic" default based on other prop values, I believe the learning curve would be small. And developers would likely appreciate it a lot.
The reason behind this change is that "read" requests frequently occur on a component mounting, while "write" requests are typically the result of user interaction.
Prior art: React Apollo. Queries (which map to GET requests) aren't lazy by default, whereas mutations (which correspond to any write requests) are lazy by default.
Cons
In the real world, applications often cannot fit all of the data that they need to send in URL query parameters for GET requests. Because of this, it is common to see POST requests being used for reads. If a user is developing an application that uses both GET and POST for reads, then the different default behavior of lazy for these two methods could potentially be confusing/frustrating.
I personally think it is worth the tradeoff, but I will leave that up to you.
I think that this value chart maps out a more useful default for the
lazyprop:falsetrueAlthough consumers may be unaccustomed to a prop having a "dynamic" default based on other prop values, I believe the learning curve would be small. And developers would likely appreciate it a lot.
The reason behind this change is that "read" requests frequently occur on a component mounting, while "write" requests are typically the result of user interaction.
Prior art: React Apollo. Queries (which map to GET requests) aren't lazy by default, whereas mutations (which correspond to any write requests) are lazy by default.
Cons
In the real world, applications often cannot fit all of the data that they need to send in URL query parameters for GET requests. Because of this, it is common to see POST requests being used for reads. If a user is developing an application that uses both GET and POST for reads, then the different default behavior of
lazyfor these two methods could potentially be confusing/frustrating.I personally think it is worth the tradeoff, but I will leave that up to you.