Fork me on GitHub
#reagent
<
2017-01-03
>
kishanov01:01:33

@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

gadfly36101:01:29

@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

gadfly36101:01:47

Benevolent dictator for life

gadfly36101:01:36

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

notanon01:01:02

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.

notanon01:01:45

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

notanon01:01:20

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

notanon01:01:42

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

notanon01:01:30

i remember that picture differently

gadfly36101:01:07

@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 ... https://github.com/Day8/re-frame/issues/137

gadfly36101:01:47

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

notanon01:01:33

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

notanon01:01:57

what challenge does it present you gadfly?

gadfly36101:01:06

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.

notanon02:01:19

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

notanon02:01:47

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

notanon02:01:53

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

notanon02:01:37

... im probably just missing the details.

notanon02:01:12

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

notanon02:01:42

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

gadfly36102:01:53

@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.

gadfly36102:01:51

@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 ;)

notanon04:01:01

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

notanon04:01:30

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

notanon04:01:48

thats why i love clojure and not haskel 🙂

notanon04:01:55

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

notanon04:01:07

i only spent roughly 30% of the time confused

notanon04:01:28

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

notanon04:01:56

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

notanon04:01:32

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

notanon04:01:38

just want to prove them out

val_waeselynck13:01:33

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

val_waeselynck13:01:54

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

derhowie20:01:33

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

...
:component-will-receive-props 
(fn [this new-argv]
       (do-something (second new-argv)))
...

pesterhazy20:01:16

@derhowie funny you mention this

pesterhazy20:01:53

I think that's the right way

pesterhazy20:01:52

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

pesterhazy21:01:18

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

pesterhazy21:01:39

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

kishanov21:01:50

@derhowie I guess this might also work

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

pesterhazy21:01:27

@kishanov that'll give you the old props

kishanov21:01:41

doesn’t it depend on the signature of react lifecycle method that one tries to use? i.e. https://facebook.github.io/react/docs/react-component.html#componentwillreceiveprops accepts nextProps as the only argument, while https://facebook.github.io/react/docs/react-component.html#componentdidupdate accepts prevProps and prevState

pesterhazy21:01:14

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

kishanov21:01:53

@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?

mattsfrey22:01:12

thats actually a really interesting pattern

mattsfrey22:01:20

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

mattsfrey22:01:29

your method with the ref seems a lot cleaner

mattsfrey22:01:41

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

pesterhazy22:01:44

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

mattsfrey23:01:14

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