Working with slightly more "structured" input data #214
lukeredpath
started this conversation in
Ideas
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
A lot of the examples for this library are focussed on parsing strings as input data into more structured output. However, as demonstrated by the
URLRouting
library'sURLRequestData
you can also parse slightly more "structured" inputs into better structured outputs. I was wondering if there might be a use case for some kind of general "key path" parser for parsing off properties of a struct. This is effectively whatURLRouting
does but in its case, it ships with a bunch of domain-specific parsers that work with specific properties ofURLRequestData
.One use case might be dealing with JSON APIs that return objects in a way that makes sense for constructing JSON schemas but doesn't translate nicely into a well designed and strongly typed domain within your code (which might involve enums and generics etc that don't map nicely to the JSON structure). If you've ever tried to do any kind of advanced JSON decoding in Swift you'll find you hit the limitations of
Codable
very quickly and end up with a spaghetti of pseudo-parsing code within your custom codable implementations.An alternative approach would be a two-step process where you parse the JSON into less structured types that reflect the JSON schema itself and then use those types as input into a parser that transforms it into your more structured domain. The nice thing about this is converting your domain types back into JSON would simply be a case of using your parser to print back into the unstructured types and then encoding the unstructured types back into JSON.
Example
Let's say we have this JSON schema returned from our API:
There's a few ways we could model this in Swift - a generic
Value<T>
although that might be a bit too flexible. If there are limited number of types supported, we might choose to model this as an enum instead:Now, instead of trying to write some kind of messy custom Codable implementation, we're going to first parse the JSON into a less structured value that more accurately represents the JSON schema, which can be done with minimal boilerplate and gives us something we can use as input:
KeyPath parsing
Now all we need to do is write a parser of
(JsonType) -> SomeValue
. Without having to write completely custom parsers to deal with this, it would be nice if we could generalise this approach by parsing off a mutable property of a struct by referencing its key path. I've managed to come up with something like this so far (it needs more work I think):We can now write our parser:
Alternatives
Would some version of this key path parser be useful in the library, or would we be better off writing a completely custom domain-specific parser instead? Writing a custom parser feels like it would be a bit more work although arguably the final result could end up looking a bit clearer:
So now the parser becomes:
Beta Was this translation helpful? Give feedback.
All reactions