v3.0.0-rc.1 #3843
Replies: 2 comments 5 replies
-
|
This release breaks my next app. ./node_modules/.pnpm/[email protected]_maey765qzsqrp6bbazpxj7endy/node_modules/sanity/lib/exports/index.d.ts:9807:10
Type error: Property or signature expected.
9805 | declare module '@sanity/types' {
9806 | interface ArrayDefinition {
> 9807 | */
| ^
9808 | components?: ArrayOfObjectsComponents | ArrayOfPrimitivesComponents;
9809 | }
9810 | interface BlockDefinition {My Repo: https://github.com/alex289/Portfolio |
Beta Was this translation helpful? Give feedback.
-
|
Fixed in 3.0.0-rc.2 |
Beta Was this translation helpful? Give feedback.
-
This did indeed fix the TS error for ...but not for (tested in rc.2) |
Beta Was this translation helpful? Give feedback.
-
|
I am unable to reproduce this directly unfortunatly. This compile for me on rc.2: const aa = defineField({
type: "color",
name: "color",
components: {
input: (inputProps) => null,
},
});However, the following gives a compilation error on the const aa = defineField({
type: "color",
name: "color",
components: {
// type the shape of the object props value
// gives compilation error here
input: (a: ObjectInputProps<{ someField: string }>) => null,
},
});I suspect there is a case to be made that we should have the default value type be What is the prop-types of the Ie, something like function ColorPicker(props: ObjectInputProps) {
const value = props.value as MyColorType | undefined
//...
}I realize you have your If you hoist the Oh, and are you using the |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the detailed response @snorrees! Very strange, as I'm not seeing the same behavior as you (I even restarted my TS server in VS Code). Given the following: export const objectField = defineField({
type: "color",
name: "color",
components: {
input: (inputProps) => null,
},
});
export const typeWithField = defineType({
name: 'sometype',
title: 'Some Type',
type: 'document',
fields: [
defineField({
type: "color",
name: "color",
components: {
input: (inputProps) => null,
},
}),
defineField({
type: "string",
name: "color",
components: {
input: (inputProps) => null,
},
})
]
})I get the following TS error on
...elsewhere I've got this going on (which I'm assuming works because the field type is RE: the rest of your questions:
export function ColorPicker(props: ObjectInputProps) {
const {onChange, value} = props
const valueRgba = value?.rgba as string
/**
* This function returns a funtion that allows the caller to merge additional
* schema fields onto a shared field.
*
* Example usage:
*
* export const title = fieldGenerator(
* defineField({
* type: 'string',
* name: 'title',
* title: 'Title',
* })
* )
*
* title({fieldset: 'My Fieldset'})
*/
export function fieldGenerator<T>(base: T): (schemaFields?: Partial<T>) => T {
return (schemaFields) => ({...base, ...schemaFields})
} |
Beta Was this translation helpful? Give feedback.
-
The problemJust reproduced in a clean studio. Not having @sanity/color-input, was key. Sorry for not checking sooner 😓 @sanity/color-input, which as I alluded to, adds an "intrinsic" What we should fixTesting in clean studio makes I was going to show you how you can "monkey-patch" What you can do right nowNow, let me instead show you how you can add color as an intrinsic type yourself, if you want. It will fix your problem in lieu of a new rc version. I also personally really like this approach, as you can extend the standard type schema with your own stuff: // anywhere in your studio, add this
import { ObjectDefinition } from 'sanity'
// define your color schema, based on object-schema
export interface ColorDefinition extends Omit<ObjectDefinition, 'type' | 'fields'> {
type: 'color'
}
/* example if you wanted to add custom option support
export interface ColorDefinition extends Omit<ObjectDefinition, 'type' | 'fields' | 'options'> {
type: 'color'
options: ColorOptions
//or go real specific and define components and spesific object props
}
*/
declare module 'sanity' {
// makes type: 'color' narrow correctly when using defineTyp/defineField/defineArrayMember
export interface IntrinsicDefinitions {
color: ColorDefinition
}
}
//now, anywhere else, it should work
export const objectField = defineField({
type: "color", // color resolves to an intrinsic type now, so you get typesafety according to your own definition
name: "color",
//components exist on ObjectDefinition unlike TypeAliasDefinition, so you are good now :)
components: {
input: (inputProps) => null,
},
}); |
Beta Was this translation helpful? Give feedback.
-
|
You're a hero — thanks a lot for all this great info! |
Beta Was this translation helpful? Give feedback.
-
Features
subtitle, and will not use the dataset name by default🐛 Notable bugfixes
defineTypenot allowing specifiedcomponentssanity --version📓 Full changelog
dev, notstart) in post-init text@sanity/pkg-utilssanity.configWorkspacePreviewworkshop storysubtitleconfigurableThis discussion was created from the release v3.0.0-rc.1.
Beta Was this translation helpful? Give feedback.
All reactions