* fix: adjusting discussion selection step 1 message
Removing a duplicate message too.
* fix: adding a dividing line between all sections of the app config forms
The line is its own component because it has some custom styling to make it go edge-to-edge.
There’s a known issue here where a divider inside a TransitionReplace component won’t show its full width until the transition is finished. No idea how to fix that.
* fix: moving app titles inside the config forms.
Also moving the Card styling in too, since it sorta goes with the dividers and the overall look of the specific forms moreso than the parent.
* fix: allowing dividers to be thicker between sections
This defaults our discussions provider to legacy if one was not specified by the backend.
It also fixes a few navigation and provider selection bugs that I encountered in testing the above.
* fix: removing unnecessary CSS classes and files
The .discussion-app-card and .features-table classes aren’t actually used - that means the AppList.scss file and pages-and-resources/index.scss above it can both be deleted.
* refactor: moving AppList components into app-list sub-directory.
* refactor: moving ConfigFormContainer and children into app-config-form sub-directory
* refactor: Renaming ConfigFormContainer to AppConfigForm
Makes it consistent with app-list/AppList.
* refactor: providing discussions path to sub-components via a context
This will be used in subsequent commits as we move functionality out of DiscussionsSettings.
* fix: change step two label to “Settings”
The mockups changed the label, which is great, since we’re aiming to remove the need for selectedAppId to be in DiscussionsSettings. This is one step toward that.
This has the side effect of making app.name no longer necessary, which is great, since the app no longer contains its own name string.
* refactor: adding replacement data layer for app-list and app-config-form
This code is a replacement for the slice, thunks, and api in /discussions/data. It’s an “expand” commit that adds the new implementation. The next commit will use it, and the last will remove the old implementation.
Those files in /discussions/data contained API functions, thunks, and reducer state for two separate components (app-list and app-config-form) that don’t actually share any code. Turns out they’re perfectly separable, and more understandable apart.
This new code isn’t used yet.
* refactor: add a context to provide a formRef to AppConfigForm components
This is an intermediary commit - it’ll likely fail linting since the whitespace is a bit off. It’s also not doing anything yet - a subsequent commit will make use of this code (the provider and new ApplyButton component)
Today the DiscussionsSettings component needs to be responsible for form submission because it owns the “Apply” button that a user clicks to submit the form. It declares a “formRef” which is passed into the form and attached to the form DOM element, and then the “Apply” button can call formRef.current.submit() to submit the form from DiscussionsSettings, even though the form itself is declared way down in a sub-module.
This is awkward, and forces this top level component to be smarter than it should be, and to know too much about its children.
An alternate pattern is to create a context provider (AppConfigFormProvider) which owns the formRef and is part of the sub-module. Then create an AppConfigFormApplyButton component that knows how to pull that formRef out of the context and call submit on it.
This way, DiscussionsSettings doesn’t know anything about form submission, and we can move all that code into the app-config-form sub-module that should know about it. Win!
Again, this commit just adds the code and inserts the provider into DiscussionsSettings - it doesn’t use it all yet.
* refactor: create AppListNextButton that knows how to move to step two of the Stepper
Like the previous commit, this will enable us to factor code out of DiscussionsSettings and into a sub-module where it is a more natural fit.
This AppListNextButton makes use of the `selectedAppId` we’ll be adding to our new app-list reducer in order to know which app has been selected in the list. It can then use that to change the URL route.
In contrast to the previous commit, we use redux here instead of a context. We used context for the formRef because we try to keep complex data types like that out of redux, and also because formRef is not _state_, but just an implementation detail of how we needed to wire everything up in a React app. selectedAppId, on the other hand, is state, and so belongs in redux more naturally.
* refactor: cutting over to using the new discussions reducers
This commit will break everything, since the React components haven’t been updated to use the new reducer shape yet. Subsequent commits will convert app-list and app-config-form over.
* refactor: remove app-list logic from DiscussionsSettings
This is a ‘contract’ commit which removes functionality from DiscussionsSettings and adds it to AppList.
A word of warning that I tried my best to separate this refactor from that of AppConfigForm, but this commit may not be perfect. The original problem was that the two sub-modules were unnecessarily intertwined, making use of some shared variables when they didn’t need to (such as selectedAppId), so I can’t fully get app-list working without touching app-config-form as well… so this particular commit probably has logical errors and won’t build properly. Taken together with the next commit for app-config-form, though, they move a significant amount of logic out of DiscussionsSettings and into the sub-modules and isolate them from each other.
You’ll see here that handleSelectApp and handleStartConfig move into the app-list sub-module. The former goes into AppList, the latter was committed to AppListNextButton in a prior commit.
Once those two are gone, a bunch of other code in DiscussionsSettings starts falling away. selectedAppId is still necessary since the config form handlers are using it, but we’ll see that disappear in the next commit.
* refactor: move app-config-form logic out of DiscussionsSettings
This is the last major commit. It removes a handleApply and handleSubmit from DiscussionsSettings and then cleans up the various variables and imports which are no longer necessary.
handleApply moved into AppConfigFormApplyButton in a prior commit, and handleSubmit has moved into AppConfigForm itself. Now DiscussionsSettings doesn’t know anything about forms or submission, we’ve successfully moved all that code down into sub-modules.
This commit also makes use of AppConfigFormApplyButton.
* refactor: remove old discussions reducers, thunks, and APIs
These three files are now obsolete and have been replaced by a new set of reducers in app-list and app-config-form, specific to those sub-modules specific functions.
This has the side effect of simplifying the naming of the state variables and making it easier to reason which variables are for what sub-module. Prior to this refactor, there were several logical bugs where we were using a confusing combination of “selectedAppId” in local state, “displayedAppId” and “activeAppId” in redux, along with displayedAppConfigId, and it wasn’t quite clear what was for which part of the app, and mis-use was causing some loading and state errors as users navigated around.
The “status” variable in this reducer was also problematic, as we have two separate async requests we’re trying to track the status of - fetchApps and fetchAppConfig. The app was getting confused about what was loaded and what was still loading, which actually caused an infinite loop for me before choosing to refactor (state changes from the two requests were invalidating the state of the other, toggling back and forth between LOADED and LOADING)
* refactor: moving authoring.discussions.heading fix into the right messages file
The links for proctored exam settings and pages and resources were incorrect - both needed a prefix of `course/` and pages & resources should end with `pages-and-resources`
* feat: adding form validation to LtiConfigForm and LegacyConfigForm
The three fields in LtiConfigForm each get their validation/feedback hooked up properly, and the blackout dates field in LegacyConfigForm now uses a regex-based validator for blackout date strings.
* doc: Improving comments for the blackout dates regex.
* fix: allow no blackout dates
* chore: adding jest-dom package and configuring it
Also bumping version of paragon - it’s in this commit because the changes in package-lock.json can’t really be separated from each other.
* fix: improve mocked data in the API layer
Make the mocked data for the app configs closer to reality, using correct shape and better IDs.
* fix: improve layout of FormSwitchGroup and make compatible wit latest paragon
Form.Group needs a controlId, and this layout gives a nice gutter between the text side on the left and the switch itself on the right.
* fix: active vs. displayed apps and app configs
We have a problem in that the app config and app that are _displayed_ in the frontend are not necessarily the same as app and app config that’s _active_ for the course. I.e., maybe I’m configuring a new one, but a different integration’s already set up.
This commit changes our data model a bit to differentiate between the two - this will let us display information about what’s currently active at the same time as configuring a different integration.
This commit also tweaks a Container size to make the form a bit wider. Pretty.
* refactor: split LegacyConfigForm parts out into their own components
This is in preparation for needing to share legacy config form fields with the ‘standard’ config form for the new discussions MFE. In particular, we also need to pull the InContextDiscussionFields out of the legacy form - that component exists but isn’t technically used in this commit. It will be included in the ‘standard’ form soon.
- This uses a new function in frontend-platform 1.9.0 that sets up a mock application for use in test suites.
- The ProctoredExamSettings.test.jsx tests have been refactored to use axios-mock-adapter and initializeMockApp.
- A tweak was made to ProctoredExamSettings to use error.response.status instead of error.customAttributes.httpErrorStatus - the former is a more canonical way of getting at this data, rather than using the customAttributes object we add to our errors. It also means the code will work with the MockAuthService instead of AxiosJwtAuthService.
- Removing axios dev dependency - we don’t need it anymore!
Prior to this, the list of providers in the UI was hardcoded in the api.js layer.
This commit hooks that up to our actual API endpoint, allowing us to load the provider list from the server.
It also - out of necessity - changes the way the AppCards are displayed, and what content is in them. This was somewhat opportunistic as our design for them simplified anyway, no longer requiring a logo or a few of the other fields.
Because the actual API sends us less display-oriented data (i.e., no names or descriptions for things), we had to modify FeaturesTable and AppCard to fetch these strings from the messages file based on the app and feature IDs.
I’m not super thrilled with this approach, since it’s somewhat brittle. Unexpected providers won’t display properly. In the long run, I expect all this may come from some other system. Using translations to load dynamic strings isn’t quite what it was intended for - i.e., we’re not putting “Piazza” in there because we want to translate it, but because the backend didn’t tell us what to use for the key “piazza”.
* feat: Implement edX forums advanced setting editor
This change implements the UX for the advanced settings editor for the internal edX forums.
* Stepper now intelligently shows/hides drop shadows on the header and footer
Also organized the component into a more Paragon-like organization with the sub-components hanging off the main one.
* Organizing full screen modal in a more Paragon-like way.
Also fixing a few minor styling issues.
* Massaging SettingsEditor into LegacyConfigForm
- Reorganizing into apps/legacy directory from settings/base-forum
- Using Formik and Yup for managing form data
- Refactoring FormSwitchGroup a little and adding data-related properties
- Also moving FormSwitchGroup into ‘generic’
- Some initial attempts at error validation in LegacyConfigForm (a blackout dates regex which doesn’t seem to work yet)
- Sub-sections of config now fold and animate when their parent is toggled.
* Minor naming and refactoring of Discussions component
- Event handlers should be named handle*, not on*. Oops. Got over-zealous.
- Organizing paths into some variables at the top of the component. The pages and resources path should probably be passed in.
* Hooking up and organizing LTI and Legacy forms
- The LTI form moves into app/lti
- Adds in rendering of the legacy discussions form.
- Splits up the messages file a bit (app/lti/messages.js exists now)
- Removing unnecessary h1 in the LtiConfigForm.
* Removing ‘info’ blue coloring from the pages & resources view.
Co-authored-by: Kshitij Sobti <kshitij@sobti.in>
* 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.
* Adding font-awesome so we can use it with StatefulButton
* Rudimentary discussion config UI with mocked APIs.
* Updating Yellowdig logo URL
* Bumping and locking dependencies, adding formik and yup
* Wiring up the “Enable” button to go to the discussions config.
* Refactoring DiscussionConfig to use formik and yup.
* Using more paragon components - Card, CardGrid, and DataTable
* Adding keys to arrays of rendered components.
* Ignore module.config.js file.
* Bumping frontend-build to the latest version.
* Removing font-awesome again - it’s no longer necessary.
The latest version of Paragon uses <FontAwesomeIcon> for its closing “X”, rather than using CSS class names directly.
* Splitting discussion app list cards out into their own component.
They used to, but were folded in while refactoring to use Card and CardGrid.
* Adding comments to FeaturesTable.
The PageCard code wasn’t updated to match the right props - it was still expecting “coursePage” when the new prop was “page”. It was also lacking some other misc refactoring from earlier.
* Backing discussions with data API/thunks/reducer.
This pulls all the data loading logic out of the React components and makes it significantly more flexible.
- Both apps and features have IDs and can be looked up in the store.
- The API layer is currently just returning hard coded data.
- LOADED and LOADING statuses are available to implement loading spinners and feedback.
- The taxonomy has been changed a bit - “forums and “tools” are now consistently referred to as “apps” - this code is almost completely agnostic to discussions, meaning that it could easily be repurposed for other kinds of apps, such as proctoring providers.
* Using ‘app’ and ‘name language in DiscussionAppCard messages.
* Using the selectedApp’s name for the Configure button.
* Misc review fixes
- better comment on error handling
- Fixing some CSS class names.
* Fixing package SCSS imports.
They need tildas. This ensures webpack knows to look for them in the node_modules folder, and also enables webpack resolve aliases to function (which is the mechanism that module.config.js works on)
* Renaming course-page-resources to pages-and-resources
It’s all course stuff in the end.
* Renaming CoursePageResources to PagesAndResources
To match its parent directory and the page’s user-facing name.
* Simplifying name of CoursePageConfigCard to PageCard
Also moving into a sub-directory where we’ll put components for the “pages” part of the UI.
* Remove data README from example app.
* Moving discussion-tool-selector directory
Adding it as a child of the pages-and-resources module.
* Organizing SCSS.
* Simplifying discussions module structure.
- Combining “container” and discussion tool selector into DiscussionAppList.
- Removing some sub-directories that feel a bit too granular.
* Splitting out some sub-components from PagesAndResources.
* Removing unnecessary scss extension on import.
* Added new components for Discussion Tool Selection
* Incorporating discussion tool selector page into CourseAuthoringRoutes
* Improving tool selection - will now unselect
Also using a pointer cursor.
* Styling tweaks, logo size and text color
Making the logo so it doesn’t scale vertically - picked 100px arbitrarily. It will be changed, but is now at least a little more inline with how the Pages & Resources view behaves.
Also darkening text color - it looked disabled.
* Adding a “Configure forum” button
It appears when a tool is selected.
This is a temporary location, depending on whether or not we insist on this page being a full-page modal. In my opinion we should just keep it a normal page.
Co-authored-by: Aayush <ayush@opencraft.com>
* Updating dependencies and removing unneeded ones.
* Fixing broken IntlProvider attribute in ProctoredExamSettings test.
* package-lock.json was out of sync - checking it in.
* Initializing an empty redux store.
* Adding model-store from frontend-app-learning.
This will let us save data from the server in a normalized way in redux, reducing boilerplate in React components.
* Fixing paragon button usage.
(also just organizing the imports while I was there…)
* Using paragon button instead of an anchor tag.
For the “New Page” button in the pages & resources view.
* Add API, reducers, and thunks to add course detail data into redux.
Subsequent PR will use this to store course detail data for use across different pages in the application.
* Prep work to add CourseAuthoringPage component.
Decided the course-detail sub-directory didn’t make much sense, given component structure, and moved it up to src.
These functions will be used in a CourseAuthoringPage component to load course detail data and display the Header and Footer in one common place, wrapping all the existing course authoring pages (proctoring and pages & resources)
It will also replace LmsApiService.js
* Minor style refactorings.
(This commit had originally made some changes to how courseId was passed in to these two components, but I decided to back it out… but the style stuff is worth adding as a fixed nit.)
* Refactor course detail loading and top-level course authoring components
This commit does a few things:
- Factors course detail data loading out of the Header.
- Loads that data in CourseAuthoringPage instead, adding it to redux and then passing it to the Header from there.
- Deletes LmsApiService, which is no longer used.
- Changes the route paths to be more canonical and entity-oriented, i.e., the first part of the route is the course, followed by the specific page about that course to load, rather than the other way around. This more naturally allows us to use react-router to extract the common course detail loading code that only depends on the courseId.
* Refactoring routes code a bit to pass courseId into components
Didn’t like how CourseAuthoringPage, LegacyProctoringRoute, and CourseAuthoringRoutes all reached into the parent route to find the courseId, so passed it in instead.
* Updating README with more detail on routes in the MFE.
