feat: autocomplete subprops and allow string values for readOnly in resolveData

[mkilpatrick]

This updates the TS types of resolveData such that:

readOnly can now return a boolean OR a string. Supporting string is helpful when you have a 'custom' field defined for a level which contains multiple fields underneath, rather than using objectFields. resolveData can pass a string value of the subfield being set for readOnly.

As an example, given this type:

type MyProps = {
  foo: {
    bar: {
      id: string;
      value: string;
  }
}

and I want to create a custom Puck field at the bar level, I have id and value as subprops. resolveData works at the level of bar, so if you wanted to set value as readOnly, that is not possible with

resolveData: () => {
  return {
    readOnly: { 'foo.bar': true }
  }
}

we do this instead now

resolveData: () => {
  return {
    readOnly: { 'foo.bar': 'value' }
  }
}

and then in the field's render function the readOnly prop would have a value of 'value'.

The readOnly acceptable values now autocomplete to any valid subfield. Prior to this change only the top-level fields were enumerated by the type. Given the MyProps example above:

resolveData: () => {
  return {
    readOnly: { 'HERE': 'value' } 
  }
}

HERE would autocomplete as: 'foo'

Now it autocompletes as : 'foo' | 'foo.bar' | 'foo.bar.id' | 'foo.bar.value'

More context around these changes can be found here.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated (UTC)
puck-docs	❌ Failed (Inspect)		Sep 24, 2024 10:39pm

[vercel]

@mkilpatrick is attempting to deploy a commit to the Measured Team on Vercel.

A member of the Team first needs to authorize it.

[mkilpatrick]

The DotBranch type could be used in a number of more places.

[chrisvxd]

I like the DotBranch type here (and have been meaning to do this for a while) but I'm unsure about the readOnly string solution.

and I want to create a custom Puck field at the bar level, I have id and value as subprops. resolveData works at the level of bar, so if you wanted to set value as readOnly, that is not possible with

resolveData: () => {
  return {
    readOnly: { 'foo.bar': true }
  }
}

This is true, but I would expect this to be the appropriate API -

resolveData: () => {
  return {
    readOnly: { 'foo.bar.value': true }
  }
}

The challenge is then that the custom field won't have any way to receive the readOnly value. Rather than make the value a string, it might be cleaner to introduce a new prop to the custom field type that provides the readOnly object

render: ({ readOnly, readOnlyData }) => {
  
  // false
  console.log(readOnly);
  
  // { 'foo.bar.value': true }
  console.log(readOnlyData);
  
  return <div />
}

Whilst we're at it, maybe we should consider that resolveData method should return a nested object rather than dot-notated fields. I can't remember the reason we didn't do this in the first place.

resolveData: () => {
  return {
    readOnly: { 
      foo: {
        bar: {
          value: true
        }
      }
    }
  }
}