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

Support predefining types #210

Open
goodwin64 opened this issue Sep 11, 2019 · 8 comments
Open

Support predefining types #210

goodwin64 opened this issue Sep 11, 2019 · 8 comments

Comments

@goodwin64
Copy link

(related to #201)

Consider 2 examples:

const search1 = '?phoneNumber=%2B380951234567&subtopicId=2&topicId=1';
const result1 = queryString.parse(search, {
  parseBooleans: true,
  parseNumbers: true,
});

const search2 = '?phoneNumber=a%2B380951234567&subtopicId=2&topicId=1';
const result2 = queryString.parse(search, {
  parseBooleans: true,
  parseNumbers: true,
});

console.log('result1', result1);
// {
//   phoneNumber: 380951234567,
//   subtopicId: 2,
//   topicId: 1,
// };
console.log('result2', result2);
// {
//   phoneNumber: 'a+380951234567',
//   subtopicId: 2,
//   topicId: 1,
// };

In the 1st example, "+" sign (%2B escaped) is ignored thus reducing to the number parsing, which is not what it supposed to be.

The main goal is to keep parsing numbers for parameters which values starts on the number and parse as plain string otherwise.

Does it look feasible to make a PR on this or should I not use parseNumbers option in that case?

@sindresorhus
Copy link
Owner

sindresorhus commented Oct 2, 2019

+380951234567 is a valid number though. You would expect '-380951234567' to be parsed as a number, right? That being said, I agree it's not a optimal behavior.

Regardless of what we decide to do with this, we should better document the behavior of what's considered a number.

// @yaodingyd

@yaodingyd
Copy link
Contributor

What should be the optimal behavior? Here it's using Number() function to convert to number.

@goodwin64
Copy link
Author

I meant if I store the number "+123" in the URL and then I parse it with "parseNumbers" option I get lost the plus sign (+) and the parsed value will be just "123".

Meanwhile I want to store some number-like parameters in URL so removing the "parseNumbers" option is not the right solution for me.

@goodwin64
Copy link
Author

goodwin64 commented Oct 3, 2019

So when I prepend the value with the prefix "a" it's just a workaround not to lost the plus sign :)

"a+123" get parsed as is and then I just skip the "a" letter, which causes a lot of questions what is "a"

@sindresorhus
Copy link
Owner

I think some kinda schema support here could solve the ambiguity. You could then explicitly define the type for this one key. See: #228 (comment)

@iagolaguna
Copy link

iagolaguna commented Feb 14, 2020

Hi, I would like to help you to solve this issue, I was thinking about you said about schema.

What do you think about something like this

const search2 = '?phoneNumber=a%2B380951234567&subtopicId=2&topicId=1';
const result2 = queryString.parse(search, {
    parseBooleans: true,
    parseNumbers: true,
    schema: {
        phoneNumber: String, // StringConstructor
    }
});

and when you are trying to parse always check the schema and see if have a property with the same name of the URL param, with this you will be able to parse correctly any primitive type.

and in the lib, maybe we can pass down the propertyName of the value that will be parsed to make something like

function parseValue(value, options, propertyName) {
const { schema } = options;
const type = schema[propertyName];
// if have type use in the function, if not keep the default behaviour 
}

@sindresorhus
Copy link
Owner

I would prefer something like this:

const search2 = '?phoneNumber=a%2B380951234567&subtopicId=2&topicId=1';
const result2 = queryString.parse(search, {
    parseBooleans: true,
    parseNumbers: true,
    types: {
        phoneNumber: 'string',
        subtopicId: value => Number(value)
    }
});

The type could also be a function to let the user handle the converting it from a string to a custom type. Don't forget that it also needs to be able to handle arrays.

@sindresorhus
Copy link
Owner

If anyone wants to work on this, see the feedback given in #249.

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

Successfully merging a pull request may close this issue.

4 participants