https://github.com/StankovicMarko/invoices/ i think i have flow here luminus+re-frame with completed register /login

btw. my still-not-working code to get the registration working is about 140 LOC while a (working) Reagent-only implementation of the same process is about 37 LOC. Is that expected?

@U45SLGVHV Thank you very much!

140 might be bit much but re-frame has more code true but really keeps you sane i remember developing my first app using reagent it got really messy toward the end cause i didn't have awareness of handling atoms gracefully re-frame does that for you and it is helpful in that regard for bigger applications small hobby like projects - reagent might be better choice

I see. Your code here matches almost exactly my Reagent only implementation - with just a little re-frame sugar on top. I might have done it way to complicated, implementing a state machine. 😄

yea, my implementation is not very re-framy but it gets you going later you can improve like use re-frame reg-fx instead of reg-event etc etc

Thanks again. First time I feel like a beginner in years building this stuff. Like I know nothing about programming …

@U45SLGVHV I ported an elaborate web app from JS to re-frame and reagent as a way of exploring them and found reagent simpler, but to your point, I have been hacking away with my own reactive library for decades. Along the way I had an epiphany that ratom programming might not seem so natural to normal people. 🙂 I am thinking about blogging up an intro to the paradigm so your experience sounds very relevant. Can you share more, here or by DM?

i can share more sure 😄 what are u interested in? sorry in advance i am little bit out of it very busy day today brain is at 20% 😄 if u got any questions i will send answers just little bit later @U0PUGPSFR

OK, asynchronous communication is always the best. You mentioned perhaps not “handling atoms gracefully”, and sth. about at a smaller scale it was OK. I guess my first Q would be how deep did you go with atoms? I just refreshed my memory on my own app and saw vanilla derefs, then cursors, then track. Did you get into all that or more?

to answer your question @U0PUGPSFR i just felt that there is and should be better way of dealing with atoms than what i was doing. i did use derefs and bunch of atoms, i had 1 that is app state but then almost an atom for each component/view to handle errors or async data. don't remember using cursors and track. there was no need for them... hmm maybe there was but i didn't get to use them i know that once i saw reframe the flow of information and the way i was doing things in reagent were pretty much the same in re-frame i just didn't have to think about atom, it's state i was pretty easy to switch. thought i should mention i am not using re-frame the 'right' way meaning - all conventions but i am learning as i go

This reminds me of what Mike wrote in the FAQ about “why not just use reagent?” — the ad hoc solutions we would inevitably invent will prolly not be better than re-frame, so we can save ourselves the trouble. In your case it sounds like you did not get as far as developing your own re-usable framework before discovering re-frame and realizing it would save you a lot of wheel-reinvention. I can definitely see how an ad hoc approach to organizing ratoms could get “interesting” fast. 🙂

yea that's true

As an aside, ratoms are great for async. Shoot that request out and whenever it comes back, bam, straight into the model it flows. Thx for the insight into your experience.

i have a couple anecdotal cases where reagent-only projects very quickly turned into a poor-man’s reframe. the event driven model just fits so well to UI work that you will end up somewhere similar quite often. in that case, might as well use reframe which really does have some fantastic concepts, tooling, extensibility, docs, etc.