Empty params in url cause Uncaught SyntaxError about react-easy-params HOT 7 CLOSED

v2.0.2 is out with the changes. Thanks for the tips, I think we found the best solution in the end 🙂

from react-easy-params.

Thanks for the crystal clear issue, it will be an simple fix.

I would rather have ?event= result in params.event === undefined instead of params.event === ''. The reason is that easy-params is preserving type information of query params and 'nothing' pairs best with undefined from all the types. Are you okay with this?

from react-easy-params.

Hmm I'm not too sure, and I've been thinking about this in my use case lately as well. I'm personally leaning towards it being an empty string, because then we can deliberately check on length if we want to deal with it like that in an "undefined" manner. And then it also allows the passing of empty strings deliberately... otherwise how would we deal with that?

Also if event was never passed in as a param, then params.event === undefined would be true.. which seems truer than if it was deliberately defined in the url.

from react-easy-params.

You are right about this. So this is my current proposal in a (url -> object -> url) format

• ?page=12&filter="apple" -> { page: 12, filter: 'apple' } -> ?page=12&filter="apple"
• ?page=12&filter=apple -> { page: 12, filter: 'apple' } -> ?page=12&filter="apple"
  • invalid type info in url for apple falls back to string
• ?page=12&filter= -> { page: 12, filter: '' }-> ?page=12
  • empty query params fall back to empty string, empty object props are not reflected in the url
• ?page=12&filter -> { page: 12 } -> ?page=12
  • Totally empty (no = sign) query params are not reflected in the params object.

It might seem a bit complex, but from a practical point this would be the best I think. Having empty strings in the params object is pretty common, since most values come from HTML input values. I would not reflect those in the query to keep things clean.

What is your opinion?

from react-easy-params.

In my use case, I think I might prefer:

?page=12&filter= -> { page: 12, filter: '' }-> ?page=12&filter=

Feel like behaviour should work both ways, as that might be the most expected outcome?

And also because I am using url params to represent inputs on the page which can be set to completely undefined (with a checkbox), or they can be deliberately kept empty to represent an empty string.

But that said, I understand where you're coming from too. I guess they're both correct in their own ways.

I'm only noticing now that you're trying to keep type information in the url structure as well- which I'm unsure about because of the established way that url params have worked in the past. I do see the value in it though.

But using that, my preference would then be:

?page=12&filter= -> { page: 12, filter: '' }-> ?page=12&filter=""

from react-easy-params.

Agreed, functionality is more important than nice query strings. So in the end I have this one implemented:

• ?page=12&filter="apple" -> { page: 12, filter: 'apple' } -> ?page=12&filter="apple"
• ?page=12&filter=apple -> { page: 12, filter: 'apple' } -> ?page=12&filter="apple"
• ?page=12&filter= -> { page: 12, filter: '' } -> ?page=12&filter=""
• ?page=12&filter -> { page: 12 } -> ?page=12

Let me know if you agree and I will merge and release it.

Another note: I am pretty sure about including the type info. I know it is a bit unorthodox, but it is really valuable in practice and I see no huge drawbacks because of it.

from react-easy-params.

Another note: I am pretty sure about including the type info. I know it is a bit unorthodox, but it is really valuable in practice and I see no huge drawbacks because of it.

Agreed. I definitely see the value in it, and since it should be contained in the current application- I don't see much of a problem with going against convention for such advantages.

The only issue I can think of is if someone in the future decides to use a different way to work with url params, then it might be slightly unexpected and they would have to implement the same type functionality themselves to be backward compatible (because URLs are static once copied and could have been saved in any number of places by users, or even the app itself).

In any case, what you've put out there now looks fine to me 🙂

from react-easy-params.