Skip to content

Lexicon validations #5

Open
Open
@mary-ext

Description

Some thoughts at the top of my head as I figure out how to get a lexicon validator that works, especially one for my needs.


  1. Reduce the ambient module declarations to just the stuff necessary to get the typed HTTP client working, rename the module specifier to be something like @atcute/lexicons/http
  2. Lexicon types should be imported from their respective packages, app.bsky.* lexicons should be imported from @atcute/bluesky, same goes for @atcute/whitewind and so on.
  3. Move com.atproto.* lexicons to a separate @atcute/atproto package

Some of these aren't strictly necessary, but given that these type declarations and lexicon validations are pretty nifty for anyone using it outside of the typed HTTP client, I should at least accomodate for it for my next chance at revisiting this


  1. We could provide validateX and isX functions just like what @atproto/api is providing, however:

    • Only validateX provides a safe-parsing functionality
    • isX is used to check whether the object in question either has no $type field, or the field exists and matches the expected type for that object.
  2. There's like 3 different ways to validate data, and they're all neat for their own cases.

    if (v.is(AppBskyFeedPost.Record, record)) {
      // handy if you just want to know if it's valid
    }
    
    // this one throws, handy for anything that requires the value to exactly match
    v.parse(AppBskyFeedPost.Record, record);
    
    // this one doesn't throw, if it returns `ok: false` you can deal with the error however you see fit
    v.safeParse(AppBskyFeedPost.Record, record);

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Assignees

Labels

breaking changeIssues that involve doing a breaking change

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions