Extracting nested types by path - internal.flatRefs ?

[cimak]

I’m not sure if this is a question or a feature idea…

Given a main type and a path, I’d like to extract (runtime) a nested type (or an array of them):

const User = type({
    name: 'string',
    contact: {
        address: {
            city: 'string',
            street: 'string',
            zipCode: /^\d{2}-\d{3}$/,
        },
    },
});

const Main = type({
    // ...
    user: User,
});

For the simple example above, this would work:

const checkZip = Main.get('user').get('contact').get('address').get('zipCode');
console.log(checkZip('12-345'))

However, this won’t work if user is optional, e.g., User.or('null'), or if:

    user: User.or(ForeginUser), // let’s say ForeignUser has a different "zipcode" format

My problem is perfectly solved by Main.internal.flatRefs, but since I’m using internal, which isn’t even mentioned in the documentation, I understand that I should expect this field or data type may disappear or change drastically in the future?

[ssalbdivad]

1. Likely the best option is some variant of get that ignores the possibility of keys being missing.

Feel free to create an issue for that. FYI you can pass multiple args directly to get like get("user", "contact") (only up to 3 though atm IIRC).

2. Generally, this is an anti-pattern, although there are valid use cases, especially for dynamic transformations. It's usually best to define a standalone type if you need to reference a specific prop in more than one place.

3. flatRefs is technically not stable but it is unlikely to change.

[cimak]

Generally, this is an anti-pattern, although there are valid use cases, especially for dynamic transformations.

I think the option to traverse ArkTypes at runtime might seem like an anti-pattern at first, but it actually opens up great opportunities for extensibility or integration with existing solutions.
I see potential use cases, for example, in a <form> library where you pass in a single (Ark)Type describing the form and know exactly what you’ll get on submit - while still allowing field-level runtime validation and displaying per-field error messages (e.g. next to an input).

Another example is a problem I’m currently dealing with: at our company, we use a custom framework for application state management that's based on paths. Unfortunately, until now, state mutation operations haven't been validated in any way, which sometimes leads to hard-to-track issues.
ArkType comes to the rescue and is perfect thanks to its super convenient syntax (love it! ❤️), but we're missing a way to operate on dynamic paths, which in some cases come from the backend.
The workaround right now is to validate the entire application state (rootType) on each state change, but it’s far from ideal performance-wise. That’s why I’m looking for a way to extract an (Ark)Type based on a dynamic path, which would allow me to validate/transform just the relevant part of the state tree.

flatRefs is technically not stable but it is unlikely to change.

Sounds like a great candidate to become an "official" feature? ;) Just make it publicly accessible instead of hiding it under internal, and give it a mention in the docs. If the library internals ever change, you could just maintain its current structure - It feels like a symbolic change, but I think it would significantly increase the library’s flexibility.
What do you think about it?

[ssalbdivad]

Very glad to hear you're enjoying the library 😊

I don't mean that traversing types at runtime is an antipattern- it's very much part of what we want to enable with ArkType!

I just meant in the original example, if you ever have a chance to define a literal type and then reference it vs. extract it back out with something like .get, the former is better.

Sounds like a great candidate to become an "official" feature?

Yeah I could see this being externally useful. I just have to think about how unions of objects are represented because it wouldn't be purely equivalent to getting a single type at that path, which is what I expect peoples' intuition would be.

If you create an issue with the context + motivation I will be more likely to add it soon!