Hi Leon, So the reason for rx bindings not being default is really quite simple - freactive is not a macro framework but uses pure functions and I preferred giving more power to the user rather than doing something "auto-magically" that may not always be desired. One could write a simple macro that wraps all the relevant forms with an "rx" but I'm not sure this would be a good idea - you would lose the ability to be specific about bindings (rx's are only one type of thing that can be bound), it would add overhead (you don't need a binding on every form) and using macros can have other unintended consequences (you couldn't use pure functions that return virtual DOM - i.e. hiccup vectors). The main macro freactive provides is the rx macro which is really a thin wrapper macro which generates an instance of ReactiveExpression for its body - it is one type of thing that can be bound, but not the only thing (atoms, cursors, etc. can be bound directly). Now, it may seem that this makes freactive more verbose than say Reagent, but this is not really true at all - you don't have to use rx's everywhere. If you just wrap whole functions/components in a single rx, you'll get something pretty similar to a React component (especially when diffing gets enabled in the next major version) - the performance will be quite good (probably similar to React). The ability to place bindings (i.e. rx's, atoms, etc.) directly on attributes or text nodes allows additional performance gains because the binding is direct and specific - you don't need to use it if it feels unnecessary, but the framework allows it and will optimize based on what you tell it. Does that make sense? Basically using more rx's may allow better performance for things like animations, but it's totally optional - you can just use one rx around the whole body of a component if you like...
Regarding transitions and callbacks, this API will change a little in the next version (the transition names will change) but the general concepts will remain the same. Right now, :on-show receives a callback, but in the next version it won't whereas :on-hide will and it will need to be called. The reason for needing to call this callback is because this callback is actually what hides/removes the element. The :on-hide transition is there so that you can apply some sort of fade effect, but if you don't call the callback, the element won't actually go away. This gives the user considerable power to screw things up (by not calling the callback) but I think it is useful to allow this so that people can apply fade transitions. On Sat, Dec 20, 2014 at 3:18 PM, Leon Grapenthin <grapenthinl...@gmail.com> wrote: > Hi Aaron, > > I am currently experimenting with freactive. I find it quite awesome to > begin with. > > Here are some questions that I found unanswered: > > - Why are rx-bindings not the default? It feels a bit redundant to wrap > forms in (rx ...) all the time. > > - What is the rationale behind the second argument "callback" (to one of > :on-hide or :on-show)? I noticed that sometimes it is passed and sometimes > it isn't and that I have to call it when it is passed... > > > On Thursday, December 18, 2014 3:28:12 AM UTC+1, Aaron Craelius wrote: > > I've just posted gists about the items-view and observable collections > proposed for freactive. > > > > In case anyone is interested in discussing please comment on the gists > themselves. > > > > observable collections: > https://gist.github.com/aaronc/0654151190b9145dd473 > > items-view: https://gist.github.com/aaronc/5d497aa61e27ce924178 > > > > And yes, these components would be separate modules from freactive core > and dom, the observable collections could be used independently of the > items-view and everything could (and probably will be) split into separate > projects. > > -- > Note that posts from new members are moderated - please be patient with > your first post. > --- > You received this message because you are subscribed to a topic in the > Google Groups "ClojureScript" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/clojurescript/99myJ9vLeKQ/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > clojurescript+unsubscr...@googlegroups.com. > To post to this group, send email to clojurescr...@googlegroups.com. > Visit this group at http://groups.google.com/group/clojurescript. > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
