-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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/lint onboarding slides #4240
Refactor/lint onboarding slides #4240
Conversation
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.
Thanks for making a PR @daningenthron! 🎉
I made some of these changes in #4254, but I will rebase and take your changes in my branch after this has been merged.
Happy Hacktoberfest! 🎃
checkedCodeOfConduct: false, | ||
checkedTermsAndConditions: false, | ||
emailMembershipNewsletter: true, | ||
emailDigestPeriodic: true, |
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.
Not that this will technically be breaking the onboard process, but it won't properly update user's preference. This is because the whole state is sent via fetch as param.
I still want to accept this and make changes to the controller to snake-case params but reverting this refactor could be more straight foward. Do you have any thought on this @jacobherrington ?
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.
Firstly, we probably want a feature spec to validate that onboarding works, going forward. That's something I'm happy to tackle in another PR.
Secondly, I think we should revert these changes in this PR and handle that in a new PR; I believe there are quite a few ways to address this and I'm not sure the Rails community has settled on one. Having it in a separate PR will allow us to merge this one and discuss it at length.
It's definitely a little weird to see snake case in JavaScript, but it's also weird to see camel case in Ruby.
I found an answer to this on SO, but I'm not sure it's the best route.
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'm going to dismiss my approval based on Mac's thoughts. We should probably approach this a bit differently.
checkedCodeOfConduct: false, | ||
checkedTermsAndConditions: false, | ||
emailMembershipNewsletter: true, | ||
emailDigestPeriodic: true, |
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 think we should avoid making these snake_case to camelCase changes in this PR and tackle it in another PR based on @maestromac's feedback. Would you mind undoing this change? I'd love to merge in the other linting changes.
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.
No problem at all, thanks for reviewing @jacobherrington! Resubmitting now.
16e1784
to
3d0a774
Compare
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.
Could we go ahead and undo all of the camel case changes? I'm still seeing some data not make it through the onboarding slides.
@@ -12,17 +17,17 @@ const SlideContent = ({ imageSource, imageAlt, content, style = { textAlign: 'ce | |||
{content} | |||
<p> | |||
<strong> | |||
<em>Let's get started...</em> | |||
<em>Let`'`s get started...</em> |
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.
location, | ||
employer_name, | ||
employment_title, | ||
employerName, |
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 information doesn't seem to be making it through, this probably needs to go back to snake case as well.
3d0a774
to
7d09618
Compare
Hi @jacobherrington, removed the additional camelCase changes, and the backticks as requested. |
Hi @jacobherrington just wanted to check in one more time - should I go ahead and close this PR at this point? |
Hey @daningenthron it looks like there are some conflicts. If you rebase this branch, we can see what changes should be merged. |
Sorry for letting this sit @daningenthron . I'm going to resolve the merge conflict and do the necessary work to get this merged. |
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!
Sorry that some of your lost work because the time this PR has been sitting 🙇
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 this got lost in the shuffle a little bit, but we are good to merge these changes imo.
Thanks for making this PR @daningenthron ❤️
Thanks so much @maestromac & @jacobherrington! Wasn't sure about moving this forward bc of the time and the refactor - thanks for finishing it up! |
What type of PR is this? (check all applicable)
Description
From #2470 - cleans up ESlint errors that weren't passing Husky. For the most part these were small edits (snake case to camel case etc), although two changes may need some attention:
EmailListTermsConditionsForm.jsx
contained adangerouslySetInnerHTML
warning that wouldn't pass; this has been bypassed by disabling the ESLint rule for this line. I think a better fix could be adding the DOMPurify dependency and sanitizing the HTML here and adding viainnerHTML
vsdangerouslySetInnerHTML
, but those changes didn't seem in line with this PR.In
SlideContent.jsx
I set up a blank (non-validating) shape for the style PropType. Not sure if this is best practice, but it seemed to make sense as far as trying to appease ESLint without defining the CSS attributes (and their types) ahead of time.Added to documentation?
[optional] What gif best describes this PR or how it makes you feel?
Hand pulling lint out of a lint trap in a single super-thick sheet