Fork me on GitHub

Fulcro 1.2.2-SNAPSHOT on clojars. It has a much improved defsc that should work for 99% of your component defining needs! See the docstring on it…it’s long…here’s a sample:

(defsc Root [this {:keys [ui/react-key child] computed children]
  {:query [:ui/react-key {:child (om/get-query Child)}]
   :initial-state (fn [c params] {:child (fc/get-initial-state Child)})
   :css [[ {:color :red}]]}
  (dom/div #js {:key react-key} 
     (ui-child child)))
You can now mix and match lambdas and the original data-based values in the options. Say you want to use a theme from some global atoms, just use {:css (fn [this] [[ {:color @theme-color-1}]])}!


short, concise, props/computed destructuring, If you use the data-template style, it even validates you’ve not got a type:

(defsc Root [this {:keys [ui/react-key child] computed children]
  {:query [:ui/react-key {:chil (om/get-query Child)}]}
  (dom/div #js {:key react-key} 
     (ui-child child)))
Will warn you that you’ve destructured :child but you joined :chil


If you use the lambda forms, I cannot interpret your code, since it is arbitrary, so you lose the error-checking.


NOTE: for those newbies lurking…the CSS requires you actually add the fulcro-css dependency 🙂


FULCRO 2.0 RC1 Nearly complete Any More Input??? The last task on my list is to finish renaming things. There have been some votes for various naming in this issue. I am leaning towards moving a few more things, if possible. The new primitives namespace (rename of next.cljc) doesn’t have to stick with that name. It was the best I came up with at the time. Please see issue I plan on taking most of tomorrow off. Thursday I’ll do the renaming and clean-up, and some fancy git footwork. If that all goes well, I’ll cut RC1 sometime Thursday.


Is there a way to grab a vector of components used in a router? i.e. for getting the value of include-children for a Root component for fulcro-css. Example here


There isn’t some global registry of components, no.


If they were related via query, you could pull the query and scan it for things that have css


The query is annotated with metadata of the components


so you could technically find all of the components in the (static) query scan for metadata with :component in it, and pull things programattically that way. But, why not just include them into Root by hand?


so, yeah, for a router, that would work


you know Clojure well enough to know how to do that easily? @devo


for just a router, I think this would work:

(->> (om/get-query RootRouer) vals (keep (comp :component meta)) vec)


The values of the query are the things that you can route to (it is a union query)


Just didn't want to maintain the vector of components in both the router and the root component.


yeah…but you might need to also filter by the ones that have css


see the source code of fc/get-initial-state to see how to do that in a cljc-compatible way if you’re doing SSR


basically the clj version has static methods in metadata, and the cljs side works with implements?


This might get just the ones that have CSS

(->> (om/get-query RootRouer) vals (keep (comp :component meta))
      (filter #(implements? css/CSS %)) vec)


I should probably add that to routing.cljc


oh wait…can’t…hard dep on css.


Had to make a couple tweaks to the snippet to get it working, but seems good now.


(om/get-query RootRouter) was yielding [:id {:current-route {:index {...} :about {...}}], so vals was breaking.


@tony.kay hey, about the new syntax, there is one thing that would be cool but might be a bit harder to implement is that, instead of: :initial-state (fn [this, params]), :initial-state (fn [params]), but then, pull the this from the defsc params declaration I think it's about getting the name for the this (first arg of defsc) and add that as the first param of any internal function would be kind like records makes sense?


@wilkerlucio Is it already possible to use pathom with fulcro 2.0? Not sure if you have to do special stuff for that or if it will just work


@mitchelkuijpers didn't checked yet, but I guess it should mostly work, the tx-listen might break because Fulcro 2.0 sends new types of events, but otherwise I guess it might work, please let me know if you try 🙂


I will try it tomorrow, mostly for the server-part


And I want to add placeholders to the client


We will find out tommorow I guess ^^


@devo….oh right…the union is a generated component one level down. The router has tracking props


@wilkerlucio oh, I see…so treat this from the outer scope…the downside is the signatures then look odd. It is easy to do, I’m not sure I like it.


because in defrecord methods you still have to say this


what I like about it at the moment is that it is full consistent in the body. I you add extra protocols, those have to say this, and that would be a littler harder change (and you could argue even less desirable)


(defsc Boo [this ...]
   {:query (fn [] ...)
(defsc Boo [this ...]
   {:query (fn [this] ...)


hm…now that I type it I might agree with you 😜


yours looks more like a functions closing over things


anyone else have an opinion? I’ll give it a few hours to percolate on the channel


@tony.kay I tend to agree with @wilkerlucio, this represents the same thing so why have it show up twice?


@tony.kay another feature that came to my mind here, on regarding the the load


the docs says that load ignores the :target when the query is for an ident


one case that I often need is to load from an ident, and then I want that ident injected in some root key (usually something like :ui/root)


because the root is clean, and my actual root has an ident, if the :target worked properly, we could load from the ident, and then create a reference to that ident somewhere on the app db root


@wilkerlucio That’s another good observation, and esp now that target supports append/prepend/etc, it makes even more sense


I’ll both changes to my TODO list