I like the mini app approach, but I think it can still benefit from something
like re-frame. In many cases, you will still have a lot of shared code -
domain logic, reusable widgets, etc. Having a common set of abstractions
across apps would be very beneficial as the project grows.
This has
Ah, the good old 'package by component or technology' debate... I tend
to fall on the component side, simply because I think it scales better
and is how I think of the app, but I can see the merits of both sides.
On 26 March 2015 at 15:19, Marc Fawzi marc.fa...@gmail.com wrote:
Jamie,
That
Coming from the Rails world as I do, I'd invert that:
handlers/page01.cljs
subscriptions/page01.cljs
views/page01.cljs
etc.
Jamie
On Mar 26, 2015, at 3:32 AM, Colin Yates colin.ya...@gmail.com wrote:
How would you structure this for an SPA with multiple top-level
'pages'? I am thinking:
Jamie,
That makes sense unless you build out your site based on micro services
(which coordinate among themselves) and then have micro apps on the front
end (each consisting of 1-4 pages and mapped to individual features of your
app) that don't need to share state/data. In that case, you'd want
My bias comes from having worked in Rails for so long. There is no perfect way.
Frankly, after reading the discussion with you and Mike, I can see why
organizing by page would be better in some situations.
On Mar 26, 2015, at 11:24 AM, Colin Yates colin.ya...@gmail.com wrote:
Ah, the good
Thanks Jamie.
On 25 March 2015 at 14:59, Jamie Orchard-Hays jamie...@gmail.com wrote:
I've been playing with it the past week or so. I started with the figwheel
template.
lein new figwheel name-of-dir -- --reagent
Then added re-frame and other dependencies.
Diggin' figwheel
Jamie
On
I did the same. Started a new reagent figwheel project and added re-frame
as a dependency manually.
On Wed, 25 Mar 2015 15:01 Colin Yates colin.ya...@gmail.com wrote:
Thanks Jamie.
On 25 March 2015 at 14:59, Jamie Orchard-Hays jamie...@gmail.com wrote:
I've been playing with it the past
