Closed goshacmd closed 7 years ago
Sweet thanks for the interest! redux-observable exposes the entire store so you can also call dispatch, however it's considered bad practice so perhaps just this read-only STATE driver sounds good. I will give it a test tonight and let you know.
First off, thanks for making this project!
I've played with Cycle.js a couple of months ago. I found its concepts to be novice and in a way, I felt a bit like when learning Haskell. However, at least for me, the all-or-nothing approach that the official docs seemed to preach (DOM driver, "Typically, when writing a Cycle.js app, you do not need to create your own drivers.") felt kind of out-of-touch with reality.
Abandoning React and reinventing the wheel is a tough sell. Going from event log + projection of all events that'd happened (aka Redux) to having DOM structure depend on DOM events is primitive... so, I've put Cycle into the mental "revise later" bucket and I wouldn't probably have come back if...
It weren't for this very project, which opened my eyes to the way Cycle can be used to augment existing React/Redux project. Sagas and typing is a sad story; redux-observables don't separate side effects in any way 😞 so the objective of redux-cycle-middleware resonated with me. I'm trying to migrate parts of my react-native project onto Cycle and I feel quite good about having analytics, push notifications, payments, and more abstracted as Cycle drivers.
Anyway, my story is getting too long already. This PR adds a STATE driver which is similar to the
select
effect in redux-saga... because all too often you have "sagas"/"epics" which are triggered by some Redux action, BUT ALSO need to access the current state to make some side-effect to a custom driver.