* Bumping paragon version to latest. * Modifying event handlers to be named with “on” prefix instead of “Handler” suffix * Tweaking a message id. * Removing “Discussion” prefix from discussions components. Seems unnecessary. * Backing pages & resources view with data handling. It still has the list of pages hard coded. * Adding FullScreenModal and Stepper components. These components are pretty close to their final form. They could benefit from some snapshot tests and such; there isn’t much actual functionality in ‘em. Stepper will get a bit more functionality when we add the dynamic drop shadow behavior. Depending on whether the stepper body is at the top or bottom, drop shadows on the header and footer should appear or disappear to indicate more content exists above or below the viewport. * Moving discussions routes inside PagesAndResources Note that the discussions component has been renamed - that’ll be coming in a subsequent commit. Also trying to get consistent about calling it “discussions” * AppList gets less responsibility The AppList is now a child of the top-level “Discussions” component, so it’s no longer responsible for loading the app list or storing the state for the selected app ID. It’s also given a handler for when an app is selected, and no longer has a button to configure the app. * Fleshing out Discussions component The top-level Discussions component (renamed from DiscussionsRoutes) is now responsible for a lot. - it loads the app list - it keeps track of selected app ID - it has handlers for all the various user actions so they can be coordinated here at the top. - it uses component composition to create the majority of the UI, folding together FullScreenModal and Stepper with its route-based views. * Decomposing the app config form The discussion app config form has been decomposed into a container responsible for loading app data, and a component specifically for the LTI configuration form. In the future, ConfigFormContainer will get a second possible child for the edX Forums app, and will switch between the two forms based on the app being configured. Note that I expect that some of the data loading logic from ConfigFormContainer may be better situated in the Discussions component… everything else is happening there, and it may make sense for it to handle loading the app config data as necessary as well.
44 lines
1.5 KiB
JavaScript
44 lines
1.5 KiB
JavaScript
import React from 'react';
|
|
import PropTypes from 'prop-types';
|
|
import { Switch, useRouteMatch } from 'react-router';
|
|
import { PageRoute } from '@edx/frontend-platform/react';
|
|
|
|
import CourseAuthoringPage from './CourseAuthoringPage';
|
|
import { PagesAndResources } from './pages-and-resources';
|
|
import ProctoredExamSettings from './proctored-exam-settings/ProctoredExamSettings';
|
|
|
|
/**
|
|
* As of this writing, these routes are mounted at a path prefixed with the following:
|
|
*
|
|
* /course/:courseId
|
|
*
|
|
* Meaning that their absolute paths look like:
|
|
*
|
|
* /course/:courseId/course-pages
|
|
* /course/:courseId/proctored-exam-settings
|
|
*
|
|
* This component and CourseAuthoringPage should maybe be combined once we no longer need to have
|
|
* CourseAuthoringPage split out for use in LegacyProctoringRoute. Once that route is removed, we
|
|
* can move the Header/Footer rendering to this component and likely pull the course detail loading
|
|
* in as well, and it'd feel a bit better-factored and the roles would feel more clear.
|
|
*/
|
|
export default function CourseAuthoringRoutes({ courseId }) {
|
|
const { path } = useRouteMatch();
|
|
return (
|
|
<CourseAuthoringPage courseId={courseId}>
|
|
<Switch>
|
|
<PageRoute path={`${path}/pages-and-resources`}>
|
|
<PagesAndResources courseId={courseId} />
|
|
</PageRoute>
|
|
<PageRoute path={`${path}/proctored-exam-settings`}>
|
|
<ProctoredExamSettings courseId={courseId} />
|
|
</PageRoute>
|
|
</Switch>
|
|
</CourseAuthoringPage>
|
|
);
|
|
}
|
|
|
|
CourseAuthoringRoutes.propTypes = {
|
|
courseId: PropTypes.string.isRequired,
|
|
};
|