-
Notifications
You must be signed in to change notification settings - Fork 19
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
feat: Integrate BFF calls with loader and hooks #1227
base: master
Are you sure you want to change the base?
Conversation
3ba3978
to
b720344
Compare
b720344
to
790931d
Compare
a38205d
to
144426e
Compare
7e70011
to
a73b16f
Compare
queryClient, | ||
subscriptionsQuery, |
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.
nit: looks like these args need to be removed from the parent function activateOrAutoApplySubscriptionLicense
, too, if no longer used (same where this parent function is called).
return subscriptionsData; | ||
return transformSubscriptionsData({ | ||
customerAgreement, | ||
subscriptionLicensesByStatus: baseLicensesByStatus, |
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.
Given this function doesn't really utilize subscriptionLicensesByStatus
here, i.e. when not relying on the BFF data, I believe it could be omitted? It'll already fallback to baseLicensesByStatus
based on the logic within the transform function, no?
1e97344
to
22b4459
Compare
22b4459
to
a02a07a
Compare
* @returns {Function|null} The BFF query function to use for the current route, or null if no match is found. | ||
*/ | ||
export function resolveBFFQuery(pathname, options = {}) { | ||
// Define route patterns and their corresponding query functions |
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.
nit: this comment technically refers to routeToBFFQueryMap
below; should it be co-located?
course_run_url: string; | ||
resume_course_run_url?: string; | ||
is_revoked: boolean; | ||
due_dates: DueDate[] |
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.
nit: semi-colon at the end for parity with other fields.
const { authenticatedUser } = useContext(AppContext); | ||
const userFirstName = authenticatedUser?.name?.split(' ').shift(); | ||
|
||
const [shouldShowLicenseActivationSuccessMessage, , close] = useToggle(!!sessionStorage.getItem('shouldShowActivationSuccessMessage')); |
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.
Name mismatch in the session storage key, shouldShowLicenseActivationSuccessMessage
is used now. Optionally consider creating a constant to re-use if it makes it less prone to mismatches?
Integrates the BFF API in dashboard related API calls related to
enterpriseCourseEnrollments
andsubscriptions
.Utilize the feature flag from the MFE config for BFF API eligibility based on the
enterpriseCustomer.uuid
. Currently, only a single stage customer is enabled.Determines if the user is on the dashboard route
/:enterpriseSlug
before making a to the BFF loader.Determines if the user is feature flagged to use the BFF API as a source of truth for
enterpriseCourseEnrollments
andsubscriptions
.If the user is not eligible to use the BFF API, fallback to the existing custom query hooks passed into
useBFF
.Updates the
dashboardLoader
to conditionally use either the BFF API or the existingenterpriseCourseEnrollments
query.Updates the root loader to determine if the user is on the dashboard route and conditionally use either the BFF API or the existing
subscriptionsQuery
Pending cleanup and test updates.
For all changes
Only if submitting a visual change