-
-
Notifications
You must be signed in to change notification settings - Fork 278
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
Type definition improvements. #288
Comments
I was going to create an issue related to Pagination, but this seems like the right place to add. My static type checker is unhappy with interface IOrderList extends Array<IOrder> {
nextPageParameters?: string,
previousPageParameters?: string,
} Alternatively maybe a response interface that could contain any of the typed array responses so as not to need to add a list type for every endpoint with a list api call? |
I had a similar issue with paginated results on products. Something as simple as a generic this
Then change the return types for all paginated responses (not all are currently implemented according to the docs as of today).
In addition there is currently no support in the types for bigInt. It appears as though you are handling sending and retrieving the data with json-bigint but the types sending data are defined as number which will be a problem in the near future. A native bigint type was added in Typscript 3.2 but targets the native esnext bigint type and would not be compatible with the bigInt library used currently.
|
I think it could be beneficial to have something similar to;
I assume the TS Compiler will struggle with this recursive type definition a bit, but something similar came to mind. |
I don't use TypeScript so any help is appreciated. Feel free to open PRs to improve the type definitions. |
No original work here. It´s basically what @YourWishes suggests in MONEI#288. Could and should be extended throughout the api for lists. Usage example: ``` const orderList: IOrder[] = []; const orderStatus = 'any'; let params = { status: orderStatus, limit: 250 }; do { const orders = await shopify.order.list(params); for (const order of orders) { orderList.push(order); } params = orders.nextPageParameters; } while (params !== undefined); console.log(`after while loop len:${orderList.length}`) ```
I also noticed quite a few type definitions are out of date.
I'm happy to submit a pull request when I get a chance, but I was wondering if this would impact users on a different API version? and how we would go about making that distinction... |
I've been working with the API and I have a few ideas for type definition improvements, I'll submit a few pull requests when I can find some time as I've made a few of these already.
Fixes
ICarrierService - Needsid:number
as part of the interfaceImprovements to types
/collections/create
return essentially eitherISmartCollection | ICustomCollection
product.list
currently acceptsparams?:any
Additions
WebhookRequestMap - Interface for lookup of WebhookTopic to an interface of webhook request. e.g. WebhookTopicproducts/create
can have request of IProduct. This will require additions to what can be given by a webhook, e.g.ICart - Interface for cart webhook callbacksIDeleteItem - Interface for a webhook callback for deleted item, generally{ id:number }
ICarrierRequest - Interface for carrier request callbacks, will also require ICarrierItem and ICarrierAddressICarrierResponse - Interface for carrier responses to Shopifydiscount_applications
accessScope.list
Improvements to structure
I guess there's also a case to be made for converting the project from Javascript to Typescript, if this is something that is being considered.
The text was updated successfully, but these errors were encountered: