Create a gist now

Instantly share code, notes, and snippets.

@cdzombak /a.md Secret
Last active Aug 29, 2015

What would you like to do?

Your diagram is very close to my mental model, yes. I've diagrammed my model of the flow here: https://dropbox.dzombak.com/twimages/Scan%20Feb%2028%2C%202015%2C%2023.47.pdf (edit: oops, that rightmost path from "auth" to "return code" should be marked "catch error", too)

They key difference between this and your diagram is very small, but I think it's important. All the logging in ThingsHub is explicitly a side effect, added in do* blocks; while the results are handled (and transformed into a return code) in the normal Reactive value-transforming way. My diagram just makes that a little clearer.

This distinction makes sense if you consider this program as a function, with one input (the state of the configuration on the filesystem) and one output: the return code with which the program exits.

Everything else—including most the useful work—is side effects, and at this high level they're modeled as such; the sync engine performs some work reports on progress, and side effects report on that progress, but the core flow of data through the program (config -> auth -> sync -> result code) is what I've modeled in my signal graph.

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