3 ms·
Hot (uninformed) take: The effect system described in the first post immediately reminded me of re-frame, a Clojurescript library that uses React under the hoo
by filoeleven 5y ago
Hot (uninformed) take:
The effect system described in the first post immediately reminded me of re-frame, a Clojurescript library that uses React under the hood. I don’t know how similar this flow is to that, but they share the key axiom that “declaring an effect should be orthogonal to running it.”
I kind of hate generators, so I’m deferring the rest of the article/series until I’m not heat-angry and can read it more in the spirit of curiosity =)
- qudat 5y agoThe term I use to describe this phenomenon is treating side-effects as data. https://erock.io/2019/04/12/simplify-testing-async-io-javascript.html https://erock.io/2019/04/12/simplify-testing-async-io-javasc...
- rendall 5y agoThe example function in the article `fetchAndSaveMovie` is (deliberately, I know) not well-written. If it were composed of 2 functions `fetchMovie` and `saveMovie`, each of which does one thing, then each could be tested separately. If the composed function then needed to be tested, it would only need to test that each function were called in succession, but personally I wouldn't think it necessary. With that small change, I'm not sure how essential is the rest of the approach. I'm definitely not saying that the approach isn't possibly valuable, more that I don't think the article argues for it very well. It introduces complexity to cover for poorly-written code. I think if it were to start out with excellent code and demonstrate an unambiguous improvement, it would be a better argument. My 2c