[CFU] Refactor summary page question rendering back to HAML - #51410
Conversation
4237d67 to
9f9725f
Compare
9f9725f to
0e9990a
Compare
| /* stylelint-disable selector-pseudo-class-no-unknown */ | ||
| .levelTitle, | ||
| .markdown h1, | ||
| .markdown h2, | ||
| :global(.markdown-container) h1, | ||
| :global(.markdown-container) h2, | ||
| :global(h1.no-underline), | ||
| :global(h2.no-underline) { | ||
| border-bottom: unset; | ||
| } | ||
| /* stylelint-enable selector-pseudo-class-no-unknown */ |
There was a problem hiding this comment.
mostly whitespace changes in this file since I removed the nesting so the styles would apply to the haml pieces again. this part here is the other change, where I'm adding some :global selectors, also to apply to the haml code. this seemed slightly cleaner than having another file dashboard/app/assets/stylesheets/summary.scss to duplicate css specifically for the haml, but feel free to push back on that.
There was a problem hiding this comment.
no new tests, just moving the existing ones around and removing the parts that were testing code that's now in the haml.
| .free-response | ||
| - title = level.get_property(:title) | ||
| - if title.present? && !in_level_group | ||
| %h1.no-underline= title | ||
| - long_instructions = level.get_property("long_instructions") | ||
| - if long_instructions | ||
| / Markdown will be rendered clientside by _free_response.js | ||
| .markdown-container{data: {markdown: long_instructions}} | ||
|
|
||
| - height = level.height || '80' | ||
| - placeholder = level.get_property(:placeholder) || I18n.t('free_response.placeholder') | ||
| %textarea.response{id: "level_#{level.id}", placeholder: placeholder, style: "height: #{height}px;", readonly: true}= last_attempt |
There was a problem hiding this comment.
this is copied and simplified from _free_response.html.haml, except for the addition of the .no-underline class.
| // send them back to the level in Participant mode instead. | ||
| if (viewAs === ViewType.Participant) { | ||
| document.location.replace(currentLevel.url + document.location.search); | ||
| } |
There was a problem hiding this comment.
a little strange to have this here in the responses component, but i wasn't sure where else to put something like this that isn't tied to any one visual element, but causes a side-effect on the page. i thought about putting it in _summary.js, but it needs access to redux, and that seems like a pain.
| textarea.freeResponse { | ||
| width: 100%; | ||
| box-sizing: border-box; | ||
| resize: vertical; | ||
| } |
There was a problem hiding this comment.
note this is removed entirely because it's back in the haml using application.scss styles
bethanyaconnor
left a comment
There was a problem hiding this comment.
Looks great -- just a couple questions/suggestions. Sorry that you had to do this :/
| levelType: level.type, | ||
| ...scriptData.reportingData, | ||
| }); | ||
| // eslint-disable-next-line react-hooks/exhaustive-deps |
There was a problem hiding this comment.
Why disable this check?
There was a problem hiding this comment.
i'm not sure actually, this was there before. i'll look up the original commit and see if i can remember why i did this. it might also just be wrong
There was a problem hiding this comment.
It might be due to the eslint upgrades (slack thread). If possible, it would be great to clean this up while you're here but if it balloons for some reason, feel free to leave it
There was a problem hiding this comment.
ah yeah it was. I added scriptData into the dependencies array and it seems happy now.
|
|
||
| const setUpWrapper = (state = {}, jsData = {}) => { | ||
| const store = createStore( | ||
| combineReducers({ |
There was a problem hiding this comment.
My preference here would be to export an UnconnectedSummaryTopLinks and not use redux in this test file. Personally, I think it's cleaner that way, but feel free to push back.
To expand: I'm suggested adding a link to SummaryTopLinks.jsx like export const UnconnectedSummaryTopLinks = SummaryTopLinks (possible I have my syntax wrong) then using that in this test. That was you don't have to mess around with creating the store and can instead pass props in directly.
There was a problem hiding this comment.
re-reading this, I misunderstood it the first time. some questions, for my own understanding: is it common practice to test on the unconnected component like this? when should/shouldn't I do it? (e.g. why only SummaryTopLinks and not SummaryResponses?) Why don't we want the code inside the connect() to be hit by the tests too?
There was a problem hiding this comment.
we do use the "unconnected" components in tests a lot through our repo (eg ShareDialog and corresponding test. That said, I forgot there's some logic in the connect function so that might be worth testing. Honestly, that's a good argument to me to keep the store in the test file.
| expect(wrapper.find(`.${styles.navLinks} a`).length).to.eq(1); | ||
| }); | ||
|
|
||
| it('applies correct classes when rtl', () => { |
| #summary-content | ||
| #summary-top-links | ||
|
|
||
| .container#level-question |
There was a problem hiding this comment.
As a follow up, could we move this to a place where it's shared with the level itself? Or is it too different for that to make sense?
There was a problem hiding this comment.
i think it's too different, but i'll look into it and see if i can make it work. it would be nice to not have the duplication
There was a problem hiding this comment.
No worries, just curious
There was a problem hiding this comment.
I'm not confident in being able to refactor _free_response to use a new thing without breaking it. I opened a task to refactor this later if we want; I'd rather do it in a separate pass, to break up the risk a bit.
There was a problem hiding this comment.
thanks! definitely a follow up task if it's possible at all!
bethanyaconnor
left a comment
There was a problem hiding this comment.
up to you on the test -- I'm fine either way. Otherwise this looks good to me (pending a green Drone run of course)
Break the
CheckForUnderstandingcomponent out into several components, that can be placed on the page alongside the level question. This lets us keep the level question rendering inside Rails, which we need for the Multi levels.There's a slight difference in padding between the top nav links and the first heading, because of the structural changes to the HTML, but I think that's fine.
Links
Testing story
Added eyes tests in #51517 to check for visual changes introduced by this PR.