Add DRF endpoint and serializers for LocalAssets model

[smcalilly]

Overview

Adds DRF endpoints and serializers for saving local assets. There are no big UI changes, except for rendering a table in a django template. The table is not styled.

Notes

Some UX things we need to improve:

1. Reload the search results when an asset is saved, like how the previous version worked when the search was managed by query string params. This version reloads the page and clears the search results since the search is happening via ajax calls. This could be a frustrating UX. I have a couple ideas how to do this.
2. When a user searches assets that overlap existing assets, the searched geometries show up on the map and not the existing geometries. This could be confusing -- a user needs to know what assets they already saved.
   • This is probably best explained by witnessing firsthand. To recreate:
   • Search "red" and select "Trails".
   • Save a section of those trails
   • The page reloads and shows the saved trails
   • Search "red" and select "Trails" again.
   • The searched geometries override the existing geometries.

Need to address several UX issues that are already tracked in Github issues.

Need to delete assets from the table. We could also add this functionality to the map -- it would be cool to select an asset in the map and delete from there...wouldn't be too hard to implement.

Testing Instructions

• Visit review app: https://ccfp-asset-d-local-asse-klwnjy.herokuapp.com/projects/2/assets/
  • Login credentials in LastPass vault, "ccfp-asset-dashboard test user"
• Search for assets
• Select assets and save
  • Note that this map UX will change
• Make sure the geometries show up in the map and in the table
• Save assets via the API

[smcalilly]

@hancush great! thanks for all your help. it took a lot of work to get there, seems so minimal for how much it took.

re: notes. yes, please.

1. for the search reloading issue, do you think that's a necessary improvement? if so, which of these solutions: a. add the query string params to the url upon first search. if the component loads and the params are in the url, use that to construct the ajax call to populate the search b. save the geojson to session storage. if the component loads and there's an object in local storage, then use that to populate the search. session storage would "clear when the page session ends" so it would invalidate the cache.
2. for the overlapping assets, i think i could fix that with turf js in the frontend. do you have any issues with me doing that? or should we handle that on the backend?
3. for deleting assets, should use the DRF endpoint and submit an ajax form in the django template? or should i move that table into react and submit via ajax? or something else i'm missing?

[hancush]

@smcalilly

1. interesting ideas! i think i'm favoring session storage, unless we think it will be a common use case that users will want to share a link with a search param with another user?
2. down with a front end fix if it makes sense. if it turns out to be trouble, maybe you could use a filter in your asset search request that excludes asset ids of existing local assets?
3. i'm not sure i'm following. it seems like we'll be handling the request with ajax either way? does this boil down to whether you should render the table in react or the template?

[smcalilly]

@hancush

1. no, i don't foresee that being a use case.
2. filtering is a good idea. i might actually try that first, need to think on it.
3. yes, i guess the question there is, do we want to manage that table in react or a django template?

[hancush]

@smcalilly re: 3, case for django is simplicity, but react would be consistent... i'll leave that choice up to you.