Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to export a specific type and all its children #95

Open
IgnisDa opened this issue Jul 24, 2023 · 7 comments
Open

How to export a specific type and all its children #95

IgnisDa opened this issue Jul 24, 2023 · 7 comments
Milestone

Comments

@IgnisDa
Copy link

IgnisDa commented Jul 24, 2023

The export function only exports the given type and not its children. How can I export a type and its children?

@Brendonovich
Copy link
Collaborator

export is only designed to export a single type, to export a type + all its dependent types you'll need to iterate through the type_map that collects all the types that specta has walked into itself.
Specta is a fairly low level library atm and is best used with something that can collect types for you, like rspc or tauri-specta.
The way rspc is able to export all dependent types is by maintaining a single type_map that is passed to all invocations of Type::reference, and then the types are converted to TS in a loop to construct the final bindings.

@IgnisDa IgnisDa closed this as completed Jul 24, 2023
@oscartbeaumont
Copy link
Member

I am going to reopen this issue as a reminder to myself that a better solution needs to exist here.

Brendan is completely right in the fact that the current APIs around dealing and exporting dependant types are very low-level and there is no reason that should remain the case. I think it has mostly ended up that way as we have added APIs into Specta as required for rspc and tauri-specta without really thinking super heavily about using Specta without a framework wrapping it.

It's worth noting that the export crate feature (example) does work with exporting dependant types out of the box and I think this will cover many use-cases. It's entirely possible it's not what your going for and that's all good but just wanted to mention it incase you haven't noticed it exists.

@IgnisDa
Copy link
Author

IgnisDa commented Jul 26, 2023

Yes I have noticed it. However, the way I want to use specta is that I want to write the export of different types to different files. If I understand correctly, specta right now works by appending each registered type to a typemap. That does not satisfy my use-case.

@oscartbeaumont
Copy link
Member

Completely fair.

We could potentially allow the user to define a function to decide the file to put the types into from the ExportConfiguration because I feel like it has come up before but idk how useful that would be unless you had some well-defined measure for what goes in each file. I am fairly sure with #72 (which will be part of Specta v2) we will store the Rust module path on each type so maybe that could be used here for automatic module-based sorting?

Out of curiosity are you organising your types by module or some internal concept?

I will keep this all in mind for when I next have time to work on Specta.

@IgnisDa
Copy link
Author

IgnisDa commented Jul 26, 2023

Out of curiosity are you organising your types by module or some internal concept?

No, I just have them in one models.rs. Here is an example of an export by specta.

Schematic has the behavior of just exporting the given type and its children. Here is an export using schematic.

The reason I am using specta and not schematic is because schematic is used for configuration and I just want to export the type signature.

@IgnisDa
Copy link
Author

IgnisDa commented Jul 26, 2023

On a different note, does specta not export docs for each field?

I have added doc comments for the field but specta does not export them.
https://github.com/IgnisDa/ryot/blob/1dea787774047b40a20fea35143fef783b004c27/apps/backend/src/models.rs#L517-L572

@oscartbeaumont
Copy link
Member

I don't think it does right now. Nothing would be preventing that from working if added to the macros, was just an oversight.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants