Reactive programming for javascript

4,517 views
4,440 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
4,517
On SlideShare
0
From Embeds
0
Number of Embeds
473
Actions
Shares
0
Downloads
14
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Reactive programming for javascript

  1. 1. Yann Schwartz - Polom Pierre Couzy – Microsoft WebWorkersCamp, 30/10/2010
  2. 2. Yann :  .Net heretic (@abolibibelot)
  3. 3. Pierre :  Worked in the Microsoft space for 20 years  Speaker, trainer, developer, architect, …  Primarily interested inWeb topics  Identity, architecture,WS-*, interop, cloud, …  Recent interop/OSS activity  Worked on drupal for Sql server project  Works on automated drupal testing onWindows  Speaker at major PHP events ▪ DrupalCon, PHP Forum, Symfony live blog.couzy.com / pierre.couzy@microsoft.com
  4. 4. A little syntactic sugar can help you think along the right lines
  5. 5.  C# is an imperative language  Which is nice  Except for a few things  Splitting data manipulation between your code and your data store  Coding data manipulation  Applying new manipulation patterns to existing data
  6. 6.  Express more intent, less implementation  Easy composition  Strong typing  This is subject to hot debate  .. And out of scope today  Be as declarative as possible within the limits imposed by an imperative language
  7. 7.  Lazy evaluation  If we step into this code, we see LINQ triggers its magic on demand  Easy composition  If we add new clauses after the LINQ expression is built but before it’s consumed, we simply merge the additions to the existing expression  So far, we’ve worked on objects  Which is how many naive LINQ implementations work : synchronously pipelining methods calls on collections  LINQ has a lot more to it  But this not on our todo today
  8. 8. A lazy,pull-based,composable pattern for data manipulation And we get
  9. 9.  Imperative synchronous programming was hard enough to call for LINQ  And yet we’ve been doing this for decades  Event-based (or async) patterns are a complete mess today  Unconvinced ? Let’s see…
  10. 10.  We were pulling data from an enumerable  We will push data from an observable  We were lazy (doing just in time)  We will receive data as a stream (just in time)  We were composable  We’ll stay that way
  11. 11.  It’s a source  Our code will subscribe to that source  Duh, difference with an event handler ?  Observable sequences are first-class constructs  Provide a layer of abstraction  Much better for testing  Allows for much more scenarios
  12. 12.  A sequence is more than a list of ..  It can fail  It can end  The observer , when it subscribes, can subscribe to those three conditions
  13. 13.  Observables allow you to manipulate a chronology of events as a list.  And we can apply operators to lists.  This is called a workflow.
  14. 14.  LINQ describes an iteration workflow (pull- based), with composition, so that the implementation does not obfuscate the intention,  Rx describes an event-based workflow (push- based), with composition, so that the implementation does not obfuscate the intention.

×