-
-
Notifications
You must be signed in to change notification settings - Fork 24
Add support to parse picklist values #207
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support to parse picklist values #207
Conversation
f989eed to
cb2dccb
Compare
|
@cesarParra not sure if you have an integration test to verify but believe the changes are completed. Let me know |
@RaviVaranasi Yeah, the CI tests will run once I approve. |
package.json
Outdated
| { | ||
| "name": "@cparra/apexdocs", | ||
| "version": "3.4.2", | ||
| "version": "3.4.3", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll take care of the release so let's revert this. Since this Apexdocs is following semver the next one will be 3.5.0 as I consider this change to be an additional feature and not a bug fix.
| } | ||
|
|
||
| function isCustomField(customField: object): customField is CustomFieldMetadata { | ||
| return (customField as CustomFieldMetadata).type != undefined; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[minor] Let's use strict equality (e.g. ===, !==). Since we want to account for both null and undefined we can coerce into a boolean:
return !!(customField as CustomFieldMetadata).type;
| **Type** | ||
| *{{fieldType}}* | ||
| {{#each pickListValues}} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm thinking that instead of looping through the picklist values, we will want to make this its own section, and only render it if there are values to display (since not all fields will be picklists).
I like how Salesforce documentation does it, where they have the "Possible values are" as the heading
See my comment below in the src/core/renderables/types.d.ts file with the details about the changes that would need to be made to the type to accomplish this
RaviVaranasi
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm wondering if this should be renamed to something like
hasType, since at this stage we already know we are dealing with custom field metadata because of the previous check (validate)
Agreed
abff594 to
1970145
Compare
|
@cesarParra Unsure of the last commit but should be ready for review again |
@RaviVaranasi No worries. I took the liberty of making that change. I tested the output and there was another change needed on the Handlebar template, since it was not respecting the correct heading. Here is the commit I made if you are curious: 2e58a93 The build is passing so I'll merge and let you know once I publish a new version to NPM |
cesarParra
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great, thanks so much for contributing this improvement!

When generating documentation for custom objects, include pick list values in documentation
TODO: