Clojurians Log v2

I think I'm a bit confused... subscriptions can take an argument. I feel like you should be able to do

(rf/reg-sub
 ::get-tag
 (fn [db tag]
   (get db tag)))

(defn my-conponent []
  (let [data @(rf/subscribe [::get-tag :my-tag])]))

That way you only have one sub, and even if tags are added dynamically, you can easily subscribe to new ones.

Yeah, It is set as Json in the json. When I set the :content-type to multipart/form-data it wont work.

when I try the same with Insomnia. Set the content type to multipart-form-data it wont work. ( when I test through the browser just running the swagger UI it does work)

ok, got it working in insomnia now

-----------------------------175945971223698693323893870064
Content-Disposition: form-data; name="file"; filename="test.txt"
Content-Type: text/plain

ajsdnasd 
-----------------------------175945971223698693323893870064--

getting a 500 error file upload exception

getting closer:P

What I was looking for, but not what I needed

I thought that that you was using subscribe in the main body of reg-sub, which is not the way it was intended to be. As for Layer 3 subsription performance I think it depends. According to @mikethompson

And, to answer you question, layer 3 are not about less rendering (in general).  The propagation pruning layer is Layer 2.  Layer 3 is about performing the the expensive computation.

I am trying to do a fade-in animation with re-frame. I already have a fade-in-1s css class that works. The problem is that I have a form like this:

[:div.fade-in-1s
  [:h "Step description"]
  [:p "Step contents"]
  ...]

Hi @setzer22, may be you can set a new key at each refresh

^{:key new-refresh-key-here}[:div.fade-in-1s ...

that works, thanks! 👍

Also remember that you can use libraries like Framer Motion here is an example of use https://github.com/reagent-project/reagent/tree/ce1dbe1be4534ca556fb05c4fede3fd6ac41b7cf/examples/framer-motion

So if you can't use subscribe in the main body of reg-sub, how can you achieve what I described in 2?

But what if I need to subscribe to a subscription, whose parameter depends on some other value I obtain from another subscription.

Say, in my case, a link has two endpoints and only need to depend on their positions and not on position of all units.

I could in principle obtain the ids of endpoints in my view and send them to another subscription, but that seems incorrect to me since subscription logic will be leaking into my views.

Using @(rf/subscribe [:node/pos endpoint-id]) works within the main body of my subscription. So my question is what is the downside of using it like this?

No downsides. As to your question about feeding sub value into another sub, you can just use reg-sub-raw for that.

Ah, sorry, I missed the fact that you deref inside the body of a subscription and not a view. Here, I'm not sure.

So basically the correct way would be to use reg-sub-raw. I will take a look at it how it works precisely.

is there a preferred way to donate to re-frame? or perhaps just to an individual?

Not yet. I haven't ever set something up

Perhaps I should setup a Github sponsors ability

In the end I actually wrapped up the defining of the two "chained" handlers into a separate function:

(rf/reg-fx
  :get-token
  (fn [{:keys [dispatch args]}]
    (-> (.getToken js/window)
        (.then #(let [dispatch-args (vec (concat [dispatch %] args))]
                  (rf/dispatch dispatch-args))))))

(defn reg-token-event-fx
  ([id interceptors handler]
   (let [with-token-id (keyword (str (name id) "-with-token"))]
     (rf/reg-event-fx with-token-id handler)
     (rf/reg-event-fx
       id
       interceptors
       (fn [_ [_ & args]]
         (cond-> {:get-token {:dispatch with-token-id}}
                 (not (empty? args)) (assoc-in [:get-token :args] args))))))
  ([id handler]
   (reg-token-event-fx id nil handler)))

(reg-token-event-fx
  :search
  [app-state-spec-interceptor]
  (fn [{{:keys [search-text]} :db} [_ token]]
    {:http-xhrio {:uri     (str "/search?q=" search-text)
                  :headers {"Authorization" (str "Bearer " token)}
                  ...}}))

