Skip to content

It would be better if allSettled will return results of effect execution #385

Description

@bacher

I'm trying to write SSR Isomorphic application (with Next.js) and I start using Fork api (scopes).

As I could understand (maybe wrong) I should use allSettled func when I use effects on backend-side.
But If I wrap effects into allSettled I'm loosing my ability to read results of effect execution (returning values). And it very uncomfortable.

I expected this flavour of using:

const user = await allSettled(getUserFx, {scope, params: { userId: 31 }});

but user will be undefined in this case...

For contrast calling const user = await getUserFx({ userId: 31 }; will return user data.

Maybe in Effector exists another methods for call effects on the backend with specifying certain scope where I could get results of execution. I couldn't find.

Activity

  1. zerobias commented on Sep 21, 2020

    @zerobias
    Member

    This imply that allSettled might fail (because if you get results, you should get errors too), if this is an expected behavior, then we could implement that idea

  2. zerobias commented on Sep 21, 2020

    @zerobias
    Member

    Oh, looks like errors support is a breaking change, as there are projects, which expect that allSettled is never throw an error
    But we can return value with type {status: 'done', value: Done} | {status: 'fail', value: Fail}

  3. bacher commented on Sep 22, 2020

    @bacher
    Author

    I've thought again, and seems allSettled semantic really shouldn't return results/throw errors.
    And maybe we need another method/helper for calling effects for specific scope directly.

    Maybe like:

    const user = await getUserFx.withScope(scope)({ userId: 31 });
    // or
    const user = await scope.exec(getUserFx, { userId: 31 });

    But in this case we're losing ability "Call provided event in scope and wait for finishing all the triggered effect." from allSettled although on backend we should wait for all asyncs.

  4. bacher commented on Sep 22, 2020

    @bacher
    Author

    But we can return value with type {status: 'done', value: Done} | {status: 'fail', value: Fail}

    Actually I think your variant is very good. Semantic is really good, no errors, but details.

  5. zerobias commented on Sep 22, 2020

    @zerobias
    Member

    Okay, then we'll implement that in next minor release

  6. zerobias commented on Oct 2, 2020

    @zerobias
    Member

    Updates: this feature was implemented in runtime and in typings, the last question is what this method should return when used with events? Is it ok to return void? Or if we decided to return similar object, which status should be used? Can we add return object later?

    After thinking about this for some time, I came to conclusion that calling allSettled with event should not return status object, at least it not useful in discussed case, but it is ok to introduce it later

  7. zerobias commented on Oct 5, 2020

    @zerobias
    Member

    Implemented in 21.4.0

  8. bacher commented on Oct 5, 2020

    @bacher
    Author

    @zerobias Thank you very much! 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    coreeffector packageenhancementNew feature or requestquestionFurther information is requested

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions