This repository has been archived by the owner on Aug 16, 2022. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 3
effector-reeffect's Past, Present and Future #26
Comments
This was referenced Sep 26, 2021
it was very unkind of you to take correspondence out of a private chat room without consent |
Sorry for that. Childish impulsive act I regret about. To be clear: |
This was referenced Sep 27, 2021
Closed
Release v3.0.0 was published. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
TL;DR — The most valuable thing
effector-reeffect
can do for theeffector
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 ofeffector-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 createdeffector-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 theeffector
, and after a month and a half, 17 of January 2020, I've published a new, completely rewritten version. Which was passing almost alleffector
'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 andeffector
:launch
was added thanks to mine and @zerobias conversations about implementation details.effector-reeffect
version 1.0.0 was released,effector
has adopted same behaviour foreffect.pending
store.effector
's internals on the Effector Meetup #1, and later scripted it in the article, which is somewhat actual still at some extends.effector
works.now
In a short
effector-reeffect
's lifetime it has changed to catch up witheffector
two times — for version 20.12.0 and 21.2.0. Both times new version was incompatible with previous versions ofeffector
. Now there is a new major version 22, andeffector-reeffect
is incompatible with it again.In a nutshell, from the very first version
effector-reeffect
was monkey-patching nativeeffector
'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.
effector-reeffect
should receive PR from @AlexandrHoroshih to be compatible witheffector
version 22.effector
andeffector-reeffect
.effector-reeffect
, but it will be deprecated on NPM.effector
releases.Why not update this package, like I did with
effector-storage
? Thing is I don't useeffector-reeffect
in my own projects anymore (unlikeeffector-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?
TAKE_FIRST
strategy just use simpleguard
.TAKE_LAST
andRACE
strategy check out examples for request cancellation fromeffector
's documentation, and work out code, fitting your needs.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.The text was updated successfully, but these errors were encountered: