effector-reeffect's Past, Present and Future

[yumauri]

TL;DR — The most valuable thing effector-reeffect can do for the effector ecosystem is to self-destruct and cease to exist in a current form.

past

4th of December 2019, after just a month of discovering effector, and being completely under admire, I've published first naive version of effector-reeffect. It was warmly welcomed by the community and by @zerobias himself, even while it was completely broken. I've stumbled upon this as soon as I've added newly created effector-reeffect in my project, for which one I've written it in a first place.

This issue gave me a huge boost in understanding effector under the hood. I was asking author and the community, reading the source code of the effector, and after a month and a half, 17 of January 2020, I've published a new, completely rewritten version. Which was passing almost all effector's internal tests for a native Effects, excluding those, which behaves differently by design. Once again, it was warmly welcomed, I started using it in my projects, some folks adopted it as well.

effector-reeffect has closed questions with parallel running effects in a very elegant (I want to believe so) way. Before it there were discussions, some snippets of a code, but there were a gap in the ecosystem. A hole, absence of support for such cases, as requests cancellation, in a native Effect from one side, and absence of plug-and-play solution for such cases in the ecosystem from the other.

I was using effector-reeffect in our projects. It was being suggested as a solution in the community chat, to address questions about parallel Effects execution. It also gave more, than just a library, to a community and effector:

• Object form of launch was added thanks to mine and @zerobias conversations about implementation details.
• Few days after effector-reeffect version 1.0.0 was released, effector has adopted same behaviour for effect.pending store.
• I made a speech about effector's internals on the Effector Meetup #1, and later scripted it in the article, which is somewhat actual still at some extends.
• I also wrote few articles about understanding, how effector works.

now

In a short effector-reeffect's lifetime it has changed to catch up with effector two times — for version 20.12.0 and 21.2.0. Both times new version was incompatible with previous versions of effector. Now there is a new major version 22, and effector-reeffect is incompatible with it again.

In a nutshell, from the very first version effector-reeffect was monkey-patching native effector's Effect and using undocumented guts of it. This is clearly bad architecture and I know this. I knew this from the start, but I didn't came up with another solution back then. Still, I think it was a good contribution to the ecosystem and community. But for now it drags them back. We need modern tools, with good API design and robust implementation, which will not rely on undocumented unstable internals.

So hereby I declare effector-reeffect deprecated and not recommended to use.

future

Here's the plan.

• Approximately in a week or so effector-reeffect should receive PR from @AlexandrHoroshih to be compatible with effector version 22.
• I will publish new version 3.0.0 to NPM, so anyone using this package could update effector and effector-reeffect.
• I will not accept any new PRs.
• I will not fix any issues, old and new ones.
• I will not remove package effector-reeffect, but it will be deprecated on NPM.
• This repository will be updated to indicate this deprecation.
• Anyone using this package should consider removing it, because it will definitely break again in the future, with new effector releases.

Why not update this package, like I did with effector-storage? Thing is I don't use effector-reeffect in my own projects anymore (unlike effector-storage). And this opens a huge gap between me as a maintainer, and users of this package. It is hard to maintain and evolve library without actually using it, without knowing use cases and edge cases.

Also, I would suggest against forking and supporting this code, if such thought just crossed your mind. Let's not prolong its suffering. When a door closes, another one opens, so, give a way for a new generation "reeffect" (or whatever name it will have).

Maybe even one day this library will rise like a phoenix from the ashes, who knows.

What to use instead?

• For the TAKE_FIRST strategy just use simple guard.
• For the TAKE_LAST and RACE strategy check out examples for request cancellation from effector's documentation, and work out code, fitting your needs.
• For other strategies (if you happen to use them), ask help for community (ru/en), I saw few snippets in the chat, implementing one or another strategy.
• You might also want to try fry-fx library by @doasync, I never used it myself, but pretty sure it is good enough.

I would like to thank you all, who uses or used this library.
And thank @zerobias for amazing effector, which inspired me into all of this.

[zerobias]

it was very unkind of you to take correspondence out of a private chat room without consent

[yumauri]

Sorry for that. Childish impulsive act I regret about.

To be clear:
Decision made was long mulled over, and I don't blame anyone. Mentioned correspondence was just a little bit too harsh for me, that is why there is a hint of injury in my message. I tried to edit it a bit, to remove that odor.

[yumauri]

Release v3.0.0 was published.