I agree in principle, but your imperative section was a total straw man of awful code design; it weakens your FRP arg
Conversation
I'm honestly curious: how would you improve the imperative solution?
1
decompose the problem; VC has an obj that just fetches and later returns. Internally, it handles cancellation, throttling, etc
2
1
what you showed is the beginning of a Massive VC, and smart programmers know to not even look at that road
1
3
but that doesn’t mean that FRP is The Way™ to solve the problem
1
2
the fact that I implemented it in a VC was to simplify the talk. I agree there are better ways to structure and decompose it
1
but the underlying issues will always be the same.
1
eh, I disagree; the structure and lack of decomposition IS the problem. FRP is not a panacea
1
2
7
not trying to argue that it is just showing an example of how we can reduce complexity in modern apps, but it's not the only way
2
however, I strongly believe that just by decomposing my solution, you wouldn't fix the underlying issues.
2
Replying to
Let me try: RAC abstracts and makes reusable much of the error-prone logic you’d have moved to your helper object.
Replying to
it'd be nice to compare how you guys refactor the same Mega-Controller - with RAC and with "plain" decomposition
1
1
they're not opposite points of view. What showed are basic ideas for decomposition. RAC can help wire things up later.