State: Move keyring data to redux. #8729
Conversation
| @@ -0,0 +1,29 @@ | |||
| export const itemSchema = { | |||
| type: 'object', | |||
There was a problem hiding this comment.
Could we maybe put additionalProperties at the top, so it's easier to match with patternProperties?
| type: { type: 'string' }, | ||
| user_ID: { type: 'integer' }, | ||
| }, | ||
| additionalProperties: false |
There was a problem hiding this comment.
I don't believe we need to be so strict here. We might have an additive change to the api that isn't yet used by the client. In that case this would throw out the persisted data needlessly.
| @@ -0,0 +1,103 @@ | |||
| Keyring Connections | |||
| =================== | |||
obenland
added
[Status] Needs Review
| } | ||
| } | ||
|
|
||
| render() { return null; } |
There was a problem hiding this comment.
eslint warning for statements inside of curly braces needing to be on the next line.
|
Alright I tested out I left a few minor notes, but should be good to 🚢 |
Closer mimics the `wpcom.undocumented` API on this, it’s also closer to how this action will be used later.
|
Thanks for your feedback @gwwar, should be fixed now! Should I wait with merging until someone sets it to "Ready to merge"? |
|
LGTM! If it's a riskier PR, you can ask for more 👀 on additional changes. Otherwise if the last reviewer just requested a few minor things with a 👍, it's usually ok to 🚢 |
gwwar
added
[Status] Ready to Merge
and removed
[Status] Needs Review
First step in redux-ifying the rest of the sharing module, including
connections-listand all components that use it.Stores keyring connections in its own redux store (previously
ConnectionsList.keyringData), in parallel tosharing.publicize(previouslyConnectionsList.siteData). It adds action creators to create, update, and delete a connection, with corresponding reducers in bothsharing.keyringandsharing.publicize, as well as the infrastructure to manage keyring connections.See #5046.