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

Option to have nullable by default? #198

Open
nahtnam opened this issue Jun 14, 2023 · 1 comment
Open

Option to have nullable by default? #198

nahtnam opened this issue Jun 14, 2023 · 1 comment
Assignees

Comments

@nahtnam
Copy link

nahtnam commented Jun 14, 2023

Hello,

I have been using groqd for a while, and while implementing Sanity's preview mode, I realized most (if not all) fields end up being null in draft state (except for the slug). I think it would be pretty useful to have a way where everything is nullable by default. I understand the typescript could get kind of tricky with this but do you think either having a way to do this with declaration merging (not sure if it's possible) or maybe something similar to grab$ but with a different symbol would be useful?

@maxyinger
Copy link
Contributor

Have been trying to think through what this might look like.

Currently thinking maybe something like a .draft() method on a query might be nice for this. Would add some TS considerations while applied tho.

Here's the basic idea I'm tossing around:

import { q, type Draft, type Selection, type TypeFromSelection } from 'groqd'

const pokemonSelection = {
   name: q.string(),
   attack: ["base.Attack", q.number()],
} satisfies Selection

type SanityPokemon = TypeFromSelection<typeof pokemonSelection>
// ^? { name: string; attack: number }

// Added Draft<T> utility type if you're using selections to define component prop types
type SanityPokemonDraft = Draft<SanityPokemon>
// ^? { name: string | null | undefined; attack: number | null | undefined }

const query = q("*")
  .filterByType("pokemon")
  .grab(pokemonSelection)
  // Added draft method which would go through all properties in the schema and make them nullish.
  // Would also be compatible following .grabOne() or .select()
  .draft()

Only annoying thing is it would impact all type definitions down stream of the query and you'd have to account for nullish scenarios that might not be applicable once you remove the .draft() method.

I'm wondering if there's a more elegant approach 🤔 ... but in general, I agree, it would be nice to have more flexible schema while you're content is a work in progress.

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

No branches or pull requests

3 participants