You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Picking the package, I took time to read the docs to know if I should encode the content passed to $path.
Please let me know if I am wrong, but I found no information on the subject.
From the Motivations page, I believe this feature was part of the package.
After a quick dive into the source, I found that it was indeed the case.
I believe it should be mentioned clearly in the docs somewhere.
Should I make a PR for this kind of change (in the future)?
The text was updated successfully, but these errors were encountered:
Maybe it is just me, I am still a junior in frontend and unfamiliar with all the commons...
But genuinely, after a video about this problem recently, my first question was "Do I still need to encode my params? It does not say otherwise".
But having seen the features from Tanstack, I had the intuition it was builtin in the solution, just not mentioned.
One line somewhere to clearly state it is handled would be enough.
But, as a newbie, to be clear, I would add a bullet in the Motivations page, in your How does next-typesafe-url solve these problems? and also add a section in Groundwork to reflect the addition to your claims.
Picking the package, I took time to read the docs to know if I should encode the content passed to
$path
.Please let me know if I am wrong, but I found no information on the subject.
From the
Motivations
page, I believe this feature was part of the package.After a quick dive into the source, I found that it was indeed the case.
I believe it should be mentioned clearly in the docs somewhere.
Should I make a PR for this kind of change (in the future)?
The text was updated successfully, but these errors were encountered: