I got a noob FP question : I got a app that reads ...

# arrow

[TwoClocks]

I got a noob FP question : I got a app that reads messages off the wire (different types), and builds state from that (and only that), then spits out other msgs, or does some work. So two questions come to mind:
1. Where exactly do I "keep" my state? and how to I keep it immutable? Every msg will update it (add or delete something to some data structure). Do I just fold over the stream of msgs and my state lives in the fold? How can anything external to the fold access it?
2. How do you manage the IO, it's basically almost all IO w/ a small state-machine in the middle
This is a pretty typical pattern for the finical markets.

[TwoClocks]

maybe more than just two question.

Do I split (dispatch?) the msgs by type? In which case some msg types/streams will need to examine the state of other streams to do work. How does that work w/o have a mutable reference someplace?

Or is thinking about it w/ streams basically wrong?

[albertosh]

State monad? https://arrow-kt.io/docs/arrow/mtl/state/

[pakoito]

For 1 it could also be Streams, you subscribe to it, append to the previous value that’s held in a different stream zipped together.

[pakoito]

And whomever just wants the latest list uses the zipped one. It’s basically reactive programming architecture, you could start looking there.

[pakoito]

2 is also enabled in this approach, as I/O should happen in a suspend function, which are supported inside Stream and IO

[TwoClocks]

not sure what you mean by the "latest list"? You need all the msgs from the begining to build your state.

[TwoClocks]

also in this case my "state" will have 100k "things" in it in various hashes and lists. Not sure if I want to ever keep more than 1 copy of it around.

[pakoito]

I’d say measure it first. Also remember that those would be shallow copies, and persistent collections -where shallow copies are cheap- exists precisely for these cases.

[pakoito]

not sure what you mean by the “latest list”? You need all the msgs from the begining to build your state.

you have a base state and then you apply patches over it. That’s what a stream is, right?

[pakoito]

I wrote about these architectures years ago

[pakoito]

https://speakerdeck.com/pakoito/fully-reactive-apps-extended

[pakoito]

https://speakerdeck.com/pakoito/headless-development-in-fully-reactive-apps

[pakoito]

https://speakerdeck.com/pakoito/solving-all-problems-with-reactive-streams

[pakoito]

those 3 presentations should give you a picture of how to build things with streams

[pakoito]

and this companion app too https://github.com/pakoito/FunctionalAndroidReference

[pakoito]

these are from before Arrow, I believe the Streams part in arrow-fx is on par feature wise, with the addition of suspend functions :D

[julian]

@pakoito Is there a video to go with the "Solving all problems with reactive streams" deck? I couldn't find one.

[julian]

Found it!

https://youtu.be/1WF5l9zCKHw▾

[julian]

Here's a list of presos etc from Paco https://androidresources.net/author/490-paco-estevez.html

[julian]

With the release of arrow fx streams, reactive architecture (even if it's Rx) is a hot topic again.