Omchaya hasn't been touched in ~25 days, mainly because we've been exploring some pretty deep rabbit-holes around this, and haven't had time to come up and consolidate it all. A few thoughts before I run out:
We don't make enough use of Om's features for Omchaya - we should definitely be using :shared, for example. I'm not sure if it was available at the time, but we certainly didn't stop and find out what it was until recently (which is a bummer for us, it's a great idea) The components in Omchaya aren't reusable in the slightest, mainly because they conflate layout, styling, component tree-structure and app-state structure. I wrote some slides for a short talk I gave at the last sfcljs meetup http://sgrove.github.io/talks/understanding_ui_complexity/understanding_ui_complexity.html#/ We've figured out a good way to separate component-tree structure from app-state that's worked out very well for us, and that's by representing as much as possible as data, and using functions to transform them. We've also started experimenting with layout systems, which are a nightmare in the browser (and a generally involved topic anyway). This is something that the performance of om/set-state! (and a non-rendering version of om/set-state!) is great for, but kills the ability to swap out layout engines. To that end, with the right hooks, we may end up bypassing a lot of Om since with the almost-everything-as-data approach we have (potentially) much better whole-app awareness. But, all that is to say, it's early days, and it's pretty exciting to be able to improve on that nightmare that is browser UI, and potentially end up with a much better story than the native world has enjoyed for over a quarter of a century. It's kind of the wild-west, and we should be experimenting like crazy. On Sat, Mar 29, 2014 at 9:23 AM, David Nolen <[email protected]> wrote: > This is getting closer but I think will write up my own thoughts/opinions > on Om application architecture soon. While the existing tutorials are nice > for understanding how Om works, I think a rough guide to architecting Om > applications would be useful to all - not the least because it will likely > need many refinements as we put the ideas into practice. > > David > > > On Sat, Mar 29, 2014 at 5:22 AM, Daniel Bell <[email protected]>wrote: > >> So, I figured it out, and wrote a blog post on why this is a terrible >> idea: >> >> http://roninhacker.wordpress.com/2014/03/29/how-to-build-stuff-with-om/ >> >> -- >> 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. > -- 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.
