How to properly migrate to effector from redux, keeping actions pure and isolated?

[mkhoussid]

I've decided to try effector and I'm trying to figure out the best way to replace redux in my project with it.

Whenever I use redux in a React project, I usually have the following structure for a feature:

src
└── features
    └── some_feature
        ├── components
        │   └── MyComponent
        │       └── index.ts
        └── redux
            ├── actions.ts
            ├── types.ts
            └── reducer.ts

With the said, here is how my files would look like:

// src/features/some_feature/components/MyComponent/index.ts
import * as React from 'react';
import { useDispatch } from 'react-redux';
import { someFunction } from '../../redux/actions';

const MyComponent: React:FC = () => {
    const dispatch = useDispatch();

    React.useEffect(() => {
        dispatch(someFunction());
    }, [])

    return <div>My component!</div>
}

My actions:

// src/features/some_feature/redux/actions.ts
import { httpClient } from 'src/services/httpClient';
import { SOME_ACTION } from '../types';

type TSetSomeData = {
    payload: {
        someData: any;
    }
}
const setSomeData = ({ payload: { someData } }): ThunkAction =>
	(dispatch): void => {
        dispatch({
            type: SOME_ACTION,
            payload: someData
        })
    };

export const someFunction = (): ThunkAction =>
	async (dispatch): Promise<void> => {
		try {
			const { someData } = (await httpClient({
				url: '/api/some-endpoint',
				method: EMethodTypes.GET,
			})) as {
				someData: any;
			};

			dispatch(setSomeData({ payload: { someData } }));
		} catch (err) {
            console.log('Error in someFunction', err);
		}
	};

My reducer:

// src/features/some_feature/redux/reducer.ts
import { AnyAction } from 'redux';
import { SOME_ACTION } from './types';

export type ISomeFeatureState = {
	someData: any;
};

const initialState = {
	someData: null,
};

const someFeatureReducer = (state: ISomeFeatureState = initialState, action: AnyAction): ISomeFeatureState => {
	const { type, payload } = action;

	if (type === SOME_ACTION) {
		return {
			...state,
			someData: payload,
		};
	} else {
		return {
			...state,
		};
	}
};

export default someFeatureReducer;

And types.ts would have export const SOME_ACTION = '@redux/features/some_feature/some-action'.

Anyway, here is how my folder structure looks like now:

src
└── features
    └── some_feature
        ├── components
        │   └── MyComponent
        │       └── index.ts
        └── effector
            ├── actions.ts
            ├── events.ts
            └── store.ts

And here are the files:

// src/features/some_feature/effector/store.ts
import { createStore } from 'effector';

export const $someData = createStore(null, {
	updateFilter: (someData) => !!someData,
});

// src/features/some_feature/effector/events.ts
import { $someData } from './store';

export const setSomeDataEvent = createEvent();
$someData.on(setSomeDataEvent, (state, payload) => payload);

// src/features/some_feature/effector/actions.ts
import { setSomeDataEvent } from './events';

type TSetSomeData = {
	payload: {
		someData: any;
	};
};
export const setSomeData = ({ payload: { someData } }: TSetSomeData) => {
	setSomeDataEvent(someData);
};

So, it's already cleaner and less code. The reason I've chosen such a structure and approach, is because it is very similar to my existing structure.

Anyway, effector offers different ways of mutating stores, one of which is on doneData:

// from the docs

import { createEvent, createStore, createEffect, sample } from 'effector'

const nextPost = createEvent()

const getCommentsFx = createEffect(async postId => {
  const url = `posts/${postId}/comments`
  const base = 'https://jsonplaceholder.typicode.com'
  const req = await fetch(`${base}/${url}`)
  return req.json()
})

const $postComments = createStore([])
  .on(getCommentsFx.doneData, (_, comments) => comments)

const $currentPost = createStore(1)
  .on(getCommentsFx.done, (_, {params: postId}) => postId)

sample({
  source: $currentPost,
  clock: nextPost,
  fn: postId => postId + 1,
  target: getCommentsFx,
})

nextPost()

