-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
🪟🎨 Clean up connector form form controls #21698
Conversation
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.
Left some comments, main changes requested are about issues I found when locally testing.
Overall this is looking great though!
title?: React.ReactNode; | ||
description?: React.ReactNode; | ||
full?: 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: it might be nice to group these props with the renderWithCard
prop somehow, so indicate that these are being applied to the card and are only used if renderWithCard
is true
(same comment for FormRoot since these props are drilled into there)
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 specified this in the types using a union of an interface for props with renderWithCard: true
and title/description/full and one with renderWithCard?: false
without them - we use the same pattern for destinations vs. sources.
Also while doing this I deduped the type between form root and connector form and removed a bunch of stuff that's not used anymore.
onClick={() => { | ||
setTestInputJson({}); | ||
}} |
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.
If the inputs in this ConfigMenu are blank (e.g. first time filling them out, or Reset was clicked to clear them), then you type a value into an input, and click Reset again without saving, it doesn't clear out the value.
I think we need to also clear the formik state here to make that work.
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.
Good catch, it needs to call resetConnectorForm
which is passed in as well, forgot about that.
<Button | ||
variant="clear" | ||
type="button" | ||
icon={<FontAwesomeIcon icon={logsVisible ? faChevronDown : faChevronRight} />} | ||
onClick={() => { | ||
setLogsVisible(!logsVisible); | ||
}} | ||
> | ||
<FormattedMessage id="connector.testLogs" /> | ||
</Button> |
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 seems like these logs are only showing up when I click Test and save
to perform the test.
If I click the Retest source
button instead, the Connector logs
tray is not rendered. I would expect as a user that the logs should be shown in both 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.
This is existing behavior but I agree it doesn't make sense. Unified the connection check behavior on submit vs. the test button (we need to set the errorStatusRequest
state)
onClick={onRetestClick} | ||
variant="secondary" | ||
icon={<FontAwesomeIcon icon={faRefresh} />} | ||
disabled={!isValid || (!isEditMode && !dirty)} |
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.
disabled={!isValid || (!isEditMode && !dirty)} | |
disabled={!isValid || (isEditMode && !dirty)} |
I think this was a mistake. The current logic means that if you set up a new connector and don't change any of the values (e.g set up an E2E Testing destination and don't change any of the defaults), then it won't let you test or submit.
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.
Good catch, actually it's even simpler - it should always be possible to re-test as long as the form is valid right now.
<FormattedMessage id="form.cancel" /> | ||
</Button> | ||
)} | ||
<Button type="submit" disabled={isSubmitting || !dirty}> |
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.
You'll need to fix this disabled
logic in a similar way, so that if we arent in edit mode, the form can still be submitted even if its not dirty (see above 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.
Adjustted
Thanks for the review @lmossman , addressed your points |
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.
Tested out the changes and it looks like all of the things I pointed out have been fixed 👍
I had to make a change because I realized we can't use the updated config values when testing an existing source/destination because with #21041 the check_for_update call can potentially update the actor in the database. This is what I did for now (but we should probably re-visit this in the future):
Also, this change makes me think that we might just want to hide the testing card for new actors and only pop them in if the user tries to save - the current solution is more consistent but I'm not sure. |
@flash1293 to confirm my understanding here:
If the above is correct, then I think the changes you made make sense to me as a temporary solution. However, it still feels pretty bad to me that users have no way of testing changes to an existing connector without saving those changes. To solve this, it seems like we need a new API endpoint, or a boolean param added to cc @evantahler @pedroslopez to get your thoughts on the above |
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.
Approving the current state of the PR as a good intermediate solution (see my comment above for my thoughts on follow-up changes here).
Also, this change makes me think that we might just want to hide the testing card for new actors and only pop them in if the user tries to save
I think the current solution is good, since as a user I like being able to test my configuration before I commit to actually saving it.
Tested locally and it works well. There is a merge conflict that needs to be fixed before merging.
@lmossman In general I agree that it's weird that invalid configurations could potentially be saved. However, this comes up because of single-use refresh tokens, which are part of the config. Once that refresh token is used, the previous config would be invalidated. Because of the way the UI worked (I haven't reviewed the actual changes in this PR), you could get into a situation where the check runs, refreshes tokens, and then the UI would call an "update" with the (invalid) values that were in the form. The problem is described more in #20913. To at least make it clearer to the user we introduced a We could add an input to the check that avoids persisting config updates, but this would have to be on some separate button so that we make sure your credentials are valid and properly update refresh tokens if necessary on the check that runs when saving. |
@pedroslopez thanks for taking a look!
Yes, this is handled on a separate PR
There is a separate button in the UI for this: I can open a separate issue for this, I don't think it's a super pressing task though - the UI worked like this probably since the beginning. |
@pedroslopez created an issue here: #21960 |
What
Fixes #20967
Old look
Empty
Selected connector
Check in progress
Error on unsaved connector
Passed checks:
Edit form:
Error on edit form:
New look
Empty
Selected connector
Check in progress
Error on unsaved connector
Passed checks:
Edit form:
Error on edit form:
How
ConnectorCard
anymore (move it down to theFormRoot
level)headerBlock
, so it can be rendered inside the card withinFormRoot
renderFooter
render prop which is responsible for rendering the form controls: