Implement Placeholders for Widget Defaults and add UUID Placeholder
- Dominant language
- JavaScript
- Stars
- 19.4k
- Forks
- 3.1k
- Avg merge
- 1d 14h
- Merged PRs (30d)
- 9
Description
**Is your feature request related to a problem? Please describe.**
This is an issue to flesh out the discussion in #1407. It aims to describe how the discussed solution would be implemented. The goals are:
1. Generalise the use of placeholders so that they can be used in places other than in generating the `slug` field.
2. Add a `uuid` placeholder that is replaced by a UUID.
3. Enable the use of placeholders within widgets' `default` field.
**Proposed Solution**
1. Extract token replacement / placeholders to separate until that allows a configurable map of tokens to be supplied.
- Extract functionality in [slugformatter](https://github.com/netlify/netlify-cms/blob/2c5827bd99e740569a049dcdbe5eb7e85c668f69/packages/netlify-cms-core/src/backend.js#L39) to a formatter utility to make it generic. Allow a map of tokens => functions to be passed in to customise the behaviour. This way the supported tokens can be varied based on where the formatter is used.
- Configure a formatter to replicate current slug formatter functionality.
Note: At this point, functionality should be identical to present.
2. Add `uuid` field to the placeholder tokens supported by the slug formatter.
- Create a function for generating a uuid that wraps [uuid lib]https://www.npmjs.com/package/uuid), using `uuidv1()`.
- This will allow a uuid to be used inside slugs which I think is worthwhile.
3. Add formatting to widget's `default` value resolution.
- Create a new Formatter for use in processing a widget's `default` field.
- Currently there is a [check](https://github.com/netlify/netlify-cms/blob/c4e474b518763f50b737647c1153f83812ed5222/packages/netlify-cms-core/src/actions/entries.js#L383) for a default value. If a default value exists it should be run through the formatter and the returned value set as the `defaultValue`.
There are some further questions, but I don't think they necessarily need to be resolved now and could be added later to keep this feature small and focussed:
- Could user-defined placeholder functions be supported?
- Should a UUID field be added by default to all collection items?
- Could this be opt-in and enabled by a setting on the collection?
- Should there be a mechanism to add a UUID to existing collection items if one doesn't exist?
- Should relations default to using a `uuid` prop as the value for `valueField`?
Note: I have a little time over the next week and should be able to get this done if the above is acceptable.
**Describe alternatives you've considered**
There is the alternative described in #1407 which involves creating a widget to dynamically supply a UID. However I think a more low-level solution is preferable. Relations should not be being declared based on properties that can be edited by a user. This solution allows a stable field to be created at creation time and set as a `hidden` widget to prevent user-editing.
Contributor guide
Assessment
This issue has not been assessed yet.