Woohoo! I've read the book... and while I've only absorbed like 40% of it - the ideas are exciting, and I'm hoping the other 60% will, erm, sink, in as I start putting it into practice. I have no doubt that some of my questions will be answered simply by starting to write code, but along with that I'd like to pick your brain(s) to address some of the newbie birds-eye-view stuff that's holding me back from diving in deep...
1) Are streams cheap (or rather - where to place sinks)?
Specifically - with a rendering engine like PIXI.js where lots of sprites are created and each one does its own internal checking for things like touch presses. I get that it would likely be better to check those things globally - but in a situation like this that might not be advantageous for other reasons (e.g. the engine itself culls away irrelevant hits, etc.).
Is it reasonable to have each of those sprites create its own StreamSink? (and only exposes it via Stream upcast - as recommended in the book) Or should each of those sprites be given access to a more global StreamSink that it sends() to?
2) How to connect mutable display objects with immutable frp pipeline?
I know this was addressed in-depth throughout the book in multiple ways... but I'm still not totally clear on it and need help getting it into my guts
Let's say we react to some event and add a new DisplayObject to the rendering system. It must continue to exist within that system, and it is mutable - even though we want to run all our logic with immutable data. What's the best-practices way of dealing with this?
I'm currently thinking of the following:
DictionaryLookup
single, top-level mutable hash table or something - contains references to DisplayObjects via a hash id
UpdateInfo: immutable object that holds things like x,y,scale,rotation, and hashId
DictionaryLookup.unsafePerformUpdate(info:UpdateInfo)
takes UpdateInfo and applies the transformations to the DisplayObject in DictionaryLookup
DictionaryLookup.getInfo(hashId:string):UpdateInfo
takes a hashId and returns a new UpdateInfo (via reading properties on the associated DisplayObject)
Is this sensible? If so - should UpdateInfo rather be a cell... or maybe better put, what would be the scenario wherein I'd want UpdateInfo to be a cell vs. just a simple object with metadata?
3) listen() vs. map()
I think this will just reveal itself as I start playing with the code, but I'm a little confused about the relationship between listen() and map() ... if you don't listen() do you never get values? i.e. if I construct a StreamSink, send() values on it, and then elsewhere I reference that Stream and map() over it - will I not get the values? What role does listen() play in this picture?
4) Sortof a mix between general question and specific. The first examples, and the simplest place to start would be the widgets... which use Operational.updates(text).listen ... can you explain a bit why that needed to be there rather than something like map or some solution without Operational?