* Client/server data adapter and simpler data passthroughs.
* Parse error response and pipe to UI
* Add top-of-form error display for social links
* Remove save failed state from save button
* Remove object deconstruction in catch
* Fixing a few small bugs.
* When opening and closing forms, remove drafts.
* Tweak where we send account_privacy back to
* Passing course cert visibility through.
* Fixin’ up the tests.
* Documenting weird social links behavior.
* More comments.
This PR rewires how our forms get their data. It also folds in changes from #35 because @abutterworth and I had a pretty hefty conflict between our two branches.
This turned into a broader effort than I intended, admittedly.
The original goal was to take our form state out of component state and put it into redux state for all six forms on the profile page. This has been done, but doing so begged a bit of broader refactoring and renaming as well.
In no particular order:
1. We were referring to our forms as fields - that language has been fixed. They're forms now.
2. We were putting 'draft' form values in component state - that state has been moved up to the redux level.
3. The fetchProfile action is now responsible for making several underlying calls to the system for the profile's account information, preferences (if it's your own account), and certificates. Before, we had multiple actions responsible for each part, and coordination was hard.
4. `react-router-redux` has been replaced with `connected-react-router`. This is admittedly not something that ultimately needed to be in this PR - I _thought_ I was going to need it, but after the work was done, the need for the change fell out and it's essentially unrelated. That said, `react-router-redux` is deprecated and no longer supported, and `connected-react-router` has taken its place. I didn't see any reason to throw away the work, so here it is.
5. I updated some packages as part of number 4 above which didn't strictly need to be updated. I _thought_ I needed to update them w/r/t changing the router, but I didn't. As above, didn't see any reason to throw away the work, though.
6. Introduced `reselect` to handle derived state. This helps keep components clean.
7. Directly connected the forms to the store. This makes ProfilePage.jsx a lot cleaner.
8. The ProfilePage.jsx file still manages calling action creators to put stuff in redux - the forms are connected for their data, but are otherwise "dumb" about how the data gets back into redux. It felt weird, for instance, to have the Name.jsx component call an action creator called `saveProfile`... just seemed above its pay grade. Admittedly this is a bit asymmetrical, but it allowed ProfilePage.jsx to be a lot shorter/have less responsibility for passing data down.
Realigning and simplifying directories and naming.
- Combining “containers” into “components”.
- Flattening out “data” into “reducers” and “config” to consolidate configuration-like files in one place and to make reducers a peer of its teammates (components, actions, sagas, and services).
- Creating dev/prod-specific redux configurations.
- Converting “index.jsx” files into files named for their contents.
- Splitting up the top-level “index.jsx” file into an entry point and an “App” component.
- Renaming SCSS file to “index.scss” to keep it consistent with where it’s imported.
- Renaming/simplifying some variables.
This PR has a refactoring of our actions/sagas/services. Rather than continue to put profile-related API actions into the frontend-auth project, we decided (against prior decision) to put them in this app, as that feels more correct, long term. This also let us unroll the service creation and decouple the services from the components.
The “fetchProfile” API is hitting the same ‘accounts’ API as fetchUserAccount from frontend-auth. This is an intentional abstraction for clarity of purpose and assuming they may diverge. It also lets us group all the profile app’s API methods together, letting the ‘session’ API stay in frontend-auth.
We also decided to do some renaming:
- “user profile” -> “profile” cause there’s no other type of profile here.
- The saga handlers are prefixed with “handle”
- The API methods use proper HTTP verbs.
- The actions keep fetch and save as verbs as they’re clearer in components than “get” and “patch”
- The goal here is to differentiate different parts of the code, making it easier to remember where you are.