Here, once getCommentsFx finishes executing, the value for the store $postComments is set with whatever getCommentsFx.doneData resolves to.

What I'm having trouble with, is utilizing the same approach, but making it "friendly" with my current project.

The only way that I can think of, is rewriting someFunction like this:

// src/features/some_feature/effector/actions.ts
import { createEffect } from 'effector';
import { httpClient } from 'src/services/httpClient';
import { $someData } from '../store';
import { setSomeDataEvent } from '../events';

type TSetSomeData = {
    payload: {
        someData: any;
    }
}
export const setSomeData = ({ payload: { someData } }: TSetSomeData) => {
	setSomeDataEvent(someData);
};
    

export const someFunction = (): ThunkAction =>
	async (dispatch): Promise<void> => {
		try {
            const { someData } = await createEffect<{someData: any}>(async () =>
                httpClient({
                    url: '/api/some-endpoint',
                    method: EMethodTypes.GET,
                })
            );

            setSomeDataEvent(someData);
		} catch (err) {
            console.log('Error in someFunction', err);
		}
	};

But I see no point in using createEffect at all, because I can just do this:

export const someFunction = (): ThunkAction =>
	async (dispatch): Promise<void> => {
		try {
            const { someData } = (await httpClient({
                url: '/api/some-endpoint',
                method: EMethodTypes.GET,
            })) as {
                someData: any
            }

            setSomeDataEvent(someData);
		} catch (err) {
            console.log('Error in someFunction', err);
		}
	};

Any suggestions about going about this? Is it fine to use effector without createEffect (or most other provided methods via its API, for that matter)? Essentially, I'm just creating stores and binding events to them, I feel like I'm not using effector in the way it was intended, but I can't think of a better way to rewrite it.

What can I do here? Should I just got back to Redux?

[AlexandrHoroshih]

Hello @mkhoussid !

You don't really need actions approach with effector, i think 🤔

Events are already behave like regular functions to the rest of the world around them.

As of someFunction, I would recommend that you start breaking this function down into its individual meaningful parts, something like that:

const getSomeDataFx = createEffect(async () => httpClient({
   url: '/api/some-endpoint',
  method: EMethodTypes.GET,
}))

const startSomething = createEvent()

const $someData = createStore(null)

sample({
 clock: startSomething,
 target: getSomeDataFx
})

sample({
 clock: getSomeDataFx.doneData,
 target: $someData
})

Notice, how it is all separated declarative blocks and unit definitions - it is easier to read and to change, as you no longer bound to single function.
E.g. if there is some additional data to be mixed with getSomeDataFx response or some cases, when you need to skip this update, you basically just adding few lines to some of the sample calls

sample({
 source: $someOtherData,
 clock: getSomeDataFx.doneData,
 filter: (_, someData) => shouldSkip(someData),
 fn: (someOtherData, someData) => mixData(someOtherData, someData),
 target: $someData
})

Also notice, that createEffect should not be called in handler, as it is Effect factory. It is the result of createEffect, that you can use both in effector logic and your Redux middlewares or thunks (for migration), as Effects are behaving like normal async functions for the rest of the world around:

const getSomeDataFx = createEffect(async () => httpClient({
   url: '/api/some-endpoint',
  method: EMethodTypes.GET,
}))

// use both in effector's logic
sample({
 clock: buttonClicked,
 filter: $moonPhaseIsRight,
 target: getSomeDataFx,
})

// and old redux stuff for soft migration
export const someFunction = (): ThunkAction =>
	async (dispatch): Promise<void> => {
		try {
            const { someData } = await getSomeDataFx()

            setSomeDataEvent(someData);
		} catch (err) {
            console.log('Error in someFunction', err);
		}
	};

[mkhoussid]

Hello! Thanks for your reply.

I've considered your suggestion, and I agree that a declarative approach is great for brevity and readability, however I am still a little hesitant about breaking up actions into separate components/methods. I've looked around the docs and I've decided to make use of the subscription feature in effector. Here is what I've ended up with:

Is this an OK solution? You've mentioned that I should not use createEffect in my handlers — so I've ended up using the result of createEffect by creating a wrapper for it (createAndExecuteEffect).

