Summary:

Users can view a list of all campsites and submit new campsites for approval.

This pull request currently fulfills most of the features described in issue 5358 to simplify the management of campsites, but the features related to user data have not been implemented yet.

A few outstanding questions are listed in the Questions section.

Implementation:

The implementation is a React app and is modeled after the Jobs and Hikes apps. The main changes outside the common/app/routes/Campsites app are:

• Two new routes were added:

  • /campsites - campsite list and map
  • /campsites/new-campsite - add a new campsite

• One model was added:

  • campsite

• One service was added:

  • campsites - with read, create, and update methods

• One dependency was added to package.json:

  • react-google-maps - This library takes care of asynchronously loading and rendering the maps used to display and search for campsites.

Security:

• User Input: User input is sanitized like in the Jobs app.
• Campsite Model API Routes: These are currently public, but not used in the app. These might be helpful for a bulk upload script (described in question 5 below), but could be closed to prevent working around moderation.
• allowExtendedOperators: This is set to true in the campsites model to allow update operations, but could be scoped to the specific update requests coming from the campsites service if this is a concern.
• Trusted Script Sources: Added maps.googleapis.com to trusted script souces

State:

App state are all observables in the appStore.

I had some issues with successive navigations between the campsites and campsites/new-campite pages (Campsites and CreateCampsite containers) using the <LinkContainer>'s to property that I believe were related to state management, and it ended up being simpler to trigger a refresh between these pages with a tags.

Questions:

1. Accessing user data: I wasn't clear on the best way to access user data, and haven't implemented the three stories in question 2 yet. Is the user service the best way to access this data?
2. Using user data: The requirements described three features that required accessing user data:
   • a: Only moderators can review pending campsites: Is there a property in the user model that should determine this behavior?
   • b: Moderators are notified on new campsite submits: Should this be emails? An icon on a different screen (i.e. not just on /campsites)? Is there anything in the code base currently doing similar notifications?
   • c. The user creating a new campsite is tracked in the DB: The username is returned from the user service, but not the ID of the Mongo record. Which makes more sense to store in the campsite object?
3. Campsite location formatting: The city/subdivision coming back from Google Maps is not standardized across countries or locations selected - this is a surprisingly hard problem and I haven't found a good solution that could handle all cases. A moderator can change the display values to fill in missing information or give more appropriate names, but the user uploading the campsite currently cannot.
   • a: Should users have the ability to set a Display Name they want to use for their campsite instead of the relying on the city?
   • b: Should users figure out and edit the subdivision/city for locations with missing info or rely on moderators?
4. API key for Google Maps: The key is hardcoded to an app I registered. Should this be updated to a FCC key?
5. Bulk upload of existing campsites: The wiki page and the CSV behind this map have some info about the location and the facebook URL. With some massaging, it could be parsed into a format for doing a lookup for the rest from the Google Maps API. Should I try to do a bulk upload upload of the existing campsites?
6. Updating approved campsites: After a campsite has been approved, updates are only possible from the API or a mongo client on the production db. Otherwise the campsite would need to be deleted, and recreated with the updated information. Is this a use case that should be addressed in the UI?
7. Creating campsites on mobile: Testing creating a new campsite on iOS, the input to the search box wasn't populating locations to select from. Is creating campsites on mobile a requirement?
8. updateService: There was not an existing updateService and added one to FreeCodeCamp/common/app/Cat.js for update operations. Is this a reasonable approach?

closes #5358

We're currently moving to Redux, so this PR will need to be refactored once #7214 is merged in.

Sounds good @BerkeleyTrue

@geoff616 updated the pull request.

@geoff616 You'll need to rebase instead of merging. And it should probably wait until that pr is merged into staging as there may still be changes.

@geoff616 updated the pull request.

Thanks @BerkeleyTrue, just rebased against latest staging. Will start moving over to redux.

@geoff616 updated the pull request.

Moved over to redux, and have most of the functionality working again. Still need to add input validation, implement the user related requirements and clean things up.

Currently a little stuck on keeping redux and the DB in sync on update operations, and haven't found a way to get this working yet.

@geoff616 updated the pull request.

@geoff616 updated the pull request.

@geoff616 updated the pull request.

@geoff616 updated the pull request.

Have all the functionality working again in redux, and added in the user features.

Wrote some scripts to migrate the MD file with the campsites into the DB. After uploading the 1,100+ campsites, the responsiveness of the app dropped significantly, and I'm looking into ways of making it less janky with that much data.

Also working through a bug, where edits to existing campsites are not re-rendering correctly. Asked for some help on SO, and waiting to see what they think.

Going to fix the above issues and will rewrite the info at the top to reflect the changes to the PR.

Thanks for the PR. I'm doing a lot of work on moving over the rest of the site to React so I've not been able to give this PR the attention it deserves. From a cursory examination, the code looks solid, but those issue you described will definitely need to be tackled.

Thanks @BerkeleyTrue. Made some progress on resolving those issues, but still working through a few bugs. Should have the PR updated by the end of the week, and happy to revisit when it makes sense.