payload
payload copied to clipboard
feat!: various type improvements
Description
- Globals are no longer typed as
TypeWithIDorGlobalTypeWithID, as globals do not have IDs. Now they are justRecord<string, unknown> - Extract common types into utilities. These are useful for properly typing our seed data, e.g. here (https://github.com/payloadcms/payload/pull/6385/files#diff-275a5bc9d2d469e19efe811b4431787d02a79db73cde145f7f81f5027c0f6c9fL4). It also makes it easier to read and clearer what this type actually does. Additionally, we can properly search for usages of these now:
-
GeneratedTypes['collections'][TSlug]toDataFromCollectionSlug<TSlug> -
MarkOptional<GeneratedTypes['collections'][TSlug],'createdAt' | 'id' | 'sizes' | 'updatedAt'>toRequiredDataFromCollectionSlug<TSlug>
-
- Make all operations uniformly accept Slugs as generic. Previously, some accepted slugs, some accepted data. It was chaos
- Rename
Tgenerics into more descriptive ones (TSlugorTData) - Remove unused generic from
BasePayloadas we always useGeneratedTypesanyways - Add optional
TSluggeneric toCollectionConfig. Currently it's used to properly type theAfterOperationHookresult. In a later PR, I want to trickle that down to all the other hooks which are currently mostly untyped! -
relationTois now properly typed to the collection slugs (from generated types)! - Lexical: Arguments for relationship, link and upload features (e.g. enabledCollections) are now strongly typed to the collection slugs (from generated types)
- Keys from GeneratedTypes are now only strings instead of
number | string | symbolwith the help of a newStringKeyOfutility type. This makeskeyofoperations on them more reliable
BREAKING:
- Type narrowing for
relationToprops on filterOptions, relationship fields and upload fields - Type narrowing for arguments of lexical relationship, link and upload features
- [ ] I have read and understand the CONTRIBUTING.md document in this repository.
Type of change
- [ ] Chore (non-breaking change which does not add functionality)
- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
- [ ] Change to the templates directory (does not affect core functionality)
- [ ] Change to the examples directory (does not affect core functionality)
- [ ] This change requires a documentation update
Checklist:
- [ ] I have added tests that prove my fix is effective or that my feature works
- [ ] Existing test suite passes locally with my changes
- [ ] I have made corresponding changes to the documentation