Recently, we discussed the behavior of Promise.finally in our development team. Even after reading the official documentation, we weren't unanimous on what will happen in certain cases. In the end, I wrote a couple of test cases to make sure about it.
The Promise.catch method is a convenient tool for handling errors anywhere inside the promise chain up to the method call. However, care must still be taken when writing the chained code inside the Promise.then method, otherwise some errors might not be properly handled.
Logging to browser console can be a useful tool for troubleshooting Ionic applications during development. Although all the logging is still done in test builds, the process of getting the log from the device is not tester-friendly. Without too much effort this experience can be improved a lot by adding an option to export the log directly from the application.
Promises make it easy to handle errors in asynchronous method calls. The rejection handler can be used to log full error details from a rejected promise. It will also catch any errors that might happen in the fulfillment handler. However, the Error object details might not get logged as you would expect.
When trying to capture camera video from browser using MediaDevices.getUserMedia, user consent is required. On first call the browser will show a dialog to the user who can either allow or block access to the camera. It might be useful to have some analytical data for your application on how many users blocked the camera access, but unfortunately there's no direct way to detect from code when the dialog was shown and how the user answered.
In modern HTML 5 browsers you can render video from your camera inside a web page using the video element. However, to further process the captured video or add some custom rendering on top of it, the canvas element needs to be used. Due to the ever changing APIs in this field, it's not easy to find up-to-date working sample code for achieving this.
Having unit tests usually drastically reduces the need for interactive debugging. However, being able to debug unit tests can sometimes prove very useful. Nowadays, any browser includes a fully featured debugger as part of its developer tools, and Karma test runner has a dedicated feature for in-browser debugging. I wrote short instructions on how exactly to use this feature for a project I am working on.
If you're looking for a book to learn SignalR from, you can't go wrong with this one. On the other hand, if you're already fluent in SignalR and just want to learn more, it probably isn't your best choice, unless you're interested in one of the above mentioned topics.
Since gadgets are HTML applications and the Windows Sidebar uses Internet Explorer 7 to render them, I prefer running their code directly in IE7 during development.
I've gathered few issues that could be covered better in the documentation since I've been struggling with them for some time before I got everything to work as expected.
I though I'd gather in one place all the useful links I found with information on development of Windows Sidebar gadgets.