I notice that <https://github.com/ChuckerTeam/chuc...

# chucker

[psh]

I notice that https://github.com/ChuckerTeam/chucker/pull/270 will introduce coroutines into Chucker for processing payloads off the main thread. Would you be on board with an issue suggesting we carry that refactor a few steps further by moving away from LiveData in the HttpTransactionDao and moving to Flow + suspend functions, and only expose the result to the GUI (in MainViewModel) using LiveData?

[gammax]

I have to admit, that I’m also a bit hesitant in moving to coroutines. Every third party dependency that we add (coroutines, LiveData, Flow, etc.) is posing more complexity/resolution time on the end user.

On the other hand moving to Flow sounds like a potential way to be up to date with the development standards. I don’t think I’m the right person to give a final call here honestly, but happy to discuss.

[MiSikora]

My 5 cents here. Personally I’d love to see LiveData being dropped or at the very least used only on the ViewModel layer. Aside from other problems, using it for anything else is really painful as it does not provide a good way to do intermediate background work and requires strange solutions like this one - https://github.com/ChuckerTeam/chucker/blob/bee88133909a3daa42d9eca7516aafd8a0a68487/library/src/main/java/com/chuckerteam/chucker/internal/support/LiveDataUtils.kt#L46.

[Vova Buberenko]

From my point of view we should do this further migration.
The only point here - let’s do splitting of Transaction into Response and Request first as discussed here https://github.com/ChuckerTeam/chucker/issues/259 and think about introducing Flow after.

P.S. I am both glad and not that we are getting so mush attention and contributions from the community, since we have a lot of cool things which move library forward, but at the same time we have too many contributions in different directions, which make it quite hard to align everything right in terms of some uniform approach / architecture.

[gammax]

I am both glad and not that we are getting so mush attention and contributions from the community,

Seems like getting that ROADMAP.md file in the root could be useful now. This will help people to align with the long term vision.

[Vova Buberenko]

It is my fault that I promised to create a project board quite a long time ago and constantly delayed it. Will fix that ASAP and we will have priorities here as well.

[gammax]

It is my fault that I promised to create a project board quite a long time ago and constantly delayed it

I was not pointing finger 😅 It was more like: we should definitely define a roadmap somehow and get a guideline also for external contribs. That would be really helpful to provide pushbacks on “wild” PRs.