Mailspring/static/components/spinner.less

62 lines
1 KiB
Plaintext
Raw Normal View History

@import "ui-variables";
.spinner {
margin: 0;
width: 94px;
text-align: center;
opacity: 1;
transition: opacity 0.2s linear;
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
pointer-events: none;
}
.spinner.hidden {
opacity: 0;
}
.spinner.paused {
> div {
// important. animating with opacity 0 chews up about 5% cpu
animation-play-state: paused;
}
}
feat(salesforce): add Salesforce creator Summary: tests on the schemas build input elements form builder pulls data grouping by row salesforce object store salesforce api logic successfully pulling salesforce objects into db object store saving to db refactoring tokenizing text field full documented tokenizing text field with specs linking in object picker component converting generated form to a controlled input form change handlers for controlled inputs Salesforce object creator store new way of opening windows removed atom.state.mode create new salesforce object creator in new window form creator loading in popup with generated form generated form renders select and multiselcet and textarea add checkbox creating related objects windnows know when others close remove debugger statements form submission converting data for salesforce posting hot window loading new hot window registration hot loading windows actions for listening to salesforce objects created generated form errors error handling for salesforce object creator rename saleforce object form store display errors to form submitting state passed through properly posts objects to Salesforce change name to salesforce object form add deep clone use formItemEach styling for Salesforce form creator salesforce required fields come back and populate form generated form loads related objects into fields remove console logs and fix sales schema adapter test fix task queue and formbuilder specs fix action bridge spec fix tokenizing text field spec fix draft store and tokenizing proptypes fix linter issues fix tokenizing text field bug rename to refresh window props remove console.log Test Plan: edgehill --test Reviewers: bengotow Reviewed By: bengotow Differential Revision: https://review.inboxapp.com/D1425
2015-04-25 00:36:19 +08:00
.spinner-cover {
&.hidden {
opacity: 0;
}
}
.spinner > div {
width: 14px;
height: 14px;
border-radius: 100%;
border: 1px solid @gray-light;
display: inline-block;
animation: bouncedelay 1.1s infinite cubic-bezier(0.45, 0.05, 0.55, 0.95);
/* Prevent first frame from flickering when animation starts */
animation-fill-mode: both;
margin-right:4px;
margin-left:4px;
}
.spinner .bounce1 {
animation-delay: -0.34s;
}
.spinner .bounce2 {
animation-delay: -0.22s;
}
.spinner .bounce3 {
animation-delay: -0.12s;
}
.spinner .bounce4 {
animation-delay: 0s;
}
@keyframes bouncedelay {
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
0%, 80%, 100% {
transform: scale(0.0);
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
} 40% {
transform: scale(1.0);
}
feat(salesforce): add Salesforce creator Summary: tests on the schemas build input elements form builder pulls data grouping by row salesforce object store salesforce api logic successfully pulling salesforce objects into db object store saving to db refactoring tokenizing text field full documented tokenizing text field with specs linking in object picker component converting generated form to a controlled input form change handlers for controlled inputs Salesforce object creator store new way of opening windows removed atom.state.mode create new salesforce object creator in new window form creator loading in popup with generated form generated form renders select and multiselcet and textarea add checkbox creating related objects windnows know when others close remove debugger statements form submission converting data for salesforce posting hot window loading new hot window registration hot loading windows actions for listening to salesforce objects created generated form errors error handling for salesforce object creator rename saleforce object form store display errors to form submitting state passed through properly posts objects to Salesforce change name to salesforce object form add deep clone use formItemEach styling for Salesforce form creator salesforce required fields come back and populate form generated form loads related objects into fields remove console logs and fix sales schema adapter test fix task queue and formbuilder specs fix action bridge spec fix tokenizing text field spec fix draft store and tokenizing proptypes fix linter issues fix tokenizing text field bug rename to refresh window props remove console.log Test Plan: edgehill --test Reviewers: bengotow Reviewed By: bengotow Differential Revision: https://review.inboxapp.com/D1425
2015-04-25 00:36:19 +08:00
}