If you have the time, please let me know if you have any insight about this approach and the folder structure of this demo project. As you can see, doneData is not used anywhere other than in createAndExecuteEffect.

[AlexandrHoroshih]

The core idea here is to seprate logic description from low-level details like data structures and side-effect implementations

Suppose we have something like simple form with two fields, we can describe the logic this way:

const loginFieldChanged = createEvent()
const passwordFieldChanged = createEvent()
const submitButtonClicked = createEvent()

const $login = createStore('')
const $password = createStore('')

const $form = combine({ login: $login, password: $password })

const $formValid = $form.map((form) => {
 // validating form somehow
})

const submitFormFx = createEffect(async (form) => {
 // submitting form to the server somehow
})

sample({
 clock: loginFieldChanged,
 fn: (browserEvent) => {
   // extracting value somehow
 },
 target: $login,
})

sample({
 clock: passwordFieldChanged,
 fn: (browserEvent) => {
   // extracting value somehow
 },
 target: $password,
})

sample({
 source: $form,
 clock: submitButtonClicked,
 filter: $formValid,
 target: submitFormFx,
})

sample({
 clock: submitFormFx.done,
 fn: () => ({ page: 'main' }),
 target: redirectFx,
})

sample({
 clock: submitFormFx.fail,
 fn: () => ({ message: 'Wrong login or password' }),
 target: showMessageFx,
})

Notice, how logic is described as a set of rules defined via sample, but exact implementation details (mappers, specific data types, validators, backend requests) are ommited from my snippet.
But you can still tell exactly how it should work:

• when user have clicked submit button, form, if it is valid, will be submitted to the server
• when form values are changed, it should be calculated, that form is valid
• if submit successful, then user should be redirected to the main page
• if submit failed, error message is shown
• etc

Your approach is still kind of good-old imperative middlewares/flows/actions/etc - everything happens in one handler, one by one, with explicit handling of data and side-effects and to understand actual logic you need to kind of deduce it from the code.
Which can be hard, if there is some poorly choosen data structure and a lot of code to handle that.

With separation of logic and implementation parts it will be much easier to you to refactor actual implementation - get better data-structures and algorithms, etc.

Also this simplifies testing for you. Most of effector tests are written like this:

test('form is submitted by click', async () => {
 const submitRequestPerformed = jest.fn()
 const scope = fork({
   handlers: [
     [submitFormFx, () => {
        submitRequestPerformed()
        Promise.resolve(mockResponse)
      }]
   ],
  values: [
   [$login, 'mockLogin'],
   [$password, 'mockPassword']
  ]
 })
 
 await allSettled(submitButtonClicked, { scope })
 
 expect(submitRequestPerformed).toHaveBeenCalled()
})

You can read more about it here:
https://dev.to/effector/the-best-part-of-effector-4c27

You can think of a way to test your async handlers in similiar way and very quickly you will find out, that, because of logic being entangled with implementations details, it will be quite hard to do, especially when you need to mock something.

[mkhoussid]

Very interesting take, thanks for your feedback. You're absolutely right, I need to focus more on declarative code, not imperative.

My final question would be about folder structure. Do I just bundle up everything related to this auth form into one file? I ask this, because, for instance, the Form component could live with other components, or, maybe, other components need to useStore for something like $user, so where do I create and store $user?

[sergeysova]

In the most cases you can create the model.ts file where you place all the effector stuff (like createStore and sample).
And the all view-library related stuff place in view.tsx (like components, @effector/reflect and effector-react)

[AlexandrHoroshih]

There are bit more examples in the documentation:
https://effector.dev/docs/api/effector/createEffect

Also you might find useful some of effector's ecosystem libraries like

• https://farfetched.pages.dev/ - advanced data fetching tool, so it is easier to build api layer for your application
• https://patronum.effector.dev/ - which provides you with some high-order operators, so you don't have to re-invent them yourself

Patronum also includes debug operator, which can provide you with detailed information on any effector's update in your app
https://patronum.effector.dev/methods/debug/