Details
This task will be futher tested in subsequent diffs. I was also able to like/unlike messages in web in my local stack using this hook and some subsequent diffs
Additionally, here is what the Alert looks like if a message fails to go through
Diff Detail
- Repository
- rCOMM Comm
- Lint
No Lint Coverage - Unit
No Test Coverage
Event Timeline
web/chat/reaction-message-utils.js | ||
---|---|---|
42 | On web we usually use pushModal instead and show something like eg. ConcurrentModificationModal. We don't currently have any usages of alert in the web codebase Can you either:
Not trying to slow you down but I think we should think this through |
web/chat/reaction-message-utils.js | ||
---|---|---|
42 |
No definitely this is a good shout. Just updated the test plan to show what alerts look like in Chrome, Firefox and Safari. If we don't think alerts are a good user experience, will be happy to update the code based off the existing web conventions |
Safari looks good but the others look really bad... I think we should probably stick with the current pattern
web/chat/reaction-message-utils.js | ||
---|---|---|
51 ↗ | (On Diff #20257) | We should still throw e... otherwise we implicitly return undefined (wish we had an ESLint rule that forced these to be explicit), and as a result will dispatch a _SUCCESS action with an undefined action.payload, instead of a _FAILED action with the exception info |
I think the wording here may be a bit confusing. In my experience, 'cancel' typically means close the alert, and there's another option like 'confirm' or something that will mean you're ok with discarding changes.
Here it seems like 'cancel' means we're ok with discarding changes. Not sure if it's just me though (cc @ted)