There are only two kinds of people in this world: 1. Those that don't know CSS 2. Those that think they do, except they don't. Not really.
Further Notes:
1. to reduce noise, you should make check-spec-interceptor
a global interceptor (a new feature)
2. It appears as if your calls to interfaces/invoke
and io/display-notification
are side effecting and would ideally be modeled as effects (ie. use reg-fx
)
3. In https://github.com/realgenekim/re-frame-event-graph/blob/master/resources/trello-events.cljs#L355-L363 it appears you are using events instead of function calls. IMO, you should have a function call reset-card
not an event. This function would be given db
arg and return a modified db
. Then you simply call that function in that event handler ... don't dispatch an event to do it. Events are meant to model user intent, not model the low level machinery - good old functions calls do that just fine.
4. I'm sure I don't need to tell you that you should clean up all those side effecting dispatch
calls in reg-event-db
handlers ... but I will any way, just in case :-)
BTW, I know I haven't got the the event knot yet. More later when I get a bit more time.
This is mind-expanding. š¤Æš¤Æ Thank you!
This is beautifulā¦
(>defn reset-card
[db] [map? => map?]
(assoc db :current-card-comments []
:current-card-attachments []
:new-comment-text ""))
(>defn set-list
[db list-id] [map? string? => map?]
(assoc db :selected-list list-id))
(comment
(-> {:a 1}
reset-card
(set-list "abc")))
This is even more beautiful āĀ as imperative stuff moves to more declarativeā¦
(re-frame/reg-event-fx
::select-board
[check-spec-interceptor]
(fn [{:keys [db]} [_ board-id]] ; currstate, and new state
(println "::select-board: " board-id)
{:dispatch-n [[::save-and-clear-searchbox]
; if moving card, make sure focus is in search box
(when (= (:left-pane-view db) :leftpane-moving-board)
(io/focus-searchbox ::focus-searchbox))
[::load-board-lists board-id]
[::select-board-next-leftpane-state]]
:db (dbh/select-board db board-id)}))
Wow, this is niceā¦. made my first reg-fx
.
(re-frame/reg-fx
:load-lists
(fn [board-id]
(check-and-throw string? board-id)
(println ":load-list: fired off go-routine: board " board-id)
(interfaces/invoke interfaces/trello {:command :load-lists
:board-id board-id
:callback ::callback-load-board-lists})))
https://github.com/Day8/re-frame/issues/218#issuecomment-252470445 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
r/with-let
is the bees knees
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 http://day8.github.io/re-frame/subscriptions/ 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.
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
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).
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.
I thought I'd might be missing something
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?
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. š
You might be right š
might be = are most likely I'm going to sleep on it. Thanks.
Good night and good luck!