-
Notifications
You must be signed in to change notification settings - Fork 20
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
Upgraded frontend-build version #593
Conversation
…ner-portal-enterprise into bilalqamar95/frontend-build-upgrade
…ner-portal-enterprise into bilalqamar95/frontend-build-upgrade
package.json
Outdated
@@ -55,7 +55,7 @@ | |||
"universal-cookie": "4.0.4" | |||
}, | |||
"devDependencies": { | |||
"@edx/frontend-build": "11.0.2", | |||
"@edx/frontend-build": "^12.0.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.
nit: let's keep the version pinned like our other dependencies are.
|
||
return ( | ||
<ToastsContext.Provider value={{ toasts, addToast, removeToast }}> | ||
<ToastsContext.Provider value={ | ||
useMemo(() => ({ toasts, addToast, removeToast }), [removeToast, toasts]) |
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.
useMemo
shouldn't be called inline like this. Let's move it up above and store its output as a new variable contextValue
instead.
src/components/app/LoginRefresh.jsx
Outdated
@@ -5,6 +5,7 @@ import { Container } from '@edx/paragon'; | |||
import { LoadingSpinner } from '../loading-spinner'; | |||
import { loginRefresh } from '../../utils/common'; | |||
|
|||
// eslint-disable-next-line react/prop-types |
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.
[curious] Why are we disabling this ESLint rule here versus defining the prop type for children
?
function LoginRefreshWithContext({ roles = [] }) { | ||
return ( | ||
<AppContext.Provider value={ | ||
useMemo(() => ({ |
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.
Call useMemo
above the return statement within the component to create a new variable contextValue
instead.
src/components/course/data/hooks.jsx
Outdated
// eslint-disable-next-line react-hooks/exhaustive-deps | ||
const baseQueryParams = new URLSearchParams(location.search); |
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 ESLint warning is valid and IMO should not be ignored. On each re-render of the component consuming this React hook, baseQueryParams
will be recomputed and have a new reference. By including it in the useMemo
below, baseEnrollmentOptions
is re-computed every single time since baseQueryParams
changes each re-render. Should the baseQueryParams
be computed with a useMemo
as well?
const { enterpriseConfig: { slug, uuid } } = useContext(AppContext); | ||
|
||
// eslint-disable-next-line react-hooks/exhaustive-deps | ||
const course = hit ? camelCaseObject(hit) : {}; |
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 a valid ESLint error we shouldn't ignore. On every re-render of SearchCourseCard
, the course
variable be have a new reference, which will make linkToCourse
re-compute on every re-render as well. Should we compute course
with a useMemo
?
} | ||
return jobsArray; | ||
}, | ||
[currentJob], |
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.
[curious] Is jobToFetch
re-computed on every render of SearchCurrentJobCard
? I believe currentJob
in the dependency array will have a new variable reference on each re-render, and thus cause jobToFetch
to unnecessarily re-compute each re-render.
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.
Also nit: i think this variable might be intended to be named jobsToFetch
since its a collection of multiple jobs?
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.
@BilalQamar95 Bump on the first question around whether currentJob
in the dependency array is causing this memo to constantly re-run since currentJob
will have a new variable reference on every re-render of SearchCurrentJobCard
.
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 couldn't test it in the current app as it required making test data & going through the workflow which would take time but I do believe that you are right here. With currentJob
in the dependency array, it seems that jobsToFetch
will re-compute with each re-render.
} | ||
return jobsArray; | ||
}, | ||
[jobs], |
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.
[curious] Is jobsToFetch
re-computed on every render of SearchJobCard
? I believe jobs
in the dependency array will have a new variable reference on each re-render, and thus cause jobsToFetch
to unnecessarily re-compute each re-render.
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.
Bump on this question.
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 do believe that you are right here, with jobs
in the dependency array, it seems that jobsToFetch will re-compute with each re-render.
// eslint-disable-next-line react/jsx-no-constructed-context-values | ||
const value = { state, dispatch }; |
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 a valid ESLint error for a component. Context values should typically always be memoized.
</h2> | ||
function SkillsQuizHeader() { | ||
return ( | ||
<div style={{ display: 'flex' }} className="ml-2"> |
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: the style
prop is unnecessary here... use the d-flex
class name instead.
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.
@BilalQamar95 Looking good. I just have 2 remaining questions bumped from the previous review :)
} | ||
return jobsArray; | ||
}, | ||
[currentJob], |
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.
@BilalQamar95 Bump on the first question around whether currentJob
in the dependency array is causing this memo to constantly re-run since currentJob
will have a new variable reference on every re-render of SearchCurrentJobCard
.
} | ||
return jobsArray; | ||
}, | ||
[jobs], |
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.
Bump on this question.
Codecov ReportBase: 79.06% // Head: 79.15% // Increases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## master #593 +/- ##
==========================================
+ Coverage 79.06% 79.15% +0.09%
==========================================
Files 264 266 +2
Lines 5206 5229 +23
Branches 1280 1282 +2
==========================================
+ Hits 4116 4139 +23
+ Misses 1065 1064 -1
- Partials 25 26 +1
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
…ner-portal-enterprise into bilalqamar95/frontend-build-upgrade
…ner-portal-enterprise into bilalqamar95/frontend-build-upgrade
@BilalQamar95, have you addressed all of Adam's comments? Should we request a second pass? Maybe you could resolve the conflicts in the meantime. |
@arbrandes yes, Adam's comments have been addressed, however this PR is quite old now & upgrades the I'm closing this PR as it seems that this task is already complete with the merge of #660 which upgrades frontend-build to |
Ticket:
42: Upgrade eslint to v8.x
What changed?
frontend-build
to v12 (Eslint was updated infrontend-build
version resulting in it's version being bumped to v12. This PR updatesfrontend-build
to reciprocate eslint version update)eslint
issuesFor all changes
Only if submitting a visual change