DUMP

[oscartbeaumont]

This is an old document in my notes that I wanna dump here. Will think about it again in the furture so that all of it will a pound of salt.

``
#[specta(optional)] should not work on unnamed fields + add into trybuild
`comments: Vec<Cow<..>>` or `doc: Option<Cow<..>>` should probs just all be `doc: Cow<..>` for consistency
Should `EnumType` have `deprecated` and `comments`. Logically right now it's on `NamedDataType` but it's also a wacky disparity.

Are we properly escaping enum tags. I have a feeling they could contain invalid chars for a TS name or even reserved words???

Defined order for handling multiple conflicting attributes either within a single attribute or across multiple attributes.
Should specta::lang::js_doc be specta::lang::ts::js_doc???
Should #[specta(optional)] change?
Should #[specta(transparent)] change? Right now a reference to it is to the type name but Serde kinda imply in their docs that it should be a direct passthrough to the single inner field. If not changing it we should have something to handle the opposite case + unit test it with #[specta(optional)] on the single field.
Unit test using inline and transparent together cause they cause issues. Especially with attributes applied to the inner value like #[specta(optional)].
Does exporting doc comments on redundant conditions break then removable of the redundant conditions?
For usage with to_named it might make sense to allow mutable changes to deprecated, doc, etc on NamedDataType

2.0.0-rc.4:

• Abstraction for collecting up types and their dependant types into a file

• Examples using the TypeMap and Type trait directly + docs explaining the methods on Type

• Cleanup DefOpts

• Run rustfmt workflow in CI

• Rewrite TS exporter to clean it up

• Cleanup macros

• Deprecated - Export Rust deprecated parameter #32

  • Deprecated function, field, variant, struct, enum + unit tests for it all

• Language overrides - Per language type overrides #110

• [DRAFT] Add in support for duplicate type names across modules #72

• Does it make sense to remove macros/src/attrs/enum. See how Serde handles those attributes on a struct.

• Error for #[serde(tag = "...")] can only be used on enums and structs with named fields

• Error for #[serde(content = "...")] can only be used on enums - Add to Specta macros

• Filter out redundant conditions in & or || #134

• Specta docs overhaul

• So the mental model is the that inline only applies to the type you call it on, if you want more inner stuff inlined it's on you to use the attributes. Although certain types will always inline like Vec, Option, etc.

Thursday:

• specta::Serialize??
• specta::json?? - specta::json #105

Refactor TS exporter to use string joining instead of Vec's so save allocations + also just give it a general cleanup!
type CowStr = Cow<'static, str>;
Can TypeMap's value not be Option? I have a feeling it doesn't need to be anymore.
Put TypeMap into ExportContext

Vec<impl Into<DataType> for DataType should be for UntaggedEnum

On a struct with named fields: Serialize the struct's name (or value of serde(rename)) as a field with the given key, in front of all the real fields of the struct.

• Unit test this
• With unnamed fields should panic

Future:

• Remove Type::definition_generics
• Names of functions on NamedType are cringe
• "syn" style extra-traits feature for debug and the like
• If you #[specta(inline)] a recursive field it will stackoverflow. Make this a proper error instead!
• impl Iterator<Item = &T> + ExactSizeIterator or something instead of returning &Vec<T>, etc. Keep it consistent
• Should SpectaFunction be a public trait cause it's got a rough signature????

Seal DefOpts
Go through and do my best to seal enum types

For flatten right now we export ({ a: string }) & ({ a: string }) but we should export ({ a: string })

• Copy all feature flags for impls from ts_rs - https://github.com/Aleph-Alpha/ts-rs
• Add smallvec support Aleph-Alpha/ts-rs#162

Aleph-Alpha/ts-rs#165
Aleph-Alpha/ts-rs#152
Aleph-Alpha/ts-rs#153

Can TypeMap should/should it not hold Option<NamedDataType>??? Technically using a type in a partially constructed state is bad.

[f32; 4] should export as a Typescript tuple of length 4

Make #[serde(untagged)] enum work?

Review public API and doc and improve them
Example of function exporting without 3rd party library
Document features
Document different export methods and when to use them
Stuff from phone
Discuss enum types and tagging, etc
DefOpts.parent_inline document what it actually does
// TODO: Does inline, definition and reference all need to exist and explain them
Design
Why not use Rust TypeId -> Limitations with lifetime
etc

Make NamedDataType.export work
Inlining a recursive type -> What happens? Unit test
Put all language exporter other than ts behind "unstable" feature flag

Should Specta v2 keep the impls for external crates because we can't ever remove them once published and moving the impls into the downstream crate would be better performance.
Break up the current language exporters into their crates and remove from Specta itself???

Rename internal module to __unstable so it's less likely to be in LSP hints and to make it clear it's not to be used.

Unit tests for stupid types -> Assoicated types, assoicated constants, with and without bounds, etc

• Can export feature work with assoicated types, does Serde?

[oscartbeaumont]

Specta v2
Why are there two Reference types.

Can we remove the reference method from Type.

Can we remove the generics arg from Type. Just ensure definition isn’t a lazy pass through cause I bet that’s what breaks it.

Rename DeprecatedType to DeprecatedAttribute or something

Should LiteralType end up as a TS only extension???

Move data type stuff to Specta-core which will cleanup the public docs

Better docs for traits and inline vs reference, named data type vs non named type

Using static references to trait object for typescript type extension???

Why is prettier and eslint in the TS module
Remove ‘ts::Result’

`export` feature doesn’t work with generic types. Should *just* work for have a better warning.

TODO: Merge this is the obsidian doc

[oscartbeaumont]

• Does flatten passthrough a transparent type (Eg. Arc, etc)

• All impls should return a Type struct or something like that.

  • Eg. impl Type for X { fn inline() -> Type { Type::from::<Self>(DataType::...) } }

  • Type::from is responsible for putting itself into the typemap so we can remove DataType::Struct and DataType::Enum because they will always be references.

  • Look into use a TypeId without the 'static bound style system like erased-serde instead of the SpectaID macros. (So it can be derived in Type::from) for better DX.

  • Use track_caller on Type::from to get caller info without macro??? Can we get module with this, probs not?

  • How do the docs end up in Type::from??

  • Make SpectaID an associated type on Type maybe????

  • Provide a Type::is<T>() function

[oscartbeaumont]

Remove NamedDataType and merge it's metadata into Type

Static vecs

! type
Move out non-ts exporter into crates

Should DataTypeReference.inline??? This would probs simplify the Type macro a bit

Type::reference -> DataTypeReference + Remove Reference
The bigger issue here is the Reference could be inlined and then it's a DataType::* not DataType::Reference

Using Cow instead of Vec everywhere

Break out language exporters into dedicated crates
Break static_types into language specific crates

The export feature should take in a standard interface to a language exporter so we don't need it to have methods for each language
Should export feature be kept in the Specta core???

Can we somehow remove Specta's dependance on tauri while keeping tauri-specta working

Public constructor for List and Map

DataTypeReference.inline -> Should we use a property and delay processing it????

Lint for enabling Debug on all public types