-
-
Notifications
You must be signed in to change notification settings - Fork 7
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
Namespaced Schemas per Context #48
Comments
Here's an example, in the embed context there is no "content" field (wp default). Context: Embedhttps://techcrunch.com/wp-json/wp/v2/posts/2258167/?context=embed Context: Viewhttps://techcrunch.com/wp-json/wp/v2/posts/2258167/?context=view I propose something along the lines of namespace WP_REST_API
namespace EDIT {
export interface Post {
// ...
}
// ...
}
namespace EMBED {
export interface Post {
// ...
}
// ...
}
namespace VIEW {
export interface Post {
// ...
}
// ...
}
} |
Yeah I came to the same realisation myself in #40. I haven't made any plans to tackle it though. |
Ah, I see, so this is basically a duplicate of #40.Sorry, I'll close this. |
Hi there 👋
thanks for setting up this package, I've extensively been working with wp-types. In fact, I'm currently finishing up a proper typescript wordpress-api-client, which builds upon wp-types.
So far it has been a blessing, but I have the issue that the typings sometimes are not 100% accurate (relates to #33):
Typings of REST responses include fields of all contexts as optional parameters – even if a response in the "view" context definitely does not contain certain fields of the "edit" context, the typings of responses in both contexts are the same – the context-specific fields are simply typed as optional, for both.
I will add an example to better illustrate the problem.
on a side note: I'm not going to open another issue for this, it's just a question: are you planning on including wp-api request DTOs, as well?
✊ keep it up
The text was updated successfully, but these errors were encountered: