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

Provide a simple way to access the value of fetch.J #3

Closed
glossd opened this issue Oct 18, 2024 · 3 comments · Fixed by #10
Closed

Provide a simple way to access the value of fetch.J #3

glossd opened this issue Oct 18, 2024 · 3 comments · Fixed by #10

Comments

@glossd
Copy link
Owner

glossd commented Oct 18, 2024

The package's only way to access the fetch.J value is with the Raw() method, but it's not very useful, because you need to do a type assertion and type switch after it.
Method fetch.J#String() can be used to access the strings, but it's not intuitive.
Perhaps fetch.J could have multiple methods that do type assertation.
e.g.

j, _ := fetch.Unmarshal[fetch.J](`[1, 2, 3]`)
arr, ok := j.Array()
if !ok {
    // not array
    // arr is empty
}

But this will not solve the problem of panicking if j is nill

@glossd
Copy link
Owner Author

glossd commented Oct 19, 2024

fetch.J#Raw() won't panic on nil after version v0.2.0

@glossd
Copy link
Owner Author

glossd commented Oct 20, 2024

Tbh the type assertation is the very similar to the example.

	j, _ := fetch.Unmarshal[fetch.J](`[1, 2, 3]`)
	arr, ok := j.Raw().([]any)
	if !ok {
		panic("not an array")
	} else {
		fmt.Println("Array:", arr)
	}

And if someone needs a specific return type they should use that particular type on the function's generic type.
fetch.J.String is convenient because it doesn't return any errors, only one string.
E.g. right now If one expects a number from fetch.J.Q, then they can do the type assertation or calling fetch.J.String to do a string conversion.
I could add bunch of methods to fetch.J - Number, Boolean, Array, Map and return the default value, but I don't think the default value should represent nil values, it will cause problems.

@glossd
Copy link
Owner Author

glossd commented Oct 20, 2024

I wrote a function to safely convert all types

func JConvert[T bool | float64 | string | []any | map[string]any](j J) (T, bool) 

and compared all the type assertations

res, ok := j.Q(".category").Raw()(map[string]any)
res, ok := fetch.JConvert[map[string]any](j.Q(".category"))
res, ok := j.Q(".category").AsObject()

res, ok := j.Q(".tags").Raw()([]any)
res, ok := fetch.JConvert[[]any](j.Q(".tags"))
res, ok := j.Q(".tags").AsArray()

res, ok := j.Q(".price").Raw()(float64)
res, ok := fetch.JConvert[float64](j.Q(".price"))
res, ok := j.Q(".price").AsNumber()

res, ok := j.Q(".name").Raw()(string)
res, ok := fetch.JConvert[string](j.Q(".name"))
res, ok := j.Q(".name").AsString()

res, ok := j.Q(".sold").Raw()(bool)
res, ok := fetch.JConvert[bool](j.Q(".sold"))
res, ok := j.Q(".sold").AsBoolean()

I believe the winner is all the As* functions.

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

Successfully merging a pull request may close this issue.

1 participant