Routing results for different effect arguments to different stores.

[KenjiTakahashi]

Hello,

Consider a following (simplified) structure: https://share.effector.dev/iCXzsmD8.
Now, how would I go about if I wanted the result of effect call for {arg:1} to go only to s1 and for {arg:2} only to s2?
I'm not sure how to achieve this in a "clean" way.
What I could think of is:

1. duplicate effects (feels unnatural, why have effect accept arguments in the first place?),
2. filter the output using sample (or sth else?) (why gather all output in one place only to split it apart again?).

Both would also require doing object comparisons in JS, which is a bit PITA.

The real life case is having multiple, separate instances of a component, where each instance expects data for different arguments.
Appreciate any insights!

[sergeysova]

If I get it, you can use condition from effector patronum library:

condition({
  source: merge(e.done, e.fail),
  filter: ({ params }) => params.arg === 1,
  then: s1,
  else: s2,
})

e({ arg: 1 })
e({ arg: 2 })

Try it

P.S. We have an article about usage with React. It can help you improve naming in your code: https://community.effector.dev/core/usage-with-react-i2p

[KenjiTakahashi]

Thanks, this is more or less what I meant by my idea 2).
The problem is I think it would be hard to generalise to our real life scenario.
What if structure of the arg is not known beforehand? Would have to compare objects in some kind of "cache", like mentioned before.
What if there are N possible args going to N stores? Nesting condition N times sounds not very feasible.

BTW: I believe you meant if, not filter, in your condition args.

[sergeysova]

If you send the real example, it will be easier to help you.
But generally you can use spread to send properties to different stores.

[KenjiTakahashi]

Sorry for a late response, been busy with other tasks for some time.

Unfortunately, I cannot share the real code, but the idea is that we have

• Functions that fetch JSON data, using standard fetch API.
• Each of the above is wrapped in an Effect.
• The results are split by JSON key names and each field's value is a Store. Together they form a kind of "model" object.
• Components then "subscribe" to whatever they want from the "model".

Most of this is generated dynamically for many endpoints, but stripped down to a single case, it would look somewhat like this: https://share.effector.dev/Q1XdJn9g.

It's possible that we're doing sth against the conventions, it would be great to see your (and/or others) perspective.
Cheers!

[sergeysova]

effector is not intended to use in classes. Just as plain models.
@AlexandrHoroshih maybe you have great ideas on how to solve the case?