<@U0RM4EPC7> <https://github.com/arrow-kt/arrow-fx...

# arrow-contributors

[Satyam Agarwal]

@simon.vergauwen https://github.com/arrow-kt/arrow-fx/pull/289/files README was a very good reference point. whenever i wanted to refresh my moemory on something, I knew I can always go back to this reference point.
I am sad to say https://arrow-kt.io/docs/fx/ doesn’t give a good overview.
Seldom, I need to check api docs, which is basically what I get out of main fx webpage. The rest is very confusing, and have fewer examples than what was mentioned in the README before the PR I mentioned.
I would really appreciate if this README was expanded.

And above all, if you can take a look at what I going on https://arrow-kt.io/docs/fx/ , it would be amazing.

I think you guys will promote. coroutines integrated solutions more and more, which is natural.
The webpage should reflect that, with rich set of examples from the README.

I don’t understand the point of kotlinx.coroutines section from the website, now that we have arrow-fx-coroutines.
Also Why IO integration contains kotlinx.coroutines when Coroutines Integration contains the same sub section ?

I think Coroutines Integration should just be removed, and Quick start should be enriched and expanded.

The Data type section is now pointing to arrow-fx-coroutines but contains no practical examples. Its just a neat and more described version of api docs.

There are many who use fx a lot, but not necessarily are well versed with fp concepts, which makes things hard, if we want to use API from the library without good docs.

For me personally, things have gotten way easier, since I have migrated from arrow from Try.catch to IO.invoke, to Either.catch, and have been using since 2018. So I know where to look, who to ask.

I know there are a lot at your plate, but honestly, so do I, and its a shame after using this library for more than about 3 years, I haven’t already started contributing. Things have been way too busy.

I hope, I, in future, instead of requesting things, should be able to make time to raise PRs instead. 🙂 But until then, here is my request 😅

[raulraja]

Hi @Satyam Agarwal, We have already started to apply changes to the docs. @tomasruizlopez is working on it for Fx and Streams. We share most of your concerns here.

[Satyam Agarwal]

Thank you so much.

[raulraja]

As part of the 1.0 effort all docs and libraries are being reviewed and we attempt to make it easier and with a clear getting started beside the gore docs

[raulraja]

The current docs suffer from too many uncoordinated contributions and now its time to review and remove all that is non essential and that we have to get rid of before 1.0

[tomasruizlopez]

Thanks @Satyam Agarwal, we'll take your feedback into consideration and probably come back to you for feedback, once we start editing the docs. We want the experience to be as smooth as possible, and the docs have still some rough edges we need to polish.

[simon.vergauwen]

Hey @Satyam Agarwal thanks for feedback, it's certainly welcome and we're aware of the problem. Seems you already got most answers 🙂

I don’t understand the point of kotlinx.coroutines section from the website, now that we have arrow-fx-coroutines

The problem with KotlinX Coroutines is that it is currently used in a lot of areas. Ktor, Spring WebFlux, etc and those all rely on cancellation to work properly. So Arrow Fx Coroutines needs a way to interopt with those libraries, hence the need for a arrow-fx-coroutines-kotlinx-coroutines library. This might be solved with https://github.com/Kotlin/KEEP/issues/214, but that is still some time away. I hope to prototype this soon. This is similar to the issue with MDCContext, although that cannot be easily solved by an interopt module.

[simon.vergauwen]

I hope, I, in future, instead of requesting things, should be able to make time to raise PRs instead. 🙂 But until then, here is my request 😅

Looking forward to it!