-
-
Notifications
You must be signed in to change notification settings - Fork 407
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
Research Module - create/edit #1116
Conversation
Test summaryRun details
View run in Cypress Dashboard ➡️ This comment has been generated by cypress-bot as a result of this project's GitHub integration settings. You can manage this integration in this project's settings in the Cypress Dashboard |
Visit the preview URL for this PR (updated for commit 292b6c4): https://onearmy-next--pr1116-research-form-y2c0ejg8.web.app (expires Tue, 20 Apr 2021 23:02:55 GMT) 🔥 via Firebase Hosting GitHub Action 🌎 |
wauw again a super nice pull request! 💪 Not a coder myself, so can't comment to much on code, i'll leave that to @chrismclarke.
|
Thank you for testing it and for the valuable feedback!
I'll take a look at those bugs and commit fixes soon. |
|
SUPER neat. it passes all my tests 💪 |
@@ -32,7 +32,7 @@ export const EventCard = (props: IProps) => ( | |||
data-eventId={props.event._id} | |||
> | |||
{props.event.moderation !== 'accepted' && ( | |||
<ModerationStatusText event={props.event} top={'0px'} /> | |||
<ModerationStatusText moderable={props.event} kind="event" top={'0px'} /> |
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.
Good to see this refactored into a common component, I don't really understand what the word moderable
means, but I can see you inherited the code from others so definitely not blaming!
Would you have any suggestion for a word that makes more sense? maybe moderatedContent
or similar? Similarly we could change the word kind
to something a bit more specific (e.g. contentType
) to make things clearer for future devs.
But these are minor issues so I might just add a small comment myself to tidy in the future.
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.
Agreed, I was struggling to find a good name for this but definitely moderatedContent
and contentType
would be more describing names. Should I open a PR for this?
|
||
React.useEffect(() => { | ||
if (submissionHandler.shouldSubmit) { | ||
const form = document.getElementById('researchForm') |
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 react probably prefers when people use refs (https://reactjs.org/docs/refs-and-the-dom.html) instead of accessing dom directly, but I'm not aware of any issues doing it the vanilla way (the id is defined well enough to avoid multiple elements with the same id).
A bit more here: https://stackoverflow.com/questions/37273876/reactjs-this-refs-vs-document-getelementbyid
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 I was adapting some of the logic from the HowTo form, which used this approach. Definitely a future improvement to not access the DOM directly.
setTimeout(() => { | ||
loggedInUser = store.activeUser | ||
resolve() | ||
}, 3000), |
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 this is something you mentioned in your comments - agreed it's a pain to know whether there is no user or if they just haven't finished login initialisation after direct nav / page reload. This workaround is fine for now, I think there would probably be some better way long term to handle more generally but I'll create a separate issue for that (#1124)
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.
There's a huge amount here, which is really appreciated but also a bit tricky to review in depth. Overall the code looks really solid (I've added a few minor comments), so happy to merge. I think we can do some manual testing to check if everything is behaving as expected, and just make minor issues to fix anything as we come across it.
As the majority of the code is nicely encapsulated within the research module we can test most from that page, but for reference @davehakkens - there's also a few updates included to re-organise/re-use some of the content from howtos and events (specifically moderation status) - so will be good to double check that is still working as expected too.
PR Type
PR Checklist
master
branch mergedDescription
Adding create/edit research forms, and create research update form. A couple of notes:
Git Issues
Closes #1111
Screenshots/Videos