You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm writing an API SDK and would love to use Valinor to map requests/responses from JSON to objects and vice-versa. Mapping responses is trivial - specify a type, use JsonSource and you're done. Mapping requests is not - there are no mentions of mapping objects to JSON in the documentation, nor do I see any tests or code to support this use case.
Taking the README example, this is what I mean:
finalclass Country
{
publicfunction__construct(
/** @var non-empty-string */publicreadonlystring$name,
/** @var list<City> */publicreadonlyarray$cities,
) {}
}
finalclass City
{
publicfunction__construct(
/** @var non-empty-string */publicreadonlystring$name,
publicreadonlyDateTimeZone$timeZone,
) {}
}
$json = <<<JSON { "name": "France", "cities": [ {"name": "Paris", "timeZone": "Europe/Paris"}, {"name": "Lyon", "timeZone": "Europe/Paris"} ] }JSON;
$result = (new \CuyZ\Valinor\MapperBuilder())
->mapper()
->map(
Country::class, // specify a type for generics or other non-native typesnewCountry('France', [
newCity('Paris', 'Europe/Paris'),
newCity('Lyon', 'Europe/Paris')
]),
\CuyZ\Valinor\Mapper\Source\Source::json()
);
assert($json === $result);
I suppose this is a somewhat common use case. Most of the time when you're trying to statically type your code, you want it to be typed for both client-server and server-client communication. In case of an SDK, that's converting request DTOs to JSON to send to an external API and converting responses from JSON to DTOs. In case of an HTTP API, that's converting request JSON to DTOs and response DTOs back to JSON.
It makes sense to me that a single library would consistently (i.e. using the same mappers, the same formats, the same naming rules, the same annotations/attributes and the same logic) convert objects both to and from other formats. At least that's how other languages' competitors do it - say Java's serializer libraries all allow bi-directional conversion.
How feasible is this to implement? This issue is forcing me to use one of the overall worse alternatives which I would love not to be doing. I can help with the implementation, but only if there's a real chance for it to be merged. That looks like a good chunk of work that I really don't want to go to waste :)
Thanks.
The text was updated successfully, but these errors were encountered:
Hey.
I'm writing an API SDK and would love to use Valinor to map requests/responses from JSON to objects and vice-versa. Mapping responses is trivial - specify a type, use
JsonSource
and you're done. Mapping requests is not - there are no mentions of mapping objects to JSON in the documentation, nor do I see any tests or code to support this use case.Taking the README example, this is what I mean:
I suppose this is a somewhat common use case. Most of the time when you're trying to statically type your code, you want it to be typed for both client-server and server-client communication. In case of an SDK, that's converting request DTOs to JSON to send to an external API and converting responses from JSON to DTOs. In case of an HTTP API, that's converting request JSON to DTOs and response DTOs back to JSON.
It makes sense to me that a single library would consistently (i.e. using the same mappers, the same formats, the same naming rules, the same annotations/attributes and the same logic) convert objects both to and from other formats. At least that's how other languages' competitors do it - say Java's serializer libraries all allow bi-directional conversion.
How feasible is this to implement? This issue is forcing me to use one of the overall worse alternatives which I would love not to be doing. I can help with the implementation, but only if there's a real chance for it to be merged. That looks like a good chunk of work that I really don't want to go to waste :)
Thanks.
The text was updated successfully, but these errors were encountered: