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

[student-libraries] Refactor the library creation dialog in preparation for adding 'unpublish' functionality #32792

Merged
merged 5 commits into from Jan 23, 2020

Conversation

jmkulwik
Copy link
Contributor

@jmkulwik jmkulwik commented Jan 21, 2020

This splits the LibraryCreationDialog into three parts

  1. LibraryCreationDialog - This is now a parent container for various success, loading, and error dialogs that are associated with library creation.
  2. libraryLoader - this is a util function that loads and does initial error checking for source code and metadata of the library (in the future, this will also merge the source and S3 versions of the library)
  3. LibraryPublisher - this handles the UX for selecting metadata to include in a library as well as the logic to publish a library. (in the future this will also handle unpublishing a library)

Background

Unpublish will add significant functionality to the library creation dialog. It will allow users to unpublish their library. It will also allow us to detect if a library has already been created, and, if it has, to merge the existing metadata into the library.

Testing story

Updated old tests

Reviewer Checklist:

  • Tests provide adequate coverage
  • Code is well-commented
  • New features are translatable or updates will not break translations
  • Relevant documentation has been added or updated
  • User impact is well-understood and desirable
  • Pull Request is labeled appropriately
  • Follow-up work items (including potential tech debt) are tracked and linked

@jmkulwik jmkulwik requested a review from a team as a code owner January 22, 2020 00:43
@jmkulwik jmkulwik changed the title Refactor the library creation dialog in preparation for adding 'unpublish' functionality [student-libraries] Refactor the library creation dialog in preparation for adding 'unpublish' functionality Jan 22, 2020
}
return (
<div>
<p style={styles.alert}>{errorMessage}</p>
Copy link

Choose a reason for hiding this comment

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

It looks like this will be rendered even when there is not error message?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

✔️

libraryDescription
);

// TODO: Display final version of error and success messages to the user.
Copy link

Choose a reason for hiding this comment

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

Is there anything left to do related to this TODO?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

✔️

class LibraryCreationDialog extends React.Component {
static propTypes = {
libraryClientApi: PropTypes.object.isRequired,

// From Redux
Copy link

Choose a reason for hiding this comment

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

🎆

Copy link
Contributor Author

Choose a reason for hiding this comment

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

✔️

return <div>{errorMessage}</div>;
};
render() {
const {message} = this.props;
Copy link

Choose a reason for hiding this comment

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

Nit: do these need to be two different lines?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

No, they don't - It seems like it's becoming good practice to do it this way (although certainly not necessary in this case).
Couple examples of this pattern:
https://towardsdatascience.com/react-best-practices-804def6d5215
https://brewhouse.io/blog/2015/03/24/best-practices-for-component-state-in-reactjs.html

Copy link

@epeach epeach left a comment

Choose a reason for hiding this comment

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

LGTM!

@jmkulwik
Copy link
Contributor Author

unit tests passed: https://drone.cdn-code.org/code-dot-org/code-dot-org/9416/
rerunning UI

@jmkulwik jmkulwik merged commit 395ab00 into staging Jan 23, 2020
bodyContent = <ErrorDisplay message={i18n.libraryNoFunctionsError()} />;
break;
default:
bodyContent = this.displayContent();
Copy link
Contributor

Choose a reason for hiding this comment

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

It seems kind of weird to be using the default case as a legitimate/common case. Would it make sense to add a DialogState to cover this case (so that the options of DialogState actually exhaustively cover the cases, and the default case of this switch statement would catch if we like, add a new DialogState or something like that?)


displayLoadingState = () => {
export class LoadingDisplay extends React.Component {
Copy link
Contributor

Choose a reason for hiding this comment

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

Could some of these be pure functional components instead of classes? https://towardsdatascience.com/react-best-practices-804def6d5215

@jmkulwik jmkulwik deleted the library-refactor-create-dialog branch February 20, 2020 01:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants