Refactor which custom properties are queried for in collection entries #2051
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
sebnitu
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What changed?
This PR refactors which custom properties are queried when
getCustomPropsis called. Instead of searching every key in theentry.context.settingsobject, we now use theentry.getSetting("customProps")method to return an array of all the props to query custom properties for.As part of this update,
getSettinghas also been refactored into a modular helper function which is then imported and applied as the entry methodgetSetting. It can now take an options object for setting a fallback value in cases where a setting doesn't exist as well as a props array with the order of properties to check for the setting. This allows for adjusting the order or adding on to the settings query.