#190-FetchInteger: Fix

[artiodev]

#190
Handles int and bool types when returned as string map value.

[yxxhero]

@artiodev thanks so much. could you add some tests?

[artiodev]

@yxxhero Done

[yxxhero]

@mumoshu WDYT?

[mumoshu]

@artiodev Thanks a bunch for the pull request!
This looks well aligned with vals' design, where it wants any fetched values to be rendered as strings, so that the values before(ref+...) and after the vals rendering are both strings. It's great in that regard.

But, is this what you originally wanted in #190?

Here, I was wondering if you wanted:

Suggested change

	ResultBool: "true"
	ResultInteger: "1"
	ResultBool: true
	ResultInteger: 1

rather than the string representations of the original values.

If necessary, we could support both options, perhaps via feature toggling envvars and or ref URL params. Just wanted to confirm your goal and intention to start!

Thanks in advance for your cooperation 🙏

[artiodev]

Hello @mumoshu,
You're right! This is the result I want, but I think is quite difficult to have.
ResultBool: "true" ResultInteger: "1" ResultBool: true ResultInteger: 1
Maybe it could be change the Lookup function using Generics type?

However at the moment this solution could be enough for me.

Thanks!

[mumoshu]

Hey @artiodev! Thanks for confirming!

From vals' design perspective, I believe that both work if each is enabled only in an opt-in manner.

Would you like it, if it looked like this:

fetched value	ref URL param	result
1		error (because vals expects string by default)
1	as=int	1
1	as=string	"1"
true		error (because vals expects string by default)
true	as=int	error (because we won't define true->int conversion or vice versa)
true	as=bool	true
true	as=string	"true"

We initially implement as=int and as=bool only because I suppose, in many cases, you don't need to turn anything into strings with vals. Put another way, we won't have as=string until it's absolutely necessary.

Does that make sense to you?

cc/ @yxxhero

[yxxhero]

Hey @artiodev! Thanks for confirming!

From vals' design perspective, I believe that both work if each is enabled only in an opt-in manner.

Would you like it, if it looked like this:

fetched value ref URL param result
1 error (because vals expects string by default)
1 as=int 1
1 as=string "1"
true error (because vals expects string by default)
true as=int error (because we won't define true->int conversion or vice versa)
true as=bool true
true as=string "true"
We initially implement as=int and as=bool only because I suppose, in many cases, you don't need to turn anything into strings with vals. Put another way, we won't have as=string until it's absolutely necessary.

Does that make sense to you?

cc/ @yxxhero

yeah. it's better.

[artiodev]

yeah, This solution is even better

[elkh510]

hi
any chance to get this marge ?

[aslafy-z]

@elkh510 This is WIP, it currently has a breaking change behavior that needs to be moved as a opt-in behavior.