Mailspring/internal_packages/worker-ui/lib/developer-bar-task.cjsx

61 lines
1.9 KiB
Plaintext
Raw Normal View History

React = require 'react/addons'
classNames = require 'classnames'
_ = require 'underscore'
{Utils} = require 'nylas-exports'
class DeveloperBarTask extends React.Component
@displayName: 'DeveloperBarTask'
constructor: (@props) ->
@state =
expanded: false
render: =>
details = false
if @state.expanded
# This could be a potentially large amount of JSON.
# Do not render unless it's actually being displayed!
details = <div className="task-details">{JSON.stringify(@props.task.toJSON())}</div>
<div className={@_classNames()} onClick={=> @setState(expanded: not @state.expanded)}>
<div className="task-summary">
{@_taskSummary()}
</div>
{details}
</div>
shouldComponentUpdate: (nextProps, nextState) =>
return not Utils.isEqualReact(nextProps, @props) or not Utils.isEqualReact(nextState, @state)
_taskSummary: =>
qs = @props.task.queueState
errType = ""
errCode = ""
errMessage = ""
if qs.localError?
localError = qs.localError
errType = localError.constructor.name
errMessage = localError.message ? JSON.stringify(localError)
else if qs.remoteError?
remoteError = qs.remoteError
errType = remoteError.constructor.name
errCode = remoteError.statusCode ? ""
errMessage = remoteError.body?.message ? remoteError?.message ? JSON.stringify(remoteError)
return "#{@props.task.constructor.name} #{errType} #{errCode} #{errMessage}"
_classNames: =>
qs = @props.task.queueState ? {}
classNames
"task": true
"task-queued": @props.type is "queued"
"task-completed": @props.type is "completed"
"task-expanded": @state.expanded
"task-local-error": qs.localError
"task-remote-error": qs.remoteError
"task-is-processing": qs.isProcessing
feat(offline-mode, undo-redo): Tasks handle network errors better and retry, undo/redo based on tasks Summary: This diff does a couple things: - Undo redo with a new undo/redo store that maintains it's own queue of undo/redo tasks. This queue is separate from the TaskQueue because not all tasks should be considered for undo history! Right now just the AddRemoveTagsTask is undoable. - NylasAPI.makeRequest now returns a promise which resolves with the result or rejects with an error. For things that still need them, there's still `success` and `error` callbacks. I also added `started:(req) ->` which allows you to get the underlying request. - Aborting a NylasAPI request now makes it call it's error callback / promise reject. - You can now run code after perform local has completed using this syntax: ``` task = new AddRemoveTagsTask(focused, ['archive'], ['inbox']) task.waitForPerformLocal().then -> Actions.setFocus(collection: 'thread', item: nextFocus) Actions.setCursorPosition(collection: 'thread', item: nextKeyboard) Actions.queueTask(task) ``` - In specs, you can now use `advanceClock` to get through a Promise.then/catch/finally. Turns out it was using something low level and not using setTimeout(0). - The TaskQueue uses promises better and defers a lot of the complexity around queueState for performLocal/performRemote to a task subclass called APITask. APITask implements "perform" and breaks it into "performLocal" and "performRemote". - All tasks either resolve or reject. They're always removed from the queue, unless they resolve with Task.Status.Retry, which means they internally did a .catch (err) => Promise.resolve(Task.Status.Retry) and they want to be run again later. - API tasks retry until they succeed or receive a NylasAPI.PermanentErrorCode (400,404,500), in which case they revert and finish. - The AddRemoveTags Task can now take more than one thread! This is super cool because you can undo/redo a bulk action and also because we'll probably have a bulk tag modification API endpoint soon. Getting undo / redo working revealed that the thread versioning system we built isn't working because the server was incrementing things by more than 1 at a time. Now we count the number of unresolved "optimistic" changes we've made to a given model, and only accept the server's version of it once the number of optimistic changes is back at zero. Known Issues: - AddRemoveTagsTasks aren't dependent on each other, so if you (undo/redo x lots) and then come back online, all the tasks try to add / remove all the tags at the same time. To fix this we can either allow the tasks to be merged together into a minimal set or make them block on each other. - When Offline, you still get errors in the console for GET requests. Need to catch these and display an offline status bar. - The metadata tasks haven't been updated yet to the new API. Wanted to get it reviewed first! Test Plan: All the tests still pass! Reviewers: evan Reviewed By: evan Differential Revision: https://phab.nylas.com/D1694
2015-07-08 01:38:53 +08:00
"task-success": qs.localComplete and qs.remoteComplete
module.exports = DeveloperBarTask