Fork me on GitHub

@notanon we started with vanilla Reagent 2.5 years ago to build complete front-end for our enterprise-ish application (several dozen screens, interactive visualizations, 7-step wizard and probably a hundred of forms). Eventually we realized that we need some consistent structure for the app and invented our own re-frame-like abomination. A year ago we switched to re-frame and continue using it. Complexity is tamed, but sometimes we’re finding a lot of interesting discoveries, cause there is not a lot of good information on how to build really large apps


@notanon I use vanilla reagent for a few large applications, but have drawn a lot upon re-frame's separation of concerns. I'd likely switch to re-frame altogether if team size grew (right now just me on frontend) .. since there is a wealth of documentation, an activity community, and a very approachable/knowledgable BDFL in @mikethompson


Benevolent dictator for life


Just something people call the author of a prolific language or library :)


thanks @kishanov & @gadfly361 . my thoughts right now are that SPAs have a limited # of use cases that need solved e.g. handling UI events, updating state and re-frame seems have to have solved these already... no reason to reinvent the wheel.


i just don't want to get into a slippery slope of 'frameworks' where... well re-frame didn't think of it, so i'm stuck


i don't mind writing some glue if there's smaller libraries that can tied together


re-frame appears on the surface to be more than the sum of its parts though


i remember that picture differently


@notanon while i am not a re-framer (yet) i can say that anything i have done in the last 2+ years appears to be well within the grasp of re-frame. I am personally holding out for this tho ...


That said, for most everything i do - holding out for that is completey unnecessary lol


i understand the desire in principle, but i dont see any actual issues/problems/problematic use cases listed in the the github issue


what challenge does it present you gadfly?


Well first, i enjoy using devcards - practical means of documenting / developing reusable components. Second, is concept of making sub-apps within an app (while this is rare, maybe ill-advised?, it's something i have to account for). Third, testing. I find re-frame makes your functions pretty pure and unit testing is great. However (and this could just be from ignorance) i find it easier to do browser based testing with vanilla reagent. I explicitly pass around my global ratom as an argument, which helps me sandbox tests.


the reusable components one really surprises me. i would think you could require in a namespace and have it add its event handlers and make its components available. i must be missing something


(please forgive me... i've been looking at re-frame for a total of 30 minutes now)


if the reusable component used namespaced keywords as its keys into the global db, it should be fine in practice?


... im probably just missing the details.


this was how i was planning to organize my app before you mentioned the github issue and when @kishanov mentioned the question of how to organize/structure large apps


because i will definitely have a need to build reusable (at least within the same spa) 'widgets'/components. like an autocomplete multi-select box


@notanon i have difficulty bc re-frame has one, implicit app-db (not passed in as an argument). As a result, there is no sandboxing one component with its own instance of app-db. Currently, the one app-db is always shared. However, it is all about trade-offs. What you gain from it being implicit is an easier time making things declarative and not passing around an extra argument everywhere.


@notanon also i dont mean to suggest that it is hard to make reusable components in re-frame, quite the contrary ... it is just hard to use devcards, which - while awesome - is just a convenience ;)


@gadfly361 i see. yeah i can understand the desire to have all the functions be pure.


although i will always choose practicality over principle if i must choose


thats why i love clojure and not haskel 🙂


i spent a good hour trying out reframe... went ok


i only spent roughly 30% of the time confused


which is pretty good considering i didnt read anything, just fired up a project and started typing


definitely going to dig in some more this week...


i feel like all the right use-cases are solved for me


just want to prove them out


> cause there is not a lot of good information on how to build really large apps


@kishanov do you know any frontend framework for which there is such good information ? 🙂


Is there a better way to grab new incoming props? Right now I'm doing this:

(fn [this new-argv]
       (do-something (second new-argv)))


@derhowie funny you mention this


I think that's the right way


I've started working on a library that makes this a bit simpler


in particular when you want to do the same thing on mount and when props change


(e.g. make an XHR request based on props)


@derhowie I guess this might also work

(fn [this]
         (let [props (reagent/argv this)]))


@kishanov that'll give you the old props


doesn’t it depend on the signature of react lifecycle method that one tries to use? i.e. accepts nextProps as the only argument, while accepts prevProps and prevState


@kishanov right, you could use component-did-update, though that's called after rendering


@pesterhazy I understand that, I’m trying to clarify which arguments Reagent function that is passed as a value to lifecycle method key should receive. My assumption was that if in React’s documentation lifecycle method (like :component-will-receive-props) is expecting 1 argument which is nextProps, wouldn’t Reagent resolve (reagent/argv this) to nextPros and not something else?


thats actually a really interesting pattern


my team so far has been tagging the component with a unique id and then having a getElementById query set the atom on component-did-mount


your method with the ref seems a lot cleaner


are there any potential side effects or issues using the ref introduces?


Not to my knowledge, it's the method preferred by the React developers


yeah, thats awesome. going to start using that instead, thanks for putting the time in for that, serious protip!