Fulcro 2.5.11 on Clojars. This release cleans up networking just a bit. I found some minor issues while creating this file upload demo: https://github.com/awkay/file-upload-demo Also Fulcro Inspect had a few little issues around networking as well, but those are fixed in Inspect beta8 (which is currently a snapshot).

I also just updated the book some with respect to middleware docs: http://book.fulcrologic.com/#_client_response_middleware

@tony.kay do Follow-on Reads (in prim/transact!) trigger ui refresh if the component is the reconciler?

if you transact on the reconciler, you get a root refresh

does that mean follow-on reads are obsolete there?

no, not obsolete

not useful

thanks

follow-on reads never meant anything when reconciler is used with transact

@tony.kay in the patreon post you mentioned shadow-cljs and mount. Is mount the lib you preffere between component/integrant/mount ?

Still trying to pick one of these :))

I’ve recently started using mount and really like it. Cleans up things quite a bit, actually…a lot less OO

integrant uses component I think

I just put an update in the book http://book.fulcrologic.com/#_rolling_your_own_server

that little bit of code is most of “easy server”, and integrating other “things” with it is as simple as throwing them into the env in the wrap-api

no need for parser injections and other such backflips

The Duct framework used component but now uses Integrant. On my side I really like Integrant.

so is Integrant using component internally?

oh…I see…I was looking at the wrong docs

after looking over the docs, I still think I like mount better personally…part of what I really like about it is that you don’t have additional config to manage. In component you’ve got to “build the system” out of OO components. In Integrant your “config” isn’t even easily coupled to the code that does the actions (defmethods are not well supported by nav in IDE/editors). In mount, you just defstate things and require them. It’s eliminates tons of cruft, but still gives you the power to “sub out” parts of the system. More importantly: navigating the code is natural and supported by the IDE…want to know where that “config” thing is coming from? Hitting “jump to definition” in the editor takes you right to the defstate. The biggest possible downside is: if you require it, you get it. So, stale requires in a namespace can accidentally start up something you didn’t need.

My current library recommends when building a new business software project are pathom, mount, promenade, clara rules, datomock (if using Datomic). I’m playing with immutant web server instead of httpkit, and it seems good so far, but nothing has stood out about it for what I’ve done to date (other than the benchmarks are better).

I’m sure my list will expand as I find further holes. The promenade library has a lot of alternatives, but I liked his approach to a monad-like error handling. I think the library could probably use a bit more, but it’s a nice clean start.

I have not used Mount at all, and I didn’t mean to push you in the Integrant camp. I used Duct at work hence it’s “closer” for me.

@tony.kay there is a root render on the transact on reconciler, even if the user send an ident too?

@wilkerlucio good question…I don’t remember on that case

so, reviewing the render code I may be misrepresenting what using the reconciler does.

when it is use as transact source

transact itself queues the ident of the component, OR the explicit ref (if given), and any declared refreshes on the mutations that ran. So @myguidingstar I think I misled you. I was thinking about swap! on app state, not transact on reconciler

It also, of course, queues any keywords that are in the transaction

transact is always a targeted update…I obviously was not awake enough when I answered that question

it auto-queues the component if it has an ident (which the reconciler does not). Using the additional ref arg (as Wilker points out) is a substitute when using the reconciler and you want :ref to be in the mutation and refresh list.

I thought there was a code path that said “if nothing is queued, then root refresh”, but I’m not seeing that as I look through the code…so a transact on reconciler with no ref or follow-on reads would refresh nothing. I need to test that, because that is not an intended behavior

@tony.kay to me the current behavior was my expectation, I'm afraid if we don't send nothing we might get unintended heavy refreshes, if this is the state I would prefer it stays that way since it's already that and for "easy refresh" we have the keyframe mode, so I rather keep the "advanced" mode to be more performance driven than easy driven

So I would disagree: If you use the reconciler and queue nothing for refresh with follow-on reads or a ref, then you’ve clearly changed the app state and a UI refresh should occur. In the absence of any way to choose what to refresh, a root render should happen.

99% of mutations will be against components or have follow-on reads. Optimization is opt-in by specifying idents (which you want anyhow).

not nescessarily, you could be swaping something that's not currently visible, that would not need any UI refresh, in this case the root render will be a waste

but no props will change on the query result, so nothing will actually happen at the react layer

still overhead, I wonder how much, I think it's worth measuring

ah, it would stop at the root? or it will call everything?

it's like force root render (which will force everything down to refresh) or it would do a normal root render which can stop at the root element?

So: 1. Your query+refresh should be tuned (e.g. via unions) to run in 10-30ms. In practice this is normally easy to achieve. 2. shouldCompontentUpdate stops tree traversal on no data change. A “root” render would short-circuit the entire React system on no-visible-changes The only case you’d really want to avoid root render in this scenario is if you’re doing frequent updates (e.g. many times a second via reconciler) of non-visible data to avoid the query CPU overhead

yeah, I didn’t say “force root”

just the normal (optimized) render from root

instead of component-targeted render

yeah, in this case I think it's ok, I was with the impression it would be a force root render

nope…not trying to circumvent optimizations…

@tony.kay i see last night you shared your current library recommends when building a new business software project, so you don't use specter anymore? or is that just not a critical part of your stack?

oh, I like specter…I think it is a great library, too…just haven’t edned up using it as much in practice

partly that is my lack of time to learn it btter when there are solutions that “work” that I alraedy know 🙂

Thanks for reminding me of it…I keep meaning to get more practice with it, because I do, in fact, think it is a super-nice library for general-purpose work

I really like the specter ideas too, but I find myself ending up just using the clojure basic things, they solve 90%+ of the cases, so I end up not using specter

(I also don't like that he decided to use uppercase for a lot of things there, looks ugly...)

In practical terms that’s how I’ve been as well; however, whenever I look at the library I think “I really need to learn this…it would make so many things less verbose”. Uppercase is less desirable, but where that is slightly ugly, the sheer concision is a big boon. I’m adding it back to my list of things I should really spend a day learning well

the other issue that I worry about is that if you write a bunch of stuff with it, it might make contributors on OSS harder to find because they don’t “get” your code…but I think that is wrong-headed

ppl are willing to learn arbitrary libraries as long as they’re good

I think the uppercase is actually a good decision, since it allows you to refer all without stomping on a bunch of accidental collisions.

specter can be very useful when dealing with tasks like garbage collection

maybe, but I dislike the :refer :all in general, I see it as a bad practice (with a few exceptions, like for testing primitives I found it ok)

i like :refer :all in some cases, limited to namespaces that have a very specific purpose, like testing files

i used specter for dealing with the salesforce API, i first wrote a few components in vanilla clojure then converted them to specter, specter was clearly better suited for that

and you can always prefix

i've been writing business apps for almost a decade but i've never used a rules engine 😅

should i be ashamed?

(as I actually agree with you @wilkerlucio, I never use refer all 😜 )

@currentoor nope…mostly haven’t either

does using something clara really help in this domain?

and rules engines in general

I find most rules engines way too heavy, but I also love some of the benefits

Declarative logic is just handy, especially if it is a complex set of intertwined rules

i see

and sicne the rules can look more like the problem domain, it is an easier translation from stakeholder to code

I just wonder if anybody is using core.logic these days 😄

Clara Rules is something I would love to experiment some time, seems interesting, but I dont have the feel on what they look like in real case scenarios

yeah same here, i'm just worried about adding it to a core part of my stack then regretting it

state machines are yet another one that are super handy in certain circumstances

so i decided to only use the CSS part of semantic ui and removed all the js factories

everything was straightforward except the modals, i wanted to get a second opinion on that

(defsc Modal [this {:keys [show?]} {:keys [header content actions]}]
  {:query         [:show?]
   :ident         (fn [] [:modal :singleton])
   :initial-state {:show? false}}
  (if show?
    (div :.ui.page.modals.dimmer.transition.visible.active
      {:ref (fn [el] (if-let [s (and el (aget el "style"))]
                       (.setProperty s "display" "flex" "important")))}
      (div :.ui.modal.transition.visible.active
        (when header (div :.header header))
        (when content (div :.content content))
        (when actions
          (div :.actions
            actions))))
    (div {})))

(def modal-factory (prim/factory Modal))
(def ui-modal (fn [props ui-opts]
                (modal-factory (prim/computed props ui-opts))))

(m/defmutation set-modal-state [{:keys [show-val]}]
  (action [{:keys [state]}]
    (swap! state assoc-in [:modal :singleton :show?] show-val)))

(defn show-modal! [comp]
  (.add js/document.body.classList "dimmable")
  (.add js/document.body.classList "dimmed")
  (prim/transact! comp `[(set-modal-state {:show-val true})]))

(defn hide-modal! [comp]
  (.remove js/document.body.classList "dimmable")
  (.remove js/document.body.classList "dimmed")
  (prim/transact! comp `[(set-modal-state {:show-val false})]))


(defsc CompUsingModal [this {:keys [modal]}]
  {:ident         (fn [] [:packages-table :singleton])
   :initial-state {:modal (prim/get-initial-state Modal {})}
   :query         [{:modal (prim/get-query Modal)}]}
  (div
    (dom/button {:onClick #(show-modal! this)}
      "show modal")

    (ui-modal
     modal
     {:header  "foo"
      :content "bar"
      :actions (div :.ui.button {:onClick #(hide-modal! this)}
                 "close")})))

semantic ui requires !important but react inline styles don't support it, so i have to use a :ref

semantic ui does modals by appending modal elements to the bottom of the body

but i'm able to get it to work "inline"

is that an ok thing to do?

another approach i suppose is to render the modal component at the bottom of my root and use app state to coordinate what goes inside there, seems like that's how semantic ui does it under the hood, but then i loose contextual reasoning

is there a way to tell a mutation to do something with new ids (aka resolved values of tempids from server response)? Listening to all transactions seems overkill. I want to set html5 route to a new url containing the new id after user hits the Save button

Is anyone planning on submitting anything related to Fulcro/Pathom for Clojure/Conj this year?