Clojurians Log v2

@thheller has joined the channel

I’m looking at fulcro as my next potential UI library. should I skip the v1 version and directly start with v2 or how far along is that?

it might be total overkill for what I need but I like it so far

don’t like that it adds 100kb gzip by just requiring and not even using anything though

you may want to try excluding cljs.pprint and cljs.analyzer from the build in some way

Hi @thheller and welcome! I’m working on an RC of v2. Should be the next few days. It won’t hurt to start with v1. v2 porting is relatively painless.

and yes, I’d love to optimize the build a bit. There are little things like that that are needed for sure 🙂

I think in advanced opt doesn’t that get cleaned up? Not sure what you mean in that particular case. The dev user file includes some things that are useful, but that ins’t even in the prod build of the cljs.

I just required fulcro.client.core nothing else

from 2.0.0-alpha6

ah….yeah, I have not gotten to cleaning yet.

advanced doesn’t like cljs.pprint or cljs.analyzer

Good to know

Om Next pulls in compiler internals and hacks them unfortunately. 2.0 inherits that code for now, but I think I know how to fix it and get rid of that requirement. I’ll double-check on pprint.

yeah when decide to use this I’ll take a look at this and try to optimize this

confirmed…I’ll get rid of those. The source had an original team of 10…some of them were a little free with the requires

hm…not sure it is that easy 😕 Logging uses it. Is pr-str as bad? I don’t remember if that is just the impl of pprint

That’s very helpful. Thanks!

pr-str is fine

ok, that’s good enough

I don’t expect a alpha release to be optimized yet so no worries

still helpful…that was a long way off in my mind, but it’s important

cljs.analyzer is probably something that gets included for self-host support but wouldn’t be required otherwise

om.next has the same issue

I have not looked…people also use it for macro env detection, no? Oh, but that would be in a clj file…

Yeah, at the moment I’m not too worried about self-hosting env.

I expect that its only used by a macro yes. it is easy to include more than you should when trying to make self-host work.

so, I’m not familair enough with the compiler…these are the only lines:

rname            (if env
                              (:name (ana/resolve-var (dissoc env :locals) name))
                              name)

in a let

def defui*? thats macro right?

yes

or rather called from a macro.

it is a function for running the internals of a macro, yes

if you don’t care about self-host then it should be in #?(:clj ...)

if you care things get very very icky 😛

I don’t care at the moment, and it is the only dep on analyzer

I’m in the midst of testing some refactoring…I’ll do that and then see if it flies ok. Thanks for the tip

looks like that file is basically 95% macro code, might be less painful to just use a .clj file

primitives?

not at all…lots of “both”

the defui macro is just huge

indeed

I’m managing to put the compiler into infinite loops at the moment 😜

hehe doh

The equivalent of (def a a) isn’t well-liked

yeah closure does not like that

I’m moving some things around, and I don’t want the old names to break…but forgot to namespace things (on at least one).

what happens if two components have the same ident? is that bad?

nope, totally expected. PersonForm PersonDetail PersonSummaryLine

ok good

