-
Notifications
You must be signed in to change notification settings - Fork 179
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
Pd file detail form edit #1673
Pd file detail form edit #1673
Conversation
@b-cooper Can't seem to get the amazon link working for this one. |
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 a buncha comments but to summarize:
- Travis is failing b/c of flow errors https://travis-ci.org/Opentrons/opentrons/builds/389928470#L1360
- Bug where file is saved with "unsaved" fields
- HOC seems like a harder way to use
onKeyDown
, and for this use case it seems easier to use a form and itsonSubmit
prop
import * as React from 'react' | ||
import _ from 'lodash' | ||
|
||
const KEY_CODES = { |
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.
keyCode
is deprecated: https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/keyCode -- now the standard is key
https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/key
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.
But also it seems like the purpose of this whole enhancer is to make a new alternative mini-API for handling key press events -- instead of being able to have full control over the onKeyDown
, you give up control (eg control over allowing event bubbling, and over handling key modifiers like ctrl or shift) for syntax shortcut. I can't think of how this would have a broad use case. IMHO it seems more straightforward to use onKeyDown
prop directly and check the key
in whatever callback you use.
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.
That's fair. I'll use the event.key
directly in the onKeyDown
prop going forward.
<h2> | ||
Information | ||
</h2> | ||
<KeypressHandler |
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.
Could this be a <form>
with onSubmit={saveFileMetaData}
(which should also give you the save on Enter key behavior) and avoid the onKeyDown
handling?
@@ -7,5 +8,12 @@ export const rootSelector = (state: BaseState): RootState => state.fileData | |||
|
|||
export const fileFormValues = createSelector( | |||
rootSelector, | |||
state => state.metadataFields |
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.
There's a bug with this PR where if you change the form fields, do not click UPDATE, and then download the JSON file with the "Export" button, then the file has the "unsaved" name/description not the "saved" one.
It happens because this fileFormValues
is also used in file-data/selectors/fileCreator.js
's createFile
selector, so redirecting it to the unsavedMetadataForm
will save the unsaved fields, not the saved fields, in the JSON file.
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 switch createFile
's constituent selector from the unsaved form values to the saved metadata in fileMetadata
. And that should fix up the possibility for confusion. The unsaved changes will still exist in the text fields and the update button will still be enabled, which will continue to signal that there are unsaved changes.
@IanLondon I would say we might as well leave the unsaved changes in text fields until we get feedback that changes our mind. |
Codecov Report
@@ Coverage Diff @@
## edge #1673 +/- ##
==========================================
- Coverage 34.68% 34.67% -0.01%
==========================================
Files 342 342
Lines 5576 5592 +16
==========================================
+ Hits 1934 1939 +5
- Misses 3642 3653 +11
Continue to review full report at Codecov.
|
Nitpicky but: Can the text not read "saved"? Because it's on the file details tab I want to be super clear that this isn't stored in your browser yet. Updated would be preferred for now. |
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.
almost!
<h2> | ||
Information | ||
</h2> | ||
<form onSubmit={() => { console.log('DID IT') }}> |
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 you do <form onSubmit={saveFileMetadata}>
and remove the onClick
of the submit button, the form's onSubmit will fire. I'm not sure what it means to have an onClick
on a type=submit button... but since it's not logging 'DID IT', the onSubmit
is getting blocked overridden by the onClick
somehow. (As the code is now, the button's onClick
fires when you hit enter, which we want to happen, but weird that the button's onClick is fired when you hit enter and the form's onSubmit is not...)
I tried locally removing the onClick
and the 'DID IT' prints
</section> | ||
<div className={styles.button_row}> | ||
<OutlineButton type="submit" className={styles.update_button} onClick={saveFileMetadata} disabled={!isFormAltered}> | ||
{isFormAltered ? 'UPDATE' : 'SAVED'} |
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.
Putting a comment here so I don't forget - Morgan requested 'UPDATED' instead of 'SAVED'
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.
🍽️ sweeet
approved! (pending CI)
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.
Got a couple things that should be addressed, but fine to grab them in the next PR (or whenever):
- Stale TODO comment (I think)
- Don't import all of
lodash
Other comments are just for discussion
} | ||
|
||
export default function FilePage (props: Props) { | ||
const {formConnector, instruments} = props | ||
const FilePage = ({formConnector, isFormAltered, instruments, saveFileMetadata}: FilePageProps) => { |
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.
Out of curiosity, why the switch to an anonymous arrow function? Also, personally not a huge fan of object destructuring inside function parameters (especially when flow gets involved).
Both of these are highly personal readability preferences, so this comment shouldn't be construed as a change request. But figured I'd bring it up because we were chatting about this stuff earlier
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 agree about avoiding destructuring inside fn params, especially of props
. We're pretty consistent about that convention across all our components
export default function FilePage (props: Props) { | ||
const {formConnector, instruments} = props | ||
const FilePage = ({formConnector, isFormAltered, instruments, saveFileMetadata}: FilePageProps) => { | ||
const handleSubmit = () => { |
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.
Would be a good part of a generic Form
component in complib. Also, should this be a method of a class
based component instead to avoid the new function on every render? (Probably a premature optimization)
type DP = { onBackClick: $PropertyType<Props, 'onBackClick'> } | ||
|
||
type SP = $Diff<Props, DP> & {_page: Page} | ||
|
||
function mapStateToProps (state: BaseState): SP { | ||
const _page = selectors.currentPage(state) | ||
// TODO: Ian 2018-02-22 fileName from file |
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.
Should this TODO comment be removed?
@@ -1,4 +1,5 @@ | |||
// @flow | |||
import _ from 'lodash' |
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 try to import specifically what we're using from lodash
:
import isEqual from 'lodash/isEqual'
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!
71e29c4
to
28af4f0
Compare
overview
changelog
This Adds a new render prop component (HOC) to the component library. It is called KeypressHandler and will allow us to consolidate keyCode mappings and keypress logic to a single source going forward. It is currently being used in the File Metadata form in order to allow for submit/save on enter key down.
review requests
Try out creating a protocol and editing any and all of its field from the File Details page.
Closes #1504 and Closes #1661