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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Why are parameters not strongly typed ? #13

Closed
2 tasks done
orevial opened this issue Nov 19, 2021 · 5 comments
Closed
2 tasks done

Why are parameters not strongly typed ? #13

orevial opened this issue Nov 19, 2021 · 5 comments
Assignees
Labels
enhancement New feature or request

Comments

@orevial
Copy link

orevial commented Nov 19, 2021

馃憻 Reproduction steps

Not really a bug but I was wondering if there was a specific reason to not add strongly typing to all services parameters ?

Examples for database service :

Future<models.DocumentList> listDocuments(
      {required String collectionId,
      List? filters,
      int? limit,
      int? offset,
      String? orderField,
      String? orderType,
      String? orderCast,
      String? search})

where filters list is not typed, or :

Future<models.Document> createDocument(
      {required String collectionId,
      required Map data,
      List? read,
      List? write,
      String? parentDocument,
      String? parentProperty,
      String? parentPropertyType})

where data, read and write are not typed either.

Same goes for certain responses that simply return a Response or sometimes just an untyped Future.

This makes the SDK really hard to use as we have to always refer to the documentation and hope that stuff we are looking for is defined there.

馃憤 Expected behavior

As a developer, I would expect following typing for examples above:

Future<models.DocumentList> listDocuments(
      {required String collectionId,
      List<Filter>? filters,
      int? limit,
      int? offset,
      String? orderField,
      String? orderType,
      String? orderCast,
      String? search})

where filters list is not typed, or :

Future<models.Document> createDocument(
      {required String collectionId,
      required Map<String, dynamic> data,
      List<Rule>? read,
      List<Rule>? write,
      String? parentDocument,
      String? parentProperty,
      String? parentPropertyType})

馃憥 Actual Behavior

Many methods are not strongly typed as explained in introduction.

馃幉 Appwrite version

Different version (specify in environment)

馃捇 Operating system

MacOS

馃П Your Environment

Tested on AppWrite 0.11.0 with following Dart packages:

  • appwrite: ^2.0.3
  • dart_appwrite: ^1.0.2

(similar problems for Dart or Flutter package).

馃憖 Have you spent some time to check if this issue has been raised before?

  • I checked and didn't find similar issue

馃彚 Have you read the Code of Conduct?

@orevial orevial added the bug Something isn't working label Nov 19, 2021
@orevial orevial changed the title Why parameters are not typed ? Why are parameters not strongly typed ? Nov 19, 2021
@eldadfux
Copy link
Member

The new Dart SDK with structured response models is now available: https://dev.to/appwrite/announcing-appwrite-dart-sdk-20-50a1

Strong typed DB filters will be introduced with the release of Appwrite 0.12

@lohanidamodar lohanidamodar added enhancement New feature or request and removed bug Something isn't working labels Dec 26, 2021
@lohanidamodar lohanidamodar self-assigned this Dec 26, 2021
@lohanidamodar
Copy link
Member

@orevial Thank you for your issue. We are aware of this. As our SDKs are generated using Swagger specs using our sdk-generator, there are certain limitations at the moment. But we are working to improve typing for Map and List param as well

@TheMaverickProgrammer
Copy link

How is this going? I second this ticket.

@lohanidamodar
Copy link
Member

@orevial @TheMaverickProgrammer Most of the issues have already been resolved in the latest version of the SDK. If you still find some params missing proper type definition (except the data attribute in the createDocument method for now), please let us know and we will try to resolve it as soon as possible.
Thank you.

@lohanidamodar
Copy link
Member

Closing this issue as it should already be resolved. If you still have the issues feel free to reopen.

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

No branches or pull requests

4 participants