Clearing pending remote requests should clear all queued requests, but there may be a problem in timing

You are aware that you can run ptransact within a mutaton?

oh right so i could conditionally call the last block of muations inside a mutation

yeah

fallbacks weren’t the best idea…they’re like a mallet when you need a screwdriver

also while you’re here, is this a bad pattern?

(defmutation handle-failed-payment [params]
  (action [{:keys [state reconciler]}]
    (swap! state assoc-in [:ucv.ui.root.mobile-pos/overlay :singleton]
           {:negative-msg "Payment failed. Please try again."})
    (js/setTimeout #(prim/transact! reconciler `[(remove-overlay)])
                   3000))
  (refresh [env] [:root/overlay]))

if i want an overlay to show for 3 seconds then go away

it’s technically fine

is there a better way?

given that this is way down in nested logic…not that I can think of

I discourage transact within mutations for two reasons: 1. People coming from js might make a big mess if they’re in the habit of composing there. If you’re used to nested nested nested callbacks it just seems fine…so I’m trying to encourage better patterns. 2. If you do a transact! within a swap!, things get screwy…because then you’re going to run swaps in swaps and things will break.

but technically it is fine to call transact! from within a mutation (not a swap), though I do recommend you defer the nested one (as you have) to ensure that tools and such see a linear sequence instead of nesting

