@niwinz: I read your blog post, very interesting. https://www.niwi.nz/2016/04/03/application-architecture-and-state-management-with-react-based-applications/

thanks!

\o/

Has anyone used devcards with Rum?

I don't know...

Oh @niwinz one question that I got when reading your post: can you change your app state through figwheel, or is it.. "hidden" inside the stream objects?

Yes, you can do it

as I have explained, a function is already implement the pure state transofrmation protocol

so you can emit a function that does whatever you want with the state

(emit! #(assoc-in % [:some :path] value))

and you have some atom that holds the whole app state somewhere, right? So you can just deref it?

yes, but is not mandatory

the atom is just a materialization of state

so if you modify that atom with swap! or reset! that changes will be overwitten at some time (strictly speaking on the provided example and how I use that)

Hmm, I see. Hopefully I'll have time to look at your source code at some point

looks like a pretty good approach. Similar ideas as re-frame, and many others..? Though I do like the use of records

I believe re-frame uses keywords for events

I know about re-frame and some others

but they have not convinced me

Hmm, yeah. Pretty much the same with me. I'm sure re-frame works great, but I'm a bit skeptical how it would scale when your app gets really big.. I'm in a project that's been going on for 1.5 years with 6 devs, and what I understand from re-frame, I worry that it wouldn't work for us

and I don't like use "frameworks" or libraries in the core of my application. I prefer use libraries on the corners and leve the application core under complete my domain

I'm not sure I like using Rx though. I've used it before and it's really good, but somehow I'd like to see a solution that didn't introduce such a "heavy" dependency. When you use Rx you're pretty much married to its ideas

and there's quite a lot to learn

yeah, it is, is a really a tradeoff

In my case I reall like the rx approach

so it is ok from my side use rx

but as I have said on the end of article

that works for me but I can't assure it will work for every project/team

yeah

I wonder if the details of Rx can be hidden?

I guess you have to know Rx when writing WatchEvent records..

Yes, this is the way to handle async stuff

I have thought about that

and using something different than rx makes thinkg much less composable

for do something like that you should choice your abstraction and have a little bit coupling with that solution