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
Manage Students Table: add multiple students button #20935
Conversation
<div> | ||
{numberOfEditingRows > 1 && | ||
<Button | ||
onClick={()=>{console.log("save all");}} |
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 the TODO referenced in the description.
This PR is getting to be large so saving "Save all" button for another one. So close to being able to ship! |
Looks like the success notification still says "you added one student". Will that be confusing for users? |
|
||
// New student row is created after a list of students have been | ||
// added to the table, but their information hasn't been saved | ||
// to the server yet. |
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.
These comments are really helpful in clarifying what's happening!
isEditing: true, | ||
isAddRow: true, | ||
}; | ||
// Creates a new "new student" add row for teach name in the array. |
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.
tiny nit: "each" instead of "teach"
expect(sortedList[1].id).to.equal(2); | ||
expect(sortedList[2].id).to.equal(1); | ||
expect(sortedList[3].id).to.equal(3); | ||
}); |
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'm confused - this test makes it seem like the new student being added will go immediately after the add new student row, effectively at the top of the table. When brent and brad are added in the PR description, they're at the bottom of the list. I don't think it matters either way, I just want to double check the test matches the behavior and clarify if I'm reading it incorrectly.
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... this is before you hit save - so the rows that are actively being edited show up at the top of the table.
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 before hitting save. We want to pin them there because it'd be weird to have them scattered throughout the table. Order is clarified in the comments of sortRows function.
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.
Circle failure looks related to ManageStudents Storybook...
"you added one student" is currently the case because I haven't implemented save all so they are saving one at a time. Once I add save all, it'll have a specific number. |
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.
Great work Caley! I don't see any blocking issues in this PR, but I do have some super-picky style nits (for which I should probably investigate linting/autofix options).
}; | ||
|
||
state = { | ||
openDialog: false, |
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.
Super-picky nit: I'd name this something like isDialogOpen
. openDialog
sounds like an action to me. In fact, you have a public method openDialog
just below.
/> | ||
<BaseDialog | ||
useUpdatedStyles | ||
uncloseable |
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 dialog has a "Cancel" button. Is there a good reason to make it uncloseable? This is worth diverging from spec to provide user-friendly behavior, unless there's a specific reason for 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.
Nope - I copied this from somewhere and forgot to remove it.
<div> | ||
{i18n.addStudentsMultipleInstructions()} | ||
</div> | ||
<textarea name="textarea" rows="15" cols="70" ref="studentsTextBox"> |
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.
May not necessary to fix in this PR, especially if there will be a styling pass later, but it'd be nice to size this textbox to match the dialog width instead of using rows/cols. Also not sure it should be resizable.
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 do a style pass all together 👍
// Types of rows in studentData/editingData | ||
// newStudent looks like a studentRow with isEditing true, but | ||
// is updated like an add row, since the student has yet to be added. | ||
export const ROW_TYPE = { |
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.
Another nit: We're not nearly as consistent about this as we should be, but this doesn't follow our naming conventions for enums/constants.
Our primary styleguide calls for EnumNamesLikeThis
, CONSTANT_VALUES_LIKE_THIS
. That would change the ROW_TYPE
enum to:
export const RowType = {
ADD: 'addRow',
NEW_STUDENT: 'newStudentRow',
STUDENT: 'studentRow',
};
// Used as `RowType.NEW_STUDENT`
Same with the ADD_STATUS
enum, above.
New React Manage Students tab is behind
manageStudents
experiment, so this change won't affect users.rowType
instead of isAddRow in thestudentData
rowTypes
todo in next PR: save all functionality