Releases · infinum/kotlin-jsonapix

Implement support for repeatable Error, Links and Meta annotations by @DrakslerT in #69
Fix encoding root meta,links and errors in XList models by @thisAAY in #64

Full Changelog: 1.0.1...1.0.2

Contributors

thisAAY and DrakslerT

Assets 2

06 Mar 09:49

thisAAY

1.0.1

ac76468

v1.0.1

Features:

Add custom types for Links and Errors in the generated wrappers, no need for casting
Add decodeJsonApiError that takes body error and decode it into the error class

Assets 2

12 Jan 15:48

thisAAY

1.0.0

75b60ab

v1.0.0

JsonApiX: First Stable Release

Enhancements:

Upgraded Kotlin to 1.9.20.
Updated Gradle to 8.2.0.
Migrated to JDK 17.

Bug Fixes:

Issue with HasOne/HasMany Annotations: Resolved a serialization issue where fields using HasOne or HasMany annotations were serialized by their field names, ignoring the @SerialName annotation. This previously forced users to match response property names with their casing (like snake case) as defined in the response. Now, fields are correctly serialized respecting the @SerialName annotation, allowing for more flexible and consistent naming conventions.

New Features:

Support for Nullable Primary Data.
Meta Support for relationships and resource objects.

Breaking Changes:

Introduction:
The latest updates to JsonApiX tackle the issue of losing access to root information in list scenarios, such as List<Person>. This problem arose from using the same Person class for both single objects and lists, leading to confusion, especially in accessing meta information. To improve this, we have implemented significant changes.

For Single Objects:
The previous direct use of Person in single object scenarios did not effectively encapsulate JSON API data.

Don't 🚫 (Old Way):

val person: Person = getPerson()
// Direct use of Person class without clear JSON API data encapsulation.

Do ✅ (New Approach):

val personModel: PersonModel = getPerson()
// Using PersonModel provides better structure and clarity.

For Lists:
Previously, using List<Person> led to ambiguity in meta access, making it difficult to determine whether operations like person.first().meta were accessing root or resource meta.

Don't 🚫 (Old Way):

val person: List<Person> = getPersons()
val meta = person.first().meta  // Ambiguity in meta access.

Do ✅ (New Approach):

val persons: PersonList = getPersonList()
val rootMeta = persons.rootMeta  // Clear access to root meta.
val resourceMeta = persons.first().resourceObjectMeta  // Specific resource meta access.