sanity
sanity copied to clipboard
Field Group navigation within array object not functional on Studio V3 in Next.js
Describe the bug
When using Sanity field groups within an array object, the generated field group navigation tabs are not functional.
To Reproduce
Steps to reproduce the behavior:
- Use Sanity Studio v3 in a Next.js app
- Create a Sanity schema that contains an object type and is also in a group:
export const test = {
name: "test",
title: "Test",
type: "object",
groups: [
{
name: "content",
title: "Content",
default: true,
},
{
name: "design",
title: "Design",
},
],
fields: [
{
name: "content",
title: "Content",
type: "content",
group: "content",
},
{
name: "design",
title: "Design",
type: "design",
group: "design",
},
],
};
export default test;
- Place this object into an array.
- Field group navigation tabs are unresponsive.
Expected behavior
Field group tabs should display the correct field group.
Screenshots


In the last image, the field group links aren't functional.
Which versions of Sanity are you using?
"sanity": "^3.0.0-dev-preview.9",
What operating system are you using?
MacOS latest.
Which versions of Node.js / npm are you running?
node 16.13.1 npm 8.1.2
This is also true without step 1. Group tabs inside the modal are irresponsive.
Group content is rendered correctly if a group has set default: true
, but is useless when you cannot switch. Not setting any to default: true
correctly renders the "All" tab and you can at least edit the fields whilst we wait for the fix
Might be a separate issue, but the same goes for fieldsets with options.collapsible
in v3. If the fieldset belongs to an object inside an array, the expand component becomes irresponsive.
EDIT: This happened to me with [email protected]
using Chrome v104.0.5112.79.
Can't reproduce this issue, so concluding it's been fixed already. Please file a new issue if it's still a problem.