fulcro 2018-03-07 | Slack Archive

tony.kay00:03:38

Just pushed 2.3.2-SNAPSHOT to clojars. This includes a new fulcro.client.alpha.dom namespace (work in progress). This new DOM support allows a much more compact DOM definition. The current status is “mostly working (see below)” for both client and SSR. It should be drop-in compatible with current components (just change your require), but it allows for the following syntactic shortcuts:

(ns app
  (:require [fulcro.client.alpha.dom :as dom :refer [div]]))

...
   (div "Hello") ; optional parameters
   (div :.a#id "div with class a and ID id") ; hiccup style IDs and classes
   (div {:id 1} "content") ; no need for #js, it auto-detects literals and converts at COMPILE time
   (div {:style {:color :red}} ...) ; automatic recursive COMPILE-time conversion to js. Again, no need for #js 
   (div some-binding "Hello") ; RUNTIME conversion of cljs data props into JS. 
   (div :.a {:className some-class} "classname mixing from keywords and props") ; results in classes a and some-class (from a binding). BROKEN.

As you can see we end up with something as tight as Sablano without the need for a wrapper. The performance is just as good as the versions with #js as long as you use literals (the common case). This result is mostly the work of @thheller (who already had the client-side macros working) and @currentoor who has been integrating it and adding the hiccup-style support.

petterik10:03:10

This is awesome! Any chance it could be released as a standalone library? fulcro.dom?

tony.kay20:03:58

So, if you’re just doing some cljs project you have Closure, so pulling in Fulcro won’t hurt you…you won’t get what you don’t need in the advanced compilation. I have no desire to maintain it as a separate library. Each and every artifact that is separate generates a bit more testing, release, and other overhead at each release, and I simply don’t have the time, nor do I see the benefit outweighing the cost. In fact, the only benefit I see at all is that you would not get the server deps, but you can always use dependency exclusions. Most of the server-side stuff would be in most servers anyhow (e.g. ring).

cjmurphy03:03:53

@wilkerlucio: It is good to be able to easily recognise quickly what is a table rather than a top/root level join. I don't know how this could be done without a convention (like by-id on the end) of some sort. It would be good for instance in Fulcro Inspect if the developer/user could see real tables in a different colour or in a separate section. A convention means you don't have to remember all the names of your tables. So much easier for maintenance to have this convention.

wilkerlucio03:03:22

@cjmurphy we could incorporate if there is a deterministic way of knowing it, the convention by-id is totally optional and we can't enforce or be sure of it. I think we could have something like that if we get :fulcro/tables back to the DB, but without knowing for sure if fells flacky, to be honest I usually only have one key that isn't a table (`:ui/root` mostly), any root join ends up turning in an ident, so I don't feel it, but I would like to understand how is this working on your side. how are you using it? you have many non tables at root?

cjmurphy04:03:20

@wilkerlucio Well people can have links, and links are used often enough in demos etc. (Personally I avoid using links too - so not really talking about 'my side'). Links are top level / root joins that can have whatever you want in them. Also when constructing Idents, or just seeing [thing/by-id 10] helps me understand mine and others code. It is definitely 100% an Ident if I see by-id there, I don't have to do further thinking, don't have to remember the names of tables (or alternatively the names of the root joins). Good to see conventions enforced, which is exactly what https://github.com/chrismurrph/default-db-format does, with a tiny amount of configuration if conventions are adhered to.

wilkerlucio04:03:11

I can understand that, not really against it, it just that the trade-off doesn't pay IMO, all id/table attributes that I see end up in /id anyway, so this is enough, and the cost of server attr translation is much worst for me, but you know, tradeoffs 🙂

2018-03-07

Channels