Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rule: no-mutation-in-pure-functions #6

Open
igorkamyshev opened this issue Aug 28, 2021 · 2 comments
Open

Rule: no-mutation-in-pure-functions #6

igorkamyshev opened this issue Aug 28, 2021 · 2 comments
Labels
enhancement New feature or request

Comments

@igorkamyshev
Copy link
Member

Some functions in effector API should be pure:

  • reducer in .on-call
  • combinator (fn) in sample
  • filter in guard, .filter and .filterMap
  • mapper in .map and .prepend

We cannot prove the purity functions by ESLint rule, but we can forbid mutations in these cases.

@AlexandrHoroshih
Copy link
Member

I'm not sure i understand - how it is supposed to work?

For e.g., i think, this kind of mutation would be entierly correct:

(state, payload) => {
 const copyState = deepCopy(state);
 const copyPayload = deepCopy(payload);
 
 copyPayload.foo = "bar";
 copyState.some = copyPayload;

return copyState;
}

state & payload are available for other reducers and stores - mutating them is not correct, because this change will be observable.
But by creating a own copy in reducer this is no longer problem, since mutation of copy is not observable from the outside.

Another problem is that there is no way to proof that this copy = deepCopy(state) actually does not mutate the state 🤔

Looks like, it is only options that are secured from false warnings, are:

  1. Direct mutations of arguments (since reducer is not the only consumer of store state and event payload)
  2. Mutations of external objects

@AlexandrHoroshih
Copy link
Member

AlexandrHoroshih commented Nov 6, 2021

Also there is another case that is affects "purity" of functions - reading from outer state that can be changed during app lifetime.
This is a side-effect and can lead to observable changes in function behaviour, basically, by making it stateful

const box = { ... };
const RED = 'red';

$store.on(event, (state, payload) => {
 // all of this this is reading from outer state which is side-effect
 // and may lead to observable changes in function behaviour
 const date = new Date()
 const otherState = $another.getState()
 
 // `box` is not readonly or frozen object, we cannot prove that is not mutable
 // should be warned, i guess
 const someData = box[payload];

 // RED is a immutable primitive constant, will never change
 // this should not be warned, i guess
 const nextState = {...state, color: RED}

})

@sergeysova sergeysova changed the title Rule: no-mutation-in-pure-functions Rule: no-mutation-in-pure-functions Nov 9, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants