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

Upgraded frontend-build version #593

Closed
wants to merge 19 commits into from

Conversation

BilalQamar95
Copy link
Contributor

Ticket:
42: Upgrade eslint to v8.x

What changed?

  • Updated frontend-build to v12 (Eslint was updated in frontend-build version resulting in it's version being bumped to v12. This PR updates frontend-build to reciprocate eslint version update)
  • Resolved eslint issues

For all changes

  • Ensure adequate tests are in place (or reviewed existing tests cover changes)

Only if submitting a visual change

  • Ensure to attach screenshots
  • Ensure to have UX team confirm screenshots

@BilalQamar95 BilalQamar95 requested a review from a team August 4, 2022 09:18
@BilalQamar95 BilalQamar95 self-assigned this Aug 4, 2022
@BilalQamar95 BilalQamar95 changed the title Upgraded frontend-build version to v12 Upgraded frontend-build version Aug 4, 2022
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",
Copy link
Member

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])
Copy link
Member

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.

@@ -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
Copy link
Member

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(() => ({
Copy link
Member

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.

Comment on lines 348 to 349
// eslint-disable-next-line react-hooks/exhaustive-deps
const baseQueryParams = new URLSearchParams(location.search);
Copy link
Member

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) : {};
Copy link
Member

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],
Copy link
Member

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.

Copy link
Member

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?

Copy link
Member

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.

Copy link
Contributor Author

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],
Copy link
Member

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.

Copy link
Member

Choose a reason for hiding this comment

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

Bump on this question.

Copy link
Contributor Author

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.

Comment on lines 24 to 25
// eslint-disable-next-line react/jsx-no-constructed-context-values
const value = { state, dispatch };
Copy link
Member

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">
Copy link
Member

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.

Copy link
Member

@adamstankiewicz adamstankiewicz left a 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],
Copy link
Member

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],
Copy link
Member

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
Copy link

codecov bot commented Oct 28, 2022

Codecov Report

Base: 79.06% // Head: 79.15% // Increases project coverage by +0.09% 🎉

Coverage data is based on head (3f4a0ad) compared to base (b35e2b8).
Patch coverage: 80.48% of modified lines in pull request are covered.

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     
Impacted Files Coverage Δ
src/components/Toasts/ToastsProvider.jsx 21.42% <0.00%> (-1.65%) ⬇️
src/components/app/App.jsx 0.00% <0.00%> (ø)
src/components/app/EnterpriseAppPageRoutes.jsx 0.00% <0.00%> (ø)
src/components/course/CourseMainContent.jsx 0.00% <0.00%> (ø)
src/components/course/CoursePage.jsx 0.00% <0.00%> (ø)
src/components/course/CourseRunCard.jsx 96.77% <ø> (ø)
src/components/course/CourseSidebar.jsx 0.00% <0.00%> (ø)
src/components/course/CourseSidebarListItem.jsx 0.00% <0.00%> (ø)
src/components/course/CourseSidebarPrice.jsx 97.61% <ø> (ø)
src/components/course/EnrollModal.jsx 93.10% <ø> (ø)
... and 105 more

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.
📢 Do you have feedback about the report comment? Let us know in this issue.

@arbrandes
Copy link

@BilalQamar95, have you addressed all of Adam's comments? Should we request a second pass? Maybe you could resolve the conflicts in the meantime.

@BilalQamar95
Copy link
Contributor Author

@arbrandes yes, Adam's comments have been addressed, however this PR is quite old now & upgrades the frontend-build to v12.0.3 resolving respective eslint issues whereas while resolving conflicts I realized the current frontend-build version of the repo is v12.4.15.

I'm closing this PR as it seems that this task is already complete with the merge of #660 which upgrades frontend-build to v12.4.15 & resolves all the subsequent eslint issues.

@BilalQamar95 BilalQamar95 deleted the bilalqamar95/frontend-build-upgrade branch January 27, 2023 09:45
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.

4 participants