Adds a possibility to configure convention for store naming. Prefix convention will be a default. Most new files are created for testing purposes 🙂

closes #31

Watch have last computation priority.

Frequent use of the watch can lead to races that are very difficult to debug. Often, the use of the watch can be avoided (by using target, for example).

Story

For now, we can write sample/guard in any order:

sample({
  target: foo, 
  fn: (bar) => Baz, 
  source: bar, 
  clock: clock
}) 

Would be nice to enforce a more convenient order E.g. source->clock->fn->target (or clock first)

Extra stuff

• We also need the same thing for @sergeysova patronum I guess

I'd like to ban forward({ from, to }) operator, and replace it with sample({ clock, target }) instead
The reason is that sample does the same thing that forward does, but it's completely superior in terms of features I figured out that every time I write forward somewhere, after a ~hour I rewrite it to sample because OK now I need to transform my data The only problem is that forward has different execution priority rather than sample, so sometimes it might be important

fixes #52

• [x] Add meta.hasSuggestions to rules
• [x] https://github.com/typescript-eslint/typescript-eslint/issues/3738

We are ready! Just waiting for releases:

• typescript-eslint v5
• eslint v8

Eslint stop with error

Referenced from: /home/user/_proj/project/front/.eslintrc.js

/home/user/_proj/project/front/node_modules/eslint-plugin-effector/rules/enforce-store-naming-convention/enforce-store-naming-convention.js:32
            type?.symbol?.escapedName === "Store" &&
                 ^

SyntaxError: Unexpected token '.'
    at wrapSafe (internal/modules/cjs/loader.js:915:16)
    at Module._compile (internal/modules/cjs/loader.js:963:27)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1027:10)
    at Module.load (internal/modules/cjs/loader.js:863:32)
    at Function.Module._load (internal/modules/cjs/loader.js:708:14)
    at Module.require (internal/modules/cjs/loader.js:887:19)
    at require (internal/modules/cjs/helpers.js:74:18)
    at Object.<anonymous> (/home/user/_proj/project/front/node_modules/eslint-plugin-effector/index.js:3:40)
    at Module._compile (internal/modules/cjs/loader.js:999:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1027:10)

    "eslint": "^7.32.0",
    "eslint-plugin-effector": "^0.2.0",

Some events shouldn't be called in application:

• Effect aware events — fx.doneDota, fx.done, etc.
• Mapped events — const newEvent = oldEvent.map(..)
• Store aware events $store.updates
• Events created by methods — const event = sample({ source: $store, clock, fn })

But these events can be called:

• const newEvent = event.prepend()
• const { a, b } = createApi(store, {})

I propose to add check to abandon names in reducer arguments like state, payload, data, result and so on. Arguments named with context should allow to effectively understand code.

Decline:

const $list = createStore([])
  .on(added, (state, payload) => [...state, payload])

Allowed:

const $list = createStore([])
  .on(added, (list, item) => [...list, item])

1. Fix false positives from the rule and add test case.

Example:

const $store = createStore(false).on(open, () => true)

2. Add a more correct deletion of the line with debug and add test case (properly saving the formatting)

// from
import { condition, debug, delay } from 'patronum'

const $store = createStore(false)

const createTest = () => {
  const state = {
    equal(a, b) {
      return a === b
    }
  }
  debug($store)
  return state
}

// into
import { condition, delay } from 'patronum'

const $store = createStore(false)

const createTest = () => {
  const state = {
    equal(a, b) {
      return a === b
    }
  }
  return state
}

I found such code:

const sendEvent = sample({ clock: somethingDone, fn: (payload) => mapper(payload) })

In my opinion, it should be rewritten in this way:

const sendEvent = somethingDone.map((payload) => mapper(payload))

В фабриках на effector имеются ложные срабатывания правила effector/no-ambiguity-target на guard.

Что говорит eslint: Method 'guard' returns 'target' and assigns the result to a variable. Consider removing one of them effector/no-ambiguity-target

Версии пакетов: effector: 21.8.12 eslint: 7.32.0 eslint-plugin-effector: 0.3.0

Конфиг eslint:

module.exports = {
  root: true,
  extends: [
    'plugin:effector/recommended'
  ],
  parser: '@typescript-eslint/parser',
  plugins: [
    'effector',
    '@typescript-eslint'
  ]
}

Пример кода: typescript playground

Rule effector/mandatory-scope-binding not working - no warnings/errors Example: https://stackblitz.com/edit/effector-vite-react-template-2sj3r3?file=src%2Fapplication.tsx

Using effects in components typically leads to business logic leaks into view. A cleaner approach is to use events instead of effects. I suggest to add corresponding rule to warn a user about it.

// Fail
function Component() {
  useUnit(someFx)
  useEvent(someFx)
  useEffect(() => {
    someFx()
    () => someFx()
  }, [])
  const callback = () => {
    someFx()
  }
  useCallback(() => {
    someFx()
  }, [])
}

Enforce a maximum number of lines of code in a unit

Some people consider large functions a code smell. Large fn or filter in sample can make it hard to follow what’s going on. This rule should help enforce that style. It should have separate configurations for all major units (sample, guard, effect) with appropriate default values per each

Personally, I hate restore because of the following pattern 👇

const $currency = restore(currencyInited, null).on(settingsChanges, (_, { ccurency}) => currency);

Furthermore, I doubt that one line of code is a good reason to skip the full store declaration.

$store.on is less extendable than sample, and it could be replaced with sample. Let's add a rule to check this.

In my mind, we should not add it to recommended preset, but it would be useful in future preset (maybe).