From 87003e214eca7aafa3bf322cf2623afcbfd98716 Mon Sep 17 00:00:00 2001 From: Victor Feyens Date: Thu, 7 Feb 2019 16:32:01 +0000 Subject: [DOC] batch of UI, Https, linter corrections --- doc/reference/javascript_cheatsheet.rst | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) (limited to 'doc/reference/javascript_cheatsheet.rst') diff --git a/doc/reference/javascript_cheatsheet.rst b/doc/reference/javascript_cheatsheet.rst index 97f7ba5cb5c..b6c5251c46c 100644 --- a/doc/reference/javascript_cheatsheet.rst +++ b/doc/reference/javascript_cheatsheet.rst @@ -1,5 +1,7 @@ :banner: banners/javascript.jpg +.. _reference/jscs: + ===================== Javascript Cheatsheet ===================== @@ -280,6 +282,7 @@ using the view in the kanban arch (a specific example is the helpdesk dashboard) Promises and asynchronous code =============================== + For a very good and complete introduction to promises, please read this excellent article https://github.com/getify/You-Dont-Know-JS/blob/master/async%20%26%20performance/ch3.md Creating new Promises @@ -418,6 +421,7 @@ Waiting for Promises Error handling -------------- + - in general in promises The general idea is that a promise should not be rejected for control flow, but should only be rejected for errors. When that is the case, you would have multiple resolutions of your promise with, for instance status codes that you would have to check in the `then` handlers and a single `catch` handler at the end of the promise chain. @@ -540,4 +544,4 @@ Testing asynchronous code }); }); - as you can see, the nicer form is to use `async/await` as it is clearer and shorter to write. \ No newline at end of file + as you can see, the nicer form is to use `async/await` as it is clearer and shorter to write. -- cgit v1.2.3