Fork me on GitHub
lwhorton16:08:41 i’m thinking about this introduction of the syntax sugar derefs, and i’m curious how to do this:


(def my-component [x]
 (let [my-local-val (r/atom) 
       some-dynamic @(subscribe [:foo x])] 


if i want local component state, but i’m using the syntax sugar form-1, that ratom is going to get blown away every rerender, no? do i just have to raise the ratom into a let, and return a renderer fn (form 2)?

(fn [x] (let [some-dynamic @(subscribe [:foo x])


yeah if you’re use a local ratom, then you should use a form-2 (or with-let). to avoid those corner cases as explained in the issue, you can subscribe in the body of the returned function

👍 1

r/with-let is the bees knees

👋 2
Jacob Emcken18:08:49

I want to trigger a CSV parse (which is async by nature using the lib node "papaparser"). So I would like to "subscribe" to both the (CSV) file and the delimiter to trigger re-calculation of a CSV preview. I'm not sure what would be a good approach. I've been looking a and if the CSV parsing had been synchronous, I would have put the re-calculation in the Layer 3... but now I'm at a loss.

Shako Farhad19:08:24

If the triggering of the delimeter is done by the user you can use a :on-click or :on-change to trigger a dispatch event that updates the CSV data. Sorry if that is not helpful. I am not quite sure how your app works. :x

Jacob Emcken20:08:46

The on-change is supposed to change the state of the delimiter in app-db. But I also want it to trigger a re-calculation of the CSV preview. The thing is I have several options for the CSV preview parser I change individually, I want the all to trigger a re-calculation of the CSV preview on top also updating the state of app-db. I "solved" this by registering my own effect but I'm repeating myself triggering this effect with the help of reg-event-fx all the places where I either change the CSV parsing options or the CSV file itself (file chooser).

Jacob Emcken20:08:08

I was just looking at the signal graph where it could just "listen" on changes in app-db I felt it would have been easier (with less repetition) to "subscribe" to the changes in app-db for re-calculate the CSV preview just like it is possible for views.

Jacob Emcken20:08:16

I thought I'd might be missing something

Shako Farhad20:08:55

Let me try to understand. You select a CSV, and then you set some parsing options. Then you have a preview window that shows the result of the parse with the given CSV and the parsing options, right?

Shako Farhad20:08:05

The preview window is the view. It subscribes to the CSV data and draws out the preview. The CSV file and the CSV parsing options are both one event. Everytime one or the other changes, you dispatch the event. The event is to rerun the parser with new inputs, and register the changes to the app-db. Then when the changes have been registered, the subscriptions are updated and the preview is updated. I think you have done it the right way from the start. 😛

Jacob Emcken20:08:25

You might be right 🙂

Jacob Emcken20:08:41

might be = are most likely I'm going to sleep on it. Thanks.

Shako Farhad20:08:12

Good night and good luck!