@pnp/[email protected]
SPO
The following code should work:
const headers: any = {
"accept": "application/json",
"content-type": "application/json"
};
const listGuid = "41216dcf-c13a-4861-93d2-900f0582519e";
const title = "Description";
const fieldType = "SP.FieldMultiLineText";
const fieldProperties = {
FieldTypeKind: 3,
RichText: true,
Required: false,
StaticName: 'taDescription'
};
return sp.web
.lists.getById(listGuid)
.fields.configure({ headers: headers }).add(title, fieldType, fieldProperties);
Code fails with the following error:
The property '__metadata' does not exist on type 'SP.Field'. Make sure to only use property names that are defined by the type.
See above code snippet. It seems like despite suppressing the verbose mode in the content-type, PnPjs adds the __metadata property to the request which leads to the error.
So...here's the thing. The request bodies are different depending on meta-data mode (verbose, minimal, none) so we would need to sniff the headers, see if they have been overwritten and create different payloads for each. Not something we are likely to tackle anytime soon - but open to ideas on how we might. For now the best thing is to leave the default in place for write/update operations and switch to none when doing large amounts of reads to save space.
Gotcha. I came across this issue when refactoring some code that used to create fields using the REST APIs. I wanted to stay as close as possible to the original and use the generic add method rather than the specific methods for adding choice, date and other fields. So perhaps the real answer is to extend the refactoring and use the specific methods which should prevent the error from happening.
Cool - will close this issue as it appears answered. Thanks man!
Most helpful comment
Gotcha. I came across this issue when refactoring some code that used to create fields using the REST APIs. I wanted to stay as close as possible to the original and use the generic
addmethod rather than the specific methods for adding choice, date and other fields. So perhaps the real answer is to extend the refactoring and use the specific methods which should prevent the error from happening.