flatMapLatest, zip for example are operators which handle concurrency in a declarative way. So requests = flatMapLatest(keyPressed => makeAPIcall(keyPressed)) means that for each key pressed, you will have a async process (API call), and you may have several of them concurrently, and the operator will take care of handling hte communication so that you get only the results of the latest one who communicated back its results. It is declarative so you don't really have to care about how the concurrency and communication are implemented.
what’s a good resource for learning these more advanced state machine concepts
what are you referring to specifically? statecharts? State machines are pretty simple to use, you don't really need to read a book to understand the concept. Extended state machines are state machines with memory (i.e. state which you can update and read from). Hierarchical state machines are machines whose control states can themselves be machines (which can themselves be machines etc. so you get a hierarchy that way). State transducers are state machines which produce outputs. That is about it really. Looking up stuff on Wikipedia here should be enough.
Statecharts are for sure more complex because it complects several unrelated things together (concurrency and communication). There are the Harel book, and then Ian Horrocks book which makes for good references (lots of pages but nice read and thorough treatment of the subject). Otherwise there are several short lessons that you can find online that are being taught in schools. That one gave me the idea of writing the chess game with state machines.
typescript=3.6.3 and .event from @cycle/dom was causing errors everywhere I used it
To recenter the subject of state machines on cycle.js, I want to emphasize that a cycle component is f::Sources -> Sinks where Sources is either an event source, or an event source factory, and Sinks are the commands to run. That makes cycle.js quite a natural fit for using state machines, as long as the machine computes commands from events. The component becomes something like
function f(sources){
const {eventSource$} = sources;
const commands$ = eventSource.map(fsm);
return {
sink1: commands$.map(extractSink1Command).filter(Boolean)
...
}
}where extractSink1Command:: Command -> Maybe Sink1Command, and commands$:: Stream Command
In practice, your machine will take several event sources, so const commands$ = eventSource.map(fsm); may become const commands$ = merge(eventSource1, eventSource2, ...).map(fsm)
When you do it like this, there is no need to handler reducers, use isolation etc. The machine already handles the necessary state in an isolated way. That may or may not have better ergonomics according to the taste du jour. But for complex logic, I really think that it is a pretty attractive option.
.compose(dropRepeats()). With combine's and merge's and map's, stream event propagations can easily go out of hand, and then at some point you have to control and clean it up with this. Maybe this is another phenomenon which belongs to the UI characteristics. I think dropRepeats could be a default behavior with MemoryStreams