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
Refactor of display logic in preparation for adding default dropdown behavior #42712
Conversation
@@ -70,6 +70,7 @@ class ReviewTab extends Component { | |||
serverLevelId, | |||
serverScriptId | |||
} = getStore().getState().pageConstants; |
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.
may be out of scope, but would you mind moving these to be passed in as props via redux?
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 about this in general -- since these are constants (ie, shouldn't change), do we still prefer they be passed in as props?
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.
From what I've seen, getStore.getState generally only gets called for libraries that can't be connected. React components generally get values like this by being connected and passing via props. I don't know the exact reason why we don't tend to call getStore.getState from within a component, but I'd generally be surprised to find something controlling a component by anything besides props.
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 have one more follow-up in the works after the functional change. I'll plan to do this as part of that change unless someone else gets to it before me.
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.
LGTM!
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.
So much better! 👏
} | ||
|
||
return ( | ||
<> |
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.
Woo fragments!
|
||
return ( | ||
<div style={styles.reviewsContainer}> | ||
<div style={styles.reviewHeader}> |
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: do we need this div if header is empty? Could we put it in renderHeader() if not?
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.
My follow-up PR (in progress) moves things around a bit more. I ended up getting rid of renderHeader. So I'll leave this as-is for now as it gets cleaned up in the next one:
https://github.com/code-dot-org/code-dot-org/pull/42716/files
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.
Nice!
3c62c5c
to
76cf867
Compare
This does a few things:
viewAs === ViewType.Teacher
to aviewAsTeacher
propstate
andprops
values anywhere with more than one reference to state/propsstate
andprops
namescodeReviewEnabled
and!viewAsTeacher
are only checked onceLinks
Testing story
Deployment strategy
Follow-up work
Privacy
Security
Caching
PR Checklist: