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. |
|
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 |
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
samplefor 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 ofonfor 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 ofclockterm for triggers.fn→map. Although it is described as combinator function, it could be conceptually described as a mapper function. And again,mapis common, widely used and familiar way to transform data. Finally, that looks consistent with$store.map(...)(but not the same though).Any thoughts?
All reactions