e.g. (js/setTimeout #(prim/transact! ...) 0) is fine

ah got it

thanks a lot Tony!

sure

Hi, I am trying to integrate (at least render) [cljsjs/react-tagsinput “3.17.0-0”] from http://cljsjs.github.io/ but w/o any luck I added dependency to the project.clj and have a proper require how I actually render it?

(defn country-input []
  (js/ReactTagsInput.renderInput #js {:value []}))

do I need to create a factory first?

(def ui-country-inpyt (prim/factory js/ReactTagsInput {}))

please help

If you can, using shadow-cljs for the build might help since you can just use the package from npm (no cljsjs) need.

thanks, but I think shadow-cljs is not an option

Haven't tried using js components yet 😞 There is reakit implemented in fulcro incubator https://github.com/fulcrologic/fulcro-incubator/blob/develop/src/fulcro/incubator/ui/reakit.cljs

> dom/create-element rk/Button #js {:onClick #(js/alert “Pow!“)} “Click me”)))

i just found the same

Will try this, thanks!

and the https://github.com/fulcrologic/semantic-ui-wrapper + http://book.fulcrologic.com/#_using_javascript_react_components

thanks!

you're welcome 🙂

seems working this way

(defn country-input []
  (dom/create-element js/ReactTagsInput (clj->js {:value ["GBR"] :onChange #(js/console.log "change")})))

thanks for help

@kirill.salykin you can also use dom/macro-create-element which will give you support for Fulcro-dom-like features. I need to add that to the book, but Wilker’s blog article here https://medium.com/@wilkerlucio/using-any-react-ui-kit-with-fulcro-82cce271b9cc

Using defrouter I would like to add my form data into the precise location for a given router component so that the router rerenders based on that data changing. I’m trying to avoid a root query like {[root/form-name '_] ... } and instead add the form ident in the correct place.

Is this possible? I’m trying to add it into the :page-name table, but it won’t rerender

@pvillegas12 follow-on read?

I don’t understand your question, because there isn’t enough context…so that is my only guess

I have this

(defrouter RootRouter :root-router
  (fn [this props] [(:page props) :root-router])
  :integrations-index IntegrationsIndex
  :integration-details IntegrationDetailsHome)

(defsc IntegrationsIndex [this {:keys [page model/by-name form/integration]}]
  {:query [:page
           {:form/integration (prim/get-query IntegrationForm)}
           {:model/by-name (prim/get-query IntegrationList)}]

I tried concocting the path [:integrations-index :form/integration] to rerender the IntegrationsIndex correctly

so, I see a few fishy things. Your ident function on your router always returns :root-router as the second element of the ident…but you’re implying that it should be able to be :form/integration

so, that will mess up normalization on initial state

Then, you’re doing a join on :form/integration in the query of index

which would have nothing to do with the ident…but it sounds like maybe you think it should

IntegrationsIndex does not have an ident function

does it need one?

it does if it is a child of a router

and it must return the same thing that the router’s ident function returns for it

If you were to use that component with merge-component or a load it would not know how to normalize the data

it is optional if you only ever use it as a pre-initialized thing at startup as a child of that one router

but to be safe, I recommend one

AND, it’s ident is the base of the path where you’ll need to put the actual form ident

ah 🙂

Right now I do set initial state to have the right page (which is the only thing I need for routing), but I’ve been hitting this part where I want the router to pass down further information to each child

{:integrations-index {:root-router {props of integration index}}

the router isn’t about passing info

The router shows a page and makes a union query (for efficiency)

the ident you plug into a router is the only input

What is confusing me is what the relative path of the query for the IntegrationsIndex is

You want different instances of that form to show up?

but the ident should solve that

exactly

You’re already giving it one

I only want one form to show up, but I did not want to make it a root query

but you didn’t declare it on that component, just the router

(defsc IntegrationsIndex
  {:ident (fn [] [:integrations-index :root-router])
   ...

I’m trying to see what the natural way to model this is, it works if within the query I do {[root/integration '_] (prim/get-query ... )}

and the path to place the form ident at is [:integrations-index :root-router :form/integration]

Does it make sense for me to be avoiding putting the form data at the root?

absolutely

Your form component should have an ident function, right?

it does

(defsc IntegrationForm [this {:keys [db/id]}]
  {:query [:db/id :integration/name fs/form-config-join]
   :form-fields #{:integration/name}
   :ident [:integration/by-id :db/id]}
  (dom/div "IntegrationForm"))

(assoc-in state-map [:integrations-index :root-router :form/integration] ident-of-form) in a mutation

that’s all

well, unless you just made up the form and are using form state…then you have a few steps

the above worked!

(defmutation new-form [params]
  (action [{:keys [state]}]
    (swap! state (fn [s]
                         (-> s
                             (fs/add-form-config* ...)
                             ...))))

yup, I have that part

Yeah, you just need to make the right edges on the graph

you named the edge in the query, but you didn’t make it in the db

What is the recommendation on the ident part between the router + children?

talking about (fn [this props] [(:page props) :root-router])

this one is static

it has to be consistent

but can be as complicated as it needs to be

If the router only ever routes to singletons, then what you have is fine

But the router can also route to different pages on a given table (e.g. the second element of the ident can vary).

The ident determines what renders…no more complicated than that

of course, it has to resolve to a real thing in your db

Alright, got it, thanks @tony.kay 👍

welcome

Does the defrouter take care of properly setting up the ident for IntegrationsIndex?

You should probably watch this video @pvillegas12: https://www.youtube.com/watch?v=HJBI24yAdBQ&index=12&list=PLVi9lDx-4C_Rwb8LUwW4AdjAu-39PHgEE&t=16s In it, I show you how to do UI routing manually. The result is pretty much exactly what defrouter builds. The “short answer” to your question is this: 1. defrouter makes a component whose initial state is the first route listed. It uses the ident function you’ve supplied to look at the props in that to determine what initial ident it is “routing” to. 2. Initial app state understands unions, and will put the initial state of the “other routing legs” into state, it just won’t have anywhere to write idents. defrouter actually generates two things: A component that “holds” the ident pointing to the “current” screen, and a Union Query component (which has no state…it is an interstitial artifact). When you “set a route”, all you’re doing is setting the ident inside of that one real component (the component that holds the current screen ident). Union query of the union element “selects” the subquery based on this ident.

Thus, some of the requirements are: 1. Every component MUST have an ident (because they have to be merged into state at their proper normalized place, e.g. all but the primary leg are merged via a separate automatic step). 2. The router itself needs an ident function that will produce the correct ident when it is given props from any of the components that stand for the “routes”. This has to do with initial state normalization.