It works great!

So thanks @me1987!

It worked. It's not fancy, but it's a workaround.

I feel like I must be blind. I'm looking for the explanations of form-1 and form-2 components in the new re-frame docs and can't find it anywhere. are form-2 components not recommended anymore?

i sent you a pm this morning asking about channels to donate to you individually. seems like you have notifications off though. just wanting to see if you had any way to get you some money from our development team

you can use subscriptions directly in form-1 components, I normally just deref directly @(rf/subscribe [...]) within let.

I was looking for https://github.com/reagent-project/reagent/blob/master/doc/CreatingReagentComponents.md#form-2--a-function-returning-a-function, which is under the reagent documentation.

I'm going through the re-frame todo mvc example, and was looking for the docs on form-2 components to under stand the todo-input https://github.com/day8/re-frame/blob/master/examples/todomvc/src/todomvc/views.cljs#L7

are form-2 components idiomatic in re-frame? is there a better alternative?

they use form-2 components there because they want to use ratoms directly for inputs, so the state is not changed while typing the text into it

I haven't ever used anything like that (we are dispatching all changes), so not sure about idiomatic way in Re-frame

I'm pretty new to re-frame and I like the idea of sticking to form-1 components. Are form 2&3 components common for re-frame projects?

I think the change in subscriptions made form-2 unnecessary in most cases. In our code, we have almost all form-1 components, and a few form-3 components where we need to use React events like component-did-mount or component-did-update. If you are starting with Re-frame, just use form-1 for everything.

Beforehand, subscriptions has to be used in form-2 components because rf/subscribe couldn't be used for every rerendering which would cause memory leaks. But it was changed that it is cached now.

awesome!

https://github.com/Day8/re-frame/issues/218 for history

form-2 is still very relevant when creating local states

not everything belongs in the app db 😄

what is something you would put into local state? like values of an input, as it changes?

collapsed/expanded state is something we have had there

my rule of thumb is: if I deleted the UI, would this state still be relevant? if so, app-db. if not, local state

> Using @(rf/subscribe [:node/pos endpoint-id]) works within the main body of my subscription. So my question is what is the downside of using it like this? There's a possibility of memory leak because derefs are tracked and it is possible that subscription won't be disposed.

don't you get then into problems when something is local at first, but then you need it somewhere else? I found that impact of user interactions often influences very different places in the state of the app.

sometimes but not all the time

you can either lift it up to a parent and pass it as props (an easy, purely mechanical change with the ratom API) or - maybe it's relevant outside of the UI

My experience is form 2 was required whenever I wanted animation with JS comps. (Material UI).

yes. UI state needs to have very low contention. you want the minimal amount of mutations & subscribers in order to remain fast

app-db is just a free for all. as your app grows, every top-level subscription has to be run on every change. it's terrible for UI state

but, there are benefits to having a single source of truth for your application domain

I'm very influenced by this article: https://medium.com/@mweststrate/ui-as-an-afterthought-26e5d2bb24d6

hmm, speed is a benefit, I like having all of the state within one atom which makes the app little bit more clear (we have now about 25k lines). Not sure how this goes when it grows.

for us, our app is about twice as big and the app-db is an unmanageable mess

you can't print it w/o performance problems lol

the dev experience and tooling problem you're talking about is legit but there are ways to solve it that actually don't depend on keeping everything in one atom

you could keep things in multiple atoms and have lil bit of code that allows you to explore them all at once

hmm, how about using inspect in shadow-cljs instead of printing?

makes sense, currently it doesn't feel to me like a mess yet and if it becomes a mess later I will have to rethink the approach

Ok, so I read this http://day8.github.io/re-frame/flow-mechanics/ and using reg-sub-raw instead makes sense for my case. Btw. I am missing a real example which would need reg-sub-raw in the text. The example here is better: https://github.com/day8/re-frame/wiki/Dynamic-Subscriptions