Add models with everything nullable and methods for that and fields param to the request.

[MiniSuperDev]

Hi, as mentioned in this issue #46 where it uses _fields to decide which properties to get.

1. It will nice if you add the List<String>? fields as param in the requests:

ListPostRequest(
 fields: ["id","categories"],
)

I think there is not conflict name, but maybe you want a convension for wordpress global parameters that start with _.

2. Add a nullable models and methods that return that.

We know that post.listRaw and similar methods already exist, but you need to create the decoder.

It would be nice if there was a method that returned an instance of the model with everything nullable.

In this way the user avoids creating models for simple cases.

Use case:
I want to delete several posts from x categories
I'm only interested in the Id and categories, no other props because will be slowly and use more network data.

I would have to create a model with only this 2 props and the logic to decode..

If you already have a method that returns everything nullable, simply use the ! operator.

Before:

final rawResponse = await client.posts.listRaw(
  ListPostRequest(
    extra: {
      '_fields': 'id,categories',
    },
  ),
);

final response =
    rawResponse.asResponse<List<WordpressPost>>(decoder: (data) {
  final jsonList = data as List<dynamic>;
  return jsonList.map((e) {
    // Here we need to create a nullable model or
    // a special model that have only this 2 fields
    return NullablePost.fromJson(e as Map<String, Object?>);
  }).toList();
});

final nullablePosts =  response.asSuccess().data;
final id = nullablePosts.first.id!;
final categories = nullablePosts.first.categories!;

After

final response = await _wordpressClient.posts.listNullable(
  ListPostRequest(
    fields: ["id", "categories"]
  ),
);
final nullablePosts =  response.asSuccess().data;
final id = nullablePosts.first.id!;
final categories = nullablePosts.first.categories!;

Well... the post.listNullable and NullablePost are the names that come to mind, maybe you have better prefix and suffix than nullable in mind.

Thanks

[ArunPrakashG]

Hey @MiniSuperDev , First of all, thank you for using the library and sharing your feedback, it helps a lot!

I do not agree on creating a model class in the library itself with all nullable fields. I feel like your use case is covered as expected when using the listRaw request method. An additional way to enhance the experience is by adding a separate parameter for the fields and other global parameters of WordPress.

So take this as an example:
You required author, id, content.
So you send a listRaw request, with the fields parameter filled with these keys.
You define a model for just these parameters or, you can use getField method from the WordpressRawResponse class for easier access with error handling, or better, you could directly access the individual fields by using the [] operator.
eg:

WordpressRawResponse response = { .... }
int firstAuthorId = response[0]["author"];

I think this solves both simple cases and advanced cases.

As for the nullability of fields in existing models, i think i may have to revisit it again; on a quick look i think some more fields could be marked as nullable.

[ArunPrakashG]

Hi @MiniSuperDev , the response class changes are published on v8.4.6. Do give it a try and let me know!

[ArunPrakashG]

Hey @MiniSuperDev , is there any update on this?