So NDC Oslo has come and gone, and whilst we wait for the videos for NDC Oslo to be available here are all the FP talks from NDC London this year.
It feels like a little while since I last played around with the <canvas> element, so I spent some time over the weekend and put together a simple painting app using the canvas and here is the end result.
Here’s some screenshots:
One of the interesting things with this simple painting app is the spray tool, here’s what I did to achieve the effect:
The startDrawing function is called when the mouseDown or a subsequent mouseMove event is raised, it in turn sets up an interval event which is triggered every 10 milliseconds and draws one pixel using the currently configured colour within the radius of the mouse pointer.
When the mouseUp event is raised, the interval event handler is unbound.
One of the cool things you can do with the <canvas> element is the ability to get a data:URL containing a representation of the image as a PNG file, which you can then use as the source for an <img> element so that the user can then save.
The code required to do this is as simple as calling toDataURL() on the <canvas> element and then use the returned value to set the src property on the <img> element.
If you’re interested in the source code, you can get it off github here.
For those of you who are familiar with Reactive Extensions you should know all about observables already, but did you know that there’s another kind of observable sequence – Rx.ConnectableObservable.
The difference between the two types of observable sequences is well explained here, in short, a connectable observable sequence allows you to share the same source sequence of values with multiple subscribers whilst the normal observable sequence gives each subscriber its own sequence of values. Whilst in most cases this difference doesn’t have any practical impacts as each subscribers are given the same values in the same order, however, consider this observable sequence of random numbers between 0 and 1000:
As you can see, each time the iterator is invoked it’ll generate a different value, hence subscribers will receive a different value each time (see demo below):
Instead, if you want to ensure that all the subscribers receive the same values, your best bet is to ‘publish‘ the source:
which returns you a connectable observable that you can then attach subscribers to:
and once you ‘connect‘ to the underlying source, the subscribers will start receiving values from the stream:
I wrote previously about how you can set up multiple observable sequences and subscribe to them with multiple observers and create a many-to-many relationship between them.
Whilst this is a very flexible model with a clear separation of responsibilities, often it requires more work to set up and is more than what you need for the task at hand. For instance, if you’re receiving a steady stream of inputs and want to log the arrival of new inputs as well as performing some aggregation on them, you don’t necessarily have to create two subscribers for the input but instead make use of the Rx.Observable.Do function.
Like the Rx.Observable.Subscribe function, the Do function can take a subscriber, or two up to three function objects to handle the onNext, onError and onCompleted events, in that order. Unlike the Rx.Observable.Select function, it doesn’t have a return value and therefore won’t allow you to transform the input stream, it’s intended purely for causing side effects.
I’ve put together a quick demo (see below) to illustrate the use of the Do function in conjunction with other common RxJS functions such as Select and Where. For this demo we just need two <span> elements, one to show the running total, the other to show a log message every time a new value is received:
Couple of things to note here:
If you are lucky enough (or unlucky enough depending on which scenario you’re trying to test) just refresh the page and try again and hopefully you have better luck the second time around!
Unfortunately, there wasn’t a live demo you can play around with and see it work, and since the article was posted things might have changed and doing cross-domain HTTP requests are no longer a straightforward affair (at least not when it comes to Chrome and Firefox). If you had tried to piece together all the bits of code snippets from the article you might find that it only works in IE but not in Chrome or Firefox.
So I decided to put together a working demo, and with that, let’s start with the HTML from the original example:
Key things to note here:
The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.