Replies: 19 comments 2 replies
-
I personally like the C option more. It's more concise and more readable |
Beta Was this translation helpful? Give feedback.
-
C option reminds me of feathers query which is readable |
Beta Was this translation helpful? Give feedback.
-
Option C more convient |
Beta Was this translation helpful? Give feedback.
-
Option C looks easier to understand without much context. |
Beta Was this translation helpful? Give feedback.
-
i think B and C option is user friendly and Nuxt can use both. |
Beta Was this translation helpful? Give feedback.
-
C option is more readable for me too. But if you have to do this :
|
Beta Was this translation helpful? Give feedback.
-
C is neat. Dot-notation is well-known (e.g. through lodash, feathers, mongo etc.) and easy to grasp 👍 |
Beta Was this translation helpful? Give feedback.
-
Any updates on this? |
Beta Was this translation helpful? Give feedback.
-
I personally like the C option too. I use GraphQL but I reckon that the B does not feel natural |
Beta Was this translation helpful? Give feedback.
-
C looks the best but what about something like exclude? const { data: user } = await useFetch('/api/user/100', {
exclude: ["createdAt", "updatedAt", "someUnnecessaryData", "info.like.createdAt"]
}) So that we only declare required data and exclude what we don't want. If we want, we can alternatively use Pick, too. |
Beta Was this translation helpful? Give feedback.
-
The C option is nice. But will it make harder to get the typings? |
Beta Was this translation helpful? Give feedback.
-
One problem that I see with the pick in |
Beta Was this translation helpful? Give feedback.
-
Hi, what about pick compatibility with a list result? By example :
|
Beta Was this translation helpful? Give feedback.
-
Worth considering how this could work for an array of data: const { data: users } = await useFetch('/api/user', {
pick: [
'*.name',
'*.info.url',
'*.info.like.status'
]
}) |
Beta Was this translation helpful? Give feedback.
-
Why not use it like in TS interface like this example: const { data: user } = await useFetch('/api/user/100',
pick :{
user: {
name: string,
info: {
url: string,
like: {
status: boolean,
},
},
}
} |
Beta Was this translation helpful? Give feedback.
-
i like C and more: |
Beta Was this translation helpful? Give feedback.
-
I like C as well. Looks clean and readable |
Beta Was this translation helpful? Give feedback.
-
Love C. Transform looks great too. It could be an alternative to Option C for more specific use-cases e.g. picking a lot of deep nested data. |
Beta Was this translation helpful? Give feedback.
-
I like option C but would suggest to replace the notation with json pointer: // C.1: deep pick following the conventions to a T
const { data: user } = await useFetch('/api/user/100', {
pick: [ '/name', '/info/url', '/info/like/status' ]
})
// C.2 deep pick without leading slash
const { data: user } = await useFetch('/api/user/100', {
pick: [ 'name', 'info/url', 'info/like/status' ]
}) this has the advantages of being a broadly known notation + standard and the implementation can use one of the many existing packages (: |
Beta Was this translation helpful? Give feedback.
-
The idea originally proposed by @xtoolkit in #1389, we could allow picking nested keys from the response. (at the time of writing this, it is only possible to specify top-level keys for
pick
)Example response:
Expected transformed data:
We have two options to achieve this:
pick
API to support deep keys router path /index throw 404 not expected to / #1389transform
optionI'm thinking that while the initial idea of introducing
pick
in #721 and improving in #1389 was an initiative, it will become soon opinionated since there is no single API method that covers all different use cases unless we do an overengineering to build an alternative of lodash directly insideuseFetch
or nuxt3 and bound to it. Alternatively, we could create a new unjs library to make a filtering API with better typing support and make it opt-in to use via thetransform
option.(
createFilter
can be auto imported but tree shaken and added to bundle by usage)Appendix: Some ideas for extended
pick
API:Beta Was this translation helpful? Give feedback.
All reactions