Fork me on GitHub
#re-frame
<
2016-09-04
>
shyambalu00:09:10

anyone got any tips

shyambalu00:09:22

on organizing larger apps

shyambalu00:09:49

the re-frame docs method of panels is too simplistic for SPAs

mikethompson03:09:36

@shyambalu that approximate approach (as per the re-frame docs) works for us up to about 20K of (client) code. We have full drag and drop pivot tables and popups galore, and workflows down the left and blah, blah , blah. Certainly not trivial. Our apps tend to be very SPA-ish in the sense that they don't need to interact with servers much. They load a blob of data and then run fairly independently of the server for long periods of time. So, I guess I'm saying that we develop biggish apps which tick a lot of SPA boxes and we use the approach described in the docs. Everyone's needs are different, of course, but I wouldn't dismiss that kind of approach out of hand.

shaun-mahood03:09:49

@mikethompson: One thing I've not been clear on in that approach - it you havr multiple sections of your app (say there is a menu on top, a summary view on the left and a detail view on the right), would each of those sections count as a single panel in that approach? Or is there some other distinguishing feature that you would use to determine what constitutes a panel?

mikethompson23:09:50

@shaun-mahood that's a good question for which I don't have a good answer. "It depends" is always the answer to these kind of design decisions, but in this case, I'm not sure what it depends on.

mikethompson23:09:28

Just to state the obvious: the more distinct or separate the GUI units, the more they should be separate "panels".

mikethompson23:09:55

I guess, you can look at two GUI units from a data point of view -- if they deal with quite distinct data (in app-db) then that probably means they should be different panels. Or you can consider function ... if the two GUI units have a quite different purpose (from a user's point of view).