Github user benkeen commented on the pull request:
https://github.com/apache/couchdb-fauxton/pull/475#issuecomment-137264706
Hey Robert, Iâve updated a few things. I started working through the
whole scenario of moving the callbacks for the ConfirmationModal into a store,
but abandoned it once I saw how much more complicated + klutzy it was going to
be. :(
Let me explain. Say we remove the onClose and onSubmit props and get the
confirmation modal to posts its own generic âsubmitâ & âcloseâ events
as we discussed. The confirmation modalâs store would then listen to those
events and set some corresponding values internally (`_isSubmitted`,
`_isClosed`, say). The component thatâs using `<ConfirmationModal />` would
then have something like an `isSubmitted: store.isConfModalSubmitted()` prop in
its own state. Then, in componentWillUpdate (I guess?) It would have detect for
the change, then actually reset the âisSubmittedâ value in the store
immediately afterwards, like so:
```javascript
componentWillUpdate: function (nextProps, nextState) {
if (!this.state.isSubmitted && nextState.isSubmitted) {
ComponentAction.doSomething();
FauxtonAction.resetConfModalSubmitted(); // this would
ultimately reset _isSubmitted in the
}
}
```
Is there a better approach, do you think? I guess we could remove the
`FauxtonAction.resetConfModalSubmitted()` call by having a â_numSubmittedâ
counter in the store and use that to determine when in the parent component to
actually submit - but this all feels tremendously hacky to me compared to the
original approach of just passing in callbacks via props.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
