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.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
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