-
Notifications
You must be signed in to change notification settings - Fork 77
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
Events part 6: edit event page #1862
Conversation
In preparation for it to be re-used in edit event page
Create event form will largely remain unaware of this change Also did a tiny refactor to make the submit button area more flexible, in order to decouple the event form UI from messy logic to determine whether to show the create or update variant and defers that responsibility back to the parent page instead.
234bd80
to
7f5c21e
Compare
Fixed edge case where event value is not populating form if user visits the page directly by delaying rendering of form until the query has loaded. This is because the event wouldn't have been in cache yet if user goes to the edit event form directly, and so form would use an undefined event for first render (as if it's creating a new one).
8ff7df0
to
54a5a4c
Compare
The TZ=UTC flag might have broken it? Anyway I think it's a good introduction to stop us worrying about timezone differences between our computer and CI.
b34521b
to
2bb1ecd
Compare
@@ -33,11 +33,11 @@ | |||
"scripts": { | |||
"start": "react-scripts start", | |||
"build": "CI=true react-scripts build", | |||
"test": "react-scripts test", | |||
"test": "TZ=UTC react-scripts test", |
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.
Wish I found this out earlier for ensuring the timezone used is the same across our computer and CI. The timezone mock thing has been causing me pain for a while as it'd error with something about unknown Date constructor as soon as I need to interact with the date inputs/dayjs.
This seems like the only solution that works by changing the test timezone to UTC with fake timers to "fix" the current date so our test data would work/pass date validation etc
jest.useFakeTimers("modern"); | ||
jest.setSystemTime(new Date("2021-08-01 00:00")); |
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.
Move to beforeAll on line 211? Else adding a second test in this describe method will still have this system date. Or not yet have this system date if the second test was executed before this test that sets the system date.
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 is specifically placed here (after the location click from LocationAutocomplete
on line 225-226) since it has the same problem as the other test - that the msw
server doesn't respond when the fake timers are on. I probably could leave a comment here too.
As for the concern that this will break things if we add more tests here, I could move the jest.useRealTimers()
to an afterEach
instead so it will correctly reset the timer after every test
app/frontend/src/features/communities/events/CreateEventPage.test.tsx
Outdated
Show resolved
Hide resolved
{({ isMutationLoading }) => ( | ||
<> | ||
<Button | ||
className={classes.submitButton} | ||
loading={isMutationLoading} | ||
type="submit" | ||
> | ||
{CREATE} | ||
</Button> | ||
<Typography className={classes.disclaimer} variant="body1"> | ||
{CREATE_EVENT_DISCLAIMER} | ||
</Typography> | ||
</> | ||
)} | ||
</EventForm> |
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 a big deal but to me this seems more opaque than a required submitButton
prop.
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 thought about using an explicitly named prop than using children
, but since this is literally appearing at the bottom of the form, it fits naturally enough with composition for me in this case.
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.
Changing an event from offline to online doesn't move it to the global community.
Also, there's a backend bug - changing something other than the date gives an error about not being allowed to have overlapping occurrences.
I think that's also a backend flaw. Currently |
Also moving the event from online to offline to a different community (going from what you said) is also technically impossible at the moment, as all events will originate from the global community in those cases and there's no way for the frontend to figure out which community a location belongs to... but I guess that logic's kinda broken anyway since we are allowing events to be created in locations that might not match with where the community say it is. So maybe it doesn't make much sense to move an event to the global community because it's going from offline to online? Or are we allowing it anyway as a non-reversible thing? |
This is probably the final piece for the MVP of #541. It looks more or less identical to the "create event page" since they share the same form UI. This has been intentional with how I put the form UI into its own component:
Also added a new "edit event" button that's only visible to users with edit or community moderation permissions:
Frontend checklist
yarn format && yarn lint --fix
yarn lint