3.0.0-alpha-2 is on clojars. This version works with the Inspect Chrome extension (see the README), and the README has been updated to cover the basics of what porting looks like. There are various known (and I’m sure unknown) issues, but it is ready for serious (non-production) play.

Incubator won’t work with it, but the significant bits (state machines and dynamic router) have been ported and included in the new Fulcro 3.

NOTE: My intention is to not supply much for the server side any more. pathom is the “right solution” for most server-side needs. If you want the old stuff (defmutation, defquery-root, etc.), you can copy it from F2 into your source base…it would work unchanged.

The todomvc example on the repo is possibly a decent place to glance at an example that works: https://github.com/fulcrologic/fulcro3/tree/develop/src/todomvc/fulcro_todomvc main.cljs, ui.cljs, and server.clj…the other files are experiments

Is there a way to make a recursive query over two components? I have a graph with these edges. A -> {A, B}; B -> {A}

@mroerni not directly like that, since the queries are declare on components, and the static resolution would cause infinite loops. You can work around this a little bit by using an alt versions of A/B down to whatever depth you need.

e.g. A', A''

when I’ve run into this, thinking about the domain often reveals an alternative that can fit into the recursion support Fulcro can do

Remember you’re talking “UI Query” here…nothing is infinite in that space, so turning recursion into an unrolled loop is a tractable, if unsightly, approach

For the UI I am using alternative versions, yes. I just thought about making components just for the sake of (de-)normalizing, when needed. Although I will get into the situation that I need all of the graph, I suppose I'm probably better off with the normalized form then anyway. I then have to worry about normalizing the data in the backend and putting them into a special field because I can not query for them with EQL from the backend.

Q: for (noob or otherwise) questions about Fulcro, where is the most suitable place to ask for help? Here, stack overflow, github issues?

@thomasmoerman here

which is kind of too bad since searching history isn’t easy

yes here…never github issues…thanks for asking 🙂

Roger that, thanks. I'm stuck with getting *colocated css* to work in my project (shadow, fulcro 2.8.11), here's a small snippet:

(ns project.ui.root
  (:require
   [fulcro.client.localized-dom :as dom :refer [div ul li p h3 span a button]]
   [fulcro-css.css-injection :as inj]
   ...more deps...))

(defsc Root2 [this {:ui/keys [msg]}]
  {:query         [:ui/msg]
   :initial-state (fn [params] {:ui/msg "hello world"})
   :css           [[:.funky {:color :red}]]}
  (dom/div :.funky msg))

(inj/upsert-css "my-css" Root2)

[352.180s] [fulcro.client.primitives] Query ID received no class (if you see this warning, it probably means metadata was lost on your query) #error {:message "", :data {}} 
[352.185s] [fulcro-css.css-injection] Auto-include was used for CSS, but the component had no query! No CSS Found. 

(disclaimer: I'm far from a css expert, so if the problem resides there I apologise)

@thomasmoerman (defsc Root2 [this props comp {:keys [funky]}] ....

then (dom/div {:classes [funky]}

i don't think you need that upsert thing

the :css part looks ok to me

I think both your and my approach are valid, as both produce following:

<div id="app" class="app-root">
    <div class="metex_ui_root_Root2__funky">hello world</div>
</div>

somewhere up the dom tree, not in the head section

@thomasmoerman hm…your code looks ok to me…but those errors do not

you’re not getting injection because auto-include uses the query to walk components, and it found no query and aborted…but not sure why that would be

what does (prim/get-query Root2) return to you in a REPL?

Also, not necessarily good to try injection at the file scope…better to use the style injector in the body of Root2 itself, or put the injection in your start

otherwise it might try to run before things are reasonably set up (though not sure why that would matter in this case off the top of my head)

OH

you’re passing the wrong args to upsert

it takes a MAP not a component

{:component Root2}

I should put an assert on that argument..easy mistake to make

yep! that fixes the upsert part! I got it from section 4.9.1 in the book (http://book.fulcrologic.com/#_basics), the older approach probably didn't use a map as argument i guess? an assert would definitely be useful there. The style element appears now at the bottom of the document, so i need to tinker a bit more to call the upsert in an appropriate place instead of bottom of the file. Thanks for helping out!

ooops…yeah, needs updated

docs fixed. thanks for letting me know

no problem!

I was wondering if it is worth it ( easy enough ) to test fulcro server mutations ( defmutation functions ) and pathom resolvers ( to make sure the return the right data ). Seem like fools errand or great idea?

I test just the parser (parser state query) => result

hmm .. can you give me example @souenzzo.. me curious what that looks like

exact like this 😅

where do get handle to parser ? is that the parser that I defined as

(defstate parser
  :start    blah blah