Skip to content
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

Merged
merged 11 commits into from
Aug 29, 2021
Merged

Conversation

darrenvong
Copy link
Member

@darrenvong darrenvong commented Aug 23, 2021

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:

Screenshot 2021-08-24 at 01 11 36

Also added a new "edit event" button that's only visible to users with edit or community moderation permissions:
Screenshot 2021-08-24 at 01 11 04
Screenshot 2021-08-24 at 01 11 16

Frontend checklist

  • Formatted my code with yarn format && yarn lint --fix
  • There are no warnings from yarn lint
  • There are no console warnings when running the app
  • Added any new components to storybook
  • Added tests where relevant
  • All tests pass
  • Clicked around my changes running locally and it works
  • Checked Desktop, Mobile and Tablet screen sizes

@darrenvong darrenvong requested a review from a team August 23, 2021 03:46
@darrenvong darrenvong added 2.has feature (new) Implementation of a feature 1.topic frontend labels Aug 23, 2021
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.
@darrenvong darrenvong force-pushed the frontend/feature/edit-event-page branch from 234bd80 to 7f5c21e Compare August 23, 2021 03:53
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).
@darrenvong darrenvong force-pushed the frontend/feature/edit-event-page branch from 8ff7df0 to 54a5a4c Compare August 23, 2021 23:19
@darrenvong darrenvong marked this pull request as ready for review August 23, 2021 23:19
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.
@darrenvong darrenvong force-pushed the frontend/feature/edit-event-page branch from b34521b to 2bb1ecd Compare August 23, 2021 23:46
@@ -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",
Copy link
Member Author

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

Comment on lines +230 to +231
jest.useFakeTimers("modern");
jest.setSystemTime(new Date("2021-08-01 00:00"));
Copy link
Member

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.

Copy link
Member Author

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

Comment on lines +109 to +123
{({ isMutationLoading }) => (
<>
<Button
className={classes.submitButton}
loading={isMutationLoading}
type="submit"
>
{CREATE}
</Button>
<Typography className={classes.disclaimer} variant="body1">
{CREATE_EVENT_DISCLAIMER}
</Typography>
</>
)}
</EventForm>
Copy link
Member

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.

Copy link
Member Author

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.

Copy link
Member

@lucaslcode lucaslcode left a 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.

@darrenvong
Copy link
Member Author

Changing an event from offline to online doesn't move it to the global community.

I think that's also a backend flaw. Currently UpdateEventReq doesn't allow a parentCommunityId to be specified, so the API will need to be updated to allow that too. Otherwise the current workaround would be an additional API call to TransferEvent

@darrenvong
Copy link
Member Author

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?

@darrenvong darrenvong merged commit b6bf022 into develop Aug 29, 2021
@darrenvong darrenvong deleted the frontend/feature/edit-event-page branch August 29, 2021 21:58
@darrenvong darrenvong added the release notes: pending Add to stuff that should be included in release notes label Aug 29, 2021
@darrenvong darrenvong mentioned this pull request Aug 29, 2021
8 tasks
@aapeliv aapeliv added release notes: done Was mentioned in release notes and removed release notes: pending Add to stuff that should be included in release notes labels Aug 31, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
1.topic frontend 2.has feature (new) Implementation of a feature release notes: done Was mentioned in release notes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants