Micro-Apps on front end with Micro-Services on backend and having routing both within each micro app on the client as well as server side routing and common footer/header allows us to segment features into apps and still have one continuous UX
with a cursor abstraction like the one i posted using cursor functions and runtime polymorphism via multi-methods (pattern matching like) we can have our cake and eat it ;) and no re-frame... Although I am very much liking it, just cant justify it If enough people are interested we can give a meetup talk about our MicroApps strategy that eliminates the challenge of building or adopting higher and higher abstractions as your application grows in complexity because it is confined to 200-500 lines of code per micro app... I couldnt have thought of this app architecture strategy. It was someone far more brilliant :) but i cant say enough about how much less headache we have to deal with and how much more we are focused on content as opposed to architecture as a result of it The argument for moving to higher and higher abstractions as complexity grows is an old argument as old as computer science but we bypass that via the aforementioned micro app strategy Sent from my iPhone > On Apr 29, 2015, at 2:40 PM, Mike Thompson <[email protected]> wrote: > >> On Wednesday, April 29, 2015 at 5:21:05 AM UTC+10, marc fawzi wrote: >> Hi, >> >> >> I'm still processing the "revolution in front end architecture" that brought >> me here and to Reactive CLojureScript! :) >> >> >> >> One part is this whole thing about putting ALL logic outside of the >> component/view. >> >> >> I think maybe we need a finer lens (or maybe I'm missing something) >> >> >> >> Let's say you have some app-state-driven animations, e.g. launch some >> animation when user interacts with your component or ajax callback writes >> new data to app state, where would you put the logic that would add/remove >> CSS class names from whatever element in your component or that would drive >> an animation via code rather than CSS (e.g. style tweening or some canvas >> animation) in response to state changes? Why would putting it in the view >> be inferior to putting it in a handler? After all, it's very specific for >> the component and most likely not resuable for other components (animations >> are very tailored instructions) >> >> >> Not really sure why animation logic that simply reacts to app state changes >> should be anywhere outside the component. Obviously, the opposite is true >> for business logic. >> >> >> Would love any insights about the subject (especially ones that are contrary >> to my understanding, so I can understand things better) > > > Marc, it depends on how complicated your app is. Cursors work well enough in > simple cases. In the reagent meetup you said your app was 200 lines long, in > which case that's tiny enough for Cursors to be a fine choice. > > But as apps get more complicated, Cursors are probably not the right > foundation. In my experience, they tend to force control logic into all the > wrong places (views), and they don't easily handle the kind of cross-cutting > architectural concerns that arise in bigger apps. > > Daid Nolan comments on this in the 3rd paragraph of the Advanced OM Tutorial > https://github.com/omcljs/om/wiki/Advanced-Tutorial > > Brandom Bloom recently commented here: > http://www.brandonbloom.name/blog/2015/04/26/rarely-reversible/ > > It is even addressed indirectly by Martin Fowler: > http://martinfowler.com/bliki/CQRS.html > > > -- > Mike > > -- > Note that posts from new members are moderated - please be patient with your > first post. > --- > You received this message because you are subscribed to the Google Groups > "ClojureScript" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/clojurescript.
