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
#7432: support placeholder text in form builder #7433
#7432: support placeholder text in form builder #7433
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #7433 +/- ##
==========================================
+ Coverage 72.61% 72.64% +0.02%
==========================================
Files 1210 1210
Lines 37821 37837 +16
Branches 7098 7107 +9
==========================================
+ Hits 27464 27486 +22
+ Misses 10357 10351 -6 ☔ View full report in Codecov by Sentry. |
@@ -67,6 +67,31 @@ const UNKNOWN_OPTION: SelectStringOption = { | |||
value: null, | |||
}; | |||
|
|||
function showPlaceholderText(uiType: UiType): boolean { |
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.
nit: in terms of naming practices I like to lean towards a question style naming for methods that return a boolean, ex. shouldShowPlaceholderText
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.
In terms of re-usability, we might want to consider how we could bundle inherent logic about the uiType into the uiType data structure itself rather than using a helper switch/case function based on its propertyType. This way its easier to refactor and add new uiTypes.
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.
Can't do it with uiType without completely rewriting several files. It's just not worth it at this time.
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.
The problem is this code:
pixiebrix-extension/src/components/formBuilder/edit/FieldEditor.tsx
Lines 148 to 184 in ed0e25b
const getSelectedUiTypeOption = () => { | |
const fieldSchema = schema.properties[propertyName]; | |
if (typeof fieldSchema === "boolean") { | |
return UNKNOWN_OPTION; | |
} | |
const isDatabaseFieldType = isDatabaseField(fieldSchema); | |
const isGoogleSheetFieldType = isGoogleSheetIdField(fieldSchema); | |
const propertyType = | |
isDatabaseFieldType || isGoogleSheetFieldType | |
? "string" | |
: (propertySchema.type as SchemaPropertyType); | |
const uiWidget = isDatabaseFieldType | |
? "database" | |
: isGoogleSheetFieldType | |
? "googleSheet" | |
: uiSchema?.[propertyName]?.[UI_WIDGET]; | |
const propertyFormat = propertySchema.format; | |
const extra: UiTypeExtra = | |
uiWidget === "select" && propertySchema.oneOf !== undefined | |
? "selectWithLabels" | |
: undefined; | |
const uiType = stringifyUiType({ | |
propertyType, | |
uiWidget, | |
propertyFormat, | |
extra, | |
}); | |
const selected = fieldTypes.find((option) => option.value === uiType); | |
return selected ?? UNKNOWN_OPTION; | |
}; |
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.
We would need to completely refactor how uiType is inferred. I spent close to 2 hours trying to find a clean way to do it without rewriting multiple components/files and wasn't making much headway, so I pulled out.
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.
Thank you for the effort! It might be good to document this complexity somewhere for posterity, or record a tech debt item/issue.
@@ -299,6 +333,8 @@ const FieldEditor: React.FC<{ | |||
<SchemaField {...defaultFieldProps} /> | |||
)} | |||
|
|||
{showPlaceholderText(uiType) && <SchemaField {...placeholderProps} />} |
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.
question: With this change a user will be able to save a placeholder for a particular input field, right? No additional work required for changing how we save the brick.
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.
Yep, this is using the uiSchema
part of RJSF, so the actual placeholder valued making it into the real form field when the brick runs should all be handled by RJSF.
"Email", | ||
"Website", | ||
"Number", | ||
])("displays the placeholder field for %s", async (inputType: string) => { |
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.
nit: is there a better type than string for inputType?
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.
inputType is just the string input values in the test.each()
call
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.
Right, I was wondering if there's maybe an Enum string type for the possible list of input types
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.
They are just human-readable labels for the test cases
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.
Hmm, although, I guess now that you mention it, it's not totally clear how these test cases map to the different UiTypes... 🤔
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.
See formFieldTypeOptions.ts
. I could create some logic to pluck the specific labels.
@@ -67,6 +67,31 @@ const UNKNOWN_OPTION: SelectStringOption = { | |||
value: null, | |||
}; | |||
|
|||
function showPlaceholderText(uiType: UiType): boolean { | |||
switch (true) { |
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.
switch(true)
?
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.
Oh, is this equivalent to using switch
with no input in other languages?
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.
Yes. That said, I'm working on a refactor that should replace the. need for this. And clean things up quite a bit. If I can parse some of the really strange behavior I'm seeing with the uiType dropdown.
When the PR is merged, the first loom link found on this PR will be posted to |
What does this PR do?
Demo
https://www.loom.com/share/9c0a387205a94073b36ffe0a692eb8a8
Checklist