-
Notifications
You must be signed in to change notification settings - Fork 4.4k
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
Split setup in advanced and regular for data sources and destinations #4160
Conversation
Awesome @gabrieldutra. A few thoughts:
Sidenote - I don't see a point to this extra padding:
|
@ranbena it can't be a front end only feature because each data source
needs to pick which configuration should be at front and which should be
collapsed.
Naming it "More Options" makes sense.
Also, is the collapsed state visible enough?
…On Sat, Sep 21, 2019, 08:46 Ran Byron ***@***.***> wrote:
Awesome @gabrieldutra <https://github.com/gabrieldutra>.
A few thoughts:
1. I think the collapse style is good 👍
2. Give the collapsed element m-t-30, m-b-10 for some spacing.
3. I'd rename to "More options" since it's not necessarily "advanced".
4. Consider keeping this a front-end-only feature, by putting all
non-required fields in the collapsed section, or by max field count.
Sidenote - I don't see a point to this extra padding:
https://github.com/getredash/redash/blob/cb654b3f2117507e2fcf2f866e8da5543665c928/client/app/components/CreateSourceDialog.jsx#L103
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#4160?email_source=notifications&email_token=AAAROLBVVLRQP6Q7BCFDHOTQKWYLHA5CNFSM4IY3LCIKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7ILCOQ#issuecomment-533770554>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAAROLHPACQGGB2WTNECHUTQKWYLHANCNFSM4IY3LCIA>
.
|
As Arik said, it's better to pick the fields that will be collapsed. There are cases where we want non-requierd fields to be visible (e.g: password field, it can be left empty, but it should be visible)
I was a bit concerned at the beginning, but it turned out to be ok to me. One other option is the SaaS style Levko mentioned. Also, I think it makes sense to use the customized Collapse we have, so we keep consistent in the UI. I've just realized the randomly selected options were done in the backend, so it's not possible to try this in preview 😅 |
Object.keys(properties).forEach((property) => { | ||
if (!isUndefined(properties[property].default)) { | ||
// set default value for checkboxes and for advanced options | ||
if (properties[property].type === 'checkbox' || properties[property].advanced) { |
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.
Why the advanced options need special handling here?
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.
This is related to the second note 🙂:
- Default values for advanced options are filled in the form when you are creating a DS/Destination (regular options are turned into placeholders). This allows the user to fill in the form without even looking into the advanced options;
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 show as a placeholder the default value and we use it as well. So there is no need to have a different behavior for the advanced options: they can skip them and the default value will still be used.
Although this made me think of why aren't we just filling in the default value for regular options as well? The only reason I can think of is to be able to change the default, but not sure if this is desired 🤔
Anyway, it's out of scope, so worth keeping the same behavior until we decide if we want to change.
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 was thinking about required values also being able to be additional settings, but considering what you mentioned I shouldn't be worried about them at all (also not a very important context anyway)
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.
A required setting will never be in advanced settings. The idea is to hide there all the things people won't really bother configure in normal cases. This doesn't apply to required settings.
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.
@gabrieldutra can you consolidate naming in codeadvanced options
/ extra options
/ additional settings
?
Yes, that's on my plans as soon as I figure what makes more sense (it's been changing since I opened, so I haven't bother to do that yet) |
@arikfr @gabrieldutra I question the need to have the "Additional Settings" functionality in datasource/destination view mode. It ain't a modal so let it be as long as it's settings, no? If not, I think at least we should have the additional settings open by default if a setting there has been modified. |
In general you're right. Let's address it when we actually have a view mode for Data Sources ;-) |
@@ -56,10 +56,11 @@ class DynamicForm extends React.Component { | |||
constructor(props) { | |||
super(props); | |||
|
|||
const filledExtraFields = filter(props.fields, field => field.extra && field.initialValue !== 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.
Perhaps use some
?
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.
Notice that if a user sets an extra field but then clear the field - it won't be undefined but '' hence the section would open needlessly.
Maybe check !isEmpty(field.initialValue)
instead?
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.
It is a bit trickier to determine whether a field is empty 😕, undefined
was the easiest I thought about (but there is the issue you mentioned). isEmpty
won't work neither for number nor for booleans. I'm thinking about an alternative option as I would like to keep it as a DynamicForm behavior 😬
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.
Just a few comments on filledExtraFields
.
Other than that, it's wonderful - great job!! 🤜 🤛
@@ -51,9 +56,14 @@ class DynamicForm extends React.Component { | |||
constructor(props) { | |||
super(props); | |||
|
|||
const hasFilledExtraField = some(props.fields, (field) => { | |||
const { extra, initialValue } = field; | |||
return extra && (!isEmpty(initialValue) || isNumber(initialValue) || isBoolean(initialValue) && initialValue); |
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.
@ranbena this seemed the simplest without separating this and deep evaluating the values with their defaults. I've also tried the last one and my opinion is that it's an unnecessary extra complexity.
@arikfr, I can go around and try to classify some DS/Destination fields as Extra Option (what of course should be reviewed afterwards), should I? |
No need. We will do it in a separate PR. |
:-) |
What type of PR is this? (check all applicable)
Description
Following #3771 to simplify the setup for DS, this will allow selecting settings to be considered "advanced".
Related Tickets & Documents
#3771
Mobile & Desktop Screenshots/Recordings (if there are UI changes)
Notes