feat(unions): Add support for simple arrays #1571
Conversation
scyzoryck
force-pushed
the
union-properties-array
branch
from
7d8dcba to
7a8b0e9
Compare
|
@goetas do you have moment to take a look at it? |
There was a problem hiding this comment.
code wise this looks good.
I see that unions are a rabbit hole. :(
in the non-unions, using @Type("array") is possible but discouraged, mainly because there is no easy way to define the content of the array. The type array works mainly because json has the knowledge of some types such as int or bool.
I can see that many people might want to have the ability to use array as type....
| @@ -60,9 +60,9 @@ public function __construct(DriverInterface $delegate, ?ParserInterface $typePar | |||
| private function reorderTypes(array $types): array | |||
| { | |||
| uasort($types, static function ($a, $b) { | |||
| $order = ['null' => 0, 'true' => 1, 'false' => 2, 'bool' => 3, 'int' => 4, 'float' => 5, 'string' => 6]; | |||
| $order = ['null' => 0, 'true' => 1, 'false' => 2, 'bool' => 3, 'int' => 4, 'float' => 5, 'array' => 6, 'string' => 7]; | |||
There was a problem hiding this comment.
the more I look at this the more I think that it would make sense to use the order used in the code (by looking at how the union types are declared) rather that having our own way of sorting.
is there a reason for not doing it?
There was a problem hiding this comment.
I see 2 risks:
- the order might be forced by Code Formatters, so coding style might impact Serializer behavior. Not sure if such linter exists.
- It might be confusing why
int|stringgives different result thanstring|int.
Moved into Union Types - code/tests improvements #1576 as an idea for the future.
|
In general yes, it is missing a lot of edge cases. But from the bright side, it looks like our community got involved more into the package life 🥳 |
Add support for array (de)serialization in Union types. Only basic one. For the future there might be needed some some refactoring as the code debugging is terrible here :D