Replies: 2 comments
-
I think, i agree with @sergeysova arguments in the #721 🤔 Just changing current terms to more common ones will require a lot of work on correcting docs, providing explanations about this transition - looks like it will create more confusion since there will be two words for the same thing 🤔 Also many reactive libraries do have their own "language" - e.g. |
Beta Was this translation helpful? Give feedback.
-
I think, that issue with effector "language" also can be solved by documentation 🤔 e.g. if we add "Concepts" section in the docs with explanations on what is a |
Beta Was this translation helpful? Give feedback.
-
Hi folks, before opening an issue, I wanted to discuss adding an aforementioned aliases in
sample
for consistency and easier adoption across various teams experienced with other community-popular state/flow managers. I've just read #721 brought up by @igorkamyshev and kinda agree that Effector uses some uncommon api terms that makes it more difficult for onboarding. Adding these aliases should be straightforward and non-breaking.Here is the rationale:
clock
→on
. Firstly, this makes it easier for adoption for newcomers due to common use ofon
for any sort of triggers. Secondly, it would look consistent with$store.on(trigger, ...)
api. I have seen (and used) dozen of state/flow managers and have never seen usage ofclock
term for triggers.fn
→map
. Although it is described as combinator function, it could be conceptually described as a mapper function. And again,map
is common, widely used and familiar way to transform data. Finally, that looks consistent with$store.map(...)
(but not the same though).Any thoughts?
Beta Was this translation helpful? Give feedback.
All reactions