prob all have [:person/by-id ###]

@tony.kay makes sense, thanks for the help!

sure

I had to push a spec update…forgot to include the server js for server tests 😕

fulcro-spec 2.0.0-alpha6-SNAPSHOT was updated

Fulcro 2.0.0-alpha7-SNAPSHOT is on clojars. Renamed a few things (but put defs in old places to point at new). One caveat, fulcro.client.core -> fulcro.client. README-2.0 updated to reflect that. @thheller I think I got the pprint out of that one, but not the analyzer…that’ll take a little bit more work.

what happens if two components have the same ident? -> the only thing to watch out for is that when multiple components with same ident declare different forms (e.g. one component is used in person name editing popup and the other is used to edit person's description). Then you can run into an issue where one of these components initializing forms prevents the other component from initializing a different form on the same ident (since forms init checks if form is initialized).

@tony.kay Fulcro CSS still pulls from om.next https://github.com/fulcrologic/fulcro-css/blob/develop/src/fulcro_css/core.cljc#L7

it pulls but never uses

sending a PR to remove

https://github.com/fulcrologic/fulcro-css/pull/3

@tony.kay also fulcro-spec is still using fulcro.client.core

Fulcro 2.0.0-alpha4-SNAPSHOT is on clojars. This has all of the changes proposed and tested on defsc

M05-More-Concise-UI documentation heavily updated

https://github.com/fulcrologic/fulcro/blob/2.0/src/devguide/fulcro_devguide/M05_More_Concise_UI.cljs

I’m going to port a bunch of stuff over to it and triple check it is all good.

seems to be good. very much an improvement I think. Fully general and usable now

@mitchelkuijpers css support will be there in a few mins on clojars

I left notes where the validation can go in the source…it was not simple 🙂

Fulcro 2.0.0-alpha6 is on clojars, as is Fulcro Spec 2.0.0-alpha5

I still have a lot of documentation I’d like to update, and a few more renames to do…but we’re getting close to an RC1

PREVIEW release of 2.x Developer’s Guide: https://fulcrologic.github.io/fulcro/guide-2.html NOTE: This was built after I did the rename of client (which is on 2.0.0-alpha7-SNAPSHOT on clojars and 2.0.0-alpha6-SNAPSHOT of spec)

hey all, newish to om and fulcro. watched the videos and worked through the devguide. still trying to wrap my head around the data model. I’m struggling with the following: a few components in different branches of the ui graph might want to read the same data, but that piece of data isn’t necessarily easy to represent as a full-on component with an ident/query/render method. to get concrete, here’s some code:

(defui FirstComponent
  static fc/InitialAppState
  (initial-state [this params]
    {:shared-prop 1})
  static om/Ident
  (ident [this props]
    [:first-component :singleton])
  static om/IQuery
  (query [this]
    [:shared-prop]))

(defui SecondComponent
  static fc/InitialAppState
  (initial-state [this params]
    {:shared-prop 1})
  static om/Ident
  (ident [this props]
    [:second-component :singleton])
  static om/IQuery
  (query [this]
    [:shared-prop]))

(defui Root
  static fc/InitialAppState
  (initial-state [this params]
    {:root-prop 42
     :first-component-data (fc/get-initial-state FirstComponent {})
     :second-component-data (fc/get-initial-state SecondComponent {})})
  static om/IQuery
  (query [this]
    [{:first-component-data (om/get-query FirstComponent)}
     {:second-component-data (om/get-query SecondComponent)}]))

{:root-prop 42,
 :first-component-data [:first-component :singleton],
 :second-component-data [:second-component :singleton],
 :ui/locale :en,
 :first-component {:singleton {:shared-prop 1}},
 :second-component {:singleton {:shared-prop 1}}}

Hey @mss. welcome. So, share data has a special query notation so you can save it at the root node. [ [:root-key '_] ] is a query for something in the root node

It’s a “unique ident”

so [ [:first-component '_] ] on your database would return {:singleton {shared-prop 1}

Idents are really meant for things that have a clear identity…like a persistent entity. The “singleton” approach is if you have a specific UI component that you’d like to link up in the graph more naturally…so inventing an id that ends up making a single entry in a table is useful when you want to link something into the graph.

The entire graph database is designed for solving the data-sharing need. I noticed you didn’t actually use any links from within components in your sample graph…so you really are just linking back to root.

I’m glad to help clarify things further if that isn’t answering your question.

perhaps an example will help:

{:shared-prop 1  ; in the database, at root
}

(defui
  static om/IQuery 
  (query [this] [ [:shared-prop '_] ])  ; query of root node
  ...
  Object
  (render [this]
    (let [{:keys [shared-prop]} (om/props this)] ...)))

I believe I use this in the websockets demo app, and the template for the current logged-in user.