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

Is runFork really the preferred method for running effects? #864

Open
tmcw opened this issue Oct 17, 2024 · 0 comments
Open

Is runFork really the preferred method for running effects? #864

tmcw opened this issue Oct 17, 2024 · 0 comments
Labels
documentation Improvements or additions to documentation

Comments

@tmcw
Copy link

tmcw commented Oct 17, 2024

What is the type of issue?

Documentation is confusing

What is the issue?

The docs for runFork say that

Unless you have a specific need for a Promise or a synchronous operation, Effect.runFork is the recommended choice.

This is confusing to me:

The only example of using runFork in the running effects documentation is extremely contrived - if I wanted to, say, "get the result of the effect," I have no idea how to do that. It seems like i'd interrupt the fiber intermittently until it returns, but that seems weird, inefficient, and very different from the norms of promises or async/await or anything else in TS, and there are no examples of doing that.

Where did you find it?

https://effect.website/docs/guides/essentials/running-effects#runfork

@tmcw tmcw added the documentation Improvements or additions to documentation label Oct 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation
Projects
None yet
Development

No branches or pull requests

1 participant