Skip to content
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

Merged
merged 12 commits into from
Oct 6, 2019

Conversation

gabrieldutra
Copy link
Member

What type of PR is this? (check all applicable)

  • Feature

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)

advanced-settings

Notes

  • I've randomly selected a few options to be considered advanced, just so we get the feel of it on Preview;
  • 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;
  • So far I'm using Antd's Collapse default for the job, but lmk if you have other suggestions 🙂

@gabrieldutra gabrieldutra self-assigned this Sep 20, 2019
@ranbena
Copy link
Contributor

ranbena commented Sep 21, 2019

Awesome @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:

@arikfr
Copy link
Member

arikfr commented Sep 21, 2019 via email

@kravets-levko
Copy link
Collaborator

We already have a bit customized Collapse in SaaS, maybe we can use it here as well?

image
image

@gabrieldutra
Copy link
Member Author

Consider keeping this a front-end-only feature, by putting all non-required fields in the collapsed section

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)

Also, is the collapsed state visible enough?

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 😅

@ranbena
Copy link
Contributor

ranbena commented Sep 21, 2019

I made a kind of a hybrid between the two and I quite like it:

Screen Shot 2019-09-21 at 16 40 12

{
  height: 40px;
  font-weight: 500;
  background-color: @btn-danger-bg;
  border-color: @btn-danger-border;
}

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) {
Copy link
Member

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?

Copy link
Member Author

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;

Copy link
Member

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.

Copy link
Member Author

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)

Copy link
Member

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.

Copy link
Contributor

@ranbena ranbena left a 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?

@gabrieldutra
Copy link
Member Author

gabrieldutra commented Sep 21, 2019

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)

@ranbena
Copy link
Contributor

ranbena commented Sep 22, 2019

@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.

@arikfr
Copy link
Member

arikfr commented Sep 22, 2019

@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?

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);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps use some?

Copy link
Contributor

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?

Copy link
Member Author

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). isEmptywon'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 😬

Copy link
Contributor

@ranbena ranbena left a 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);
Copy link
Member Author

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.

@gabrieldutra
Copy link
Member Author

gabrieldutra commented Sep 23, 2019

@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?

@arikfr
Copy link
Member

arikfr commented Sep 24, 2019

@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.

@arikfr arikfr merged commit 8ea285d into master Oct 6, 2019
@arikfr arikfr deleted the ds-advanced-options branch October 6, 2019 08:46
@arikfr
Copy link
Member

arikfr commented Oct 6, 2019

:-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants