Fork me on GitHub

Or perhaps name the function dispatch-<event-name>:

(defmacro def-event-fx
  [name docstring attr-map params body]
     (defn ~name
     (defn dispatch-~name
       (rf/dispatch event-vec#))
     (rf/reg-event-fx ~name ~name)))

(def-event-fx my-event
  [cofx event-vec]
  ;; handle my event

;; dispatch the event
(dispatch-my-event [event args])


It'd probably be better to be explicit about the dispatch rather than implicitly creating a dispatch function.


Going to try out this impl in our CLJS app to see how things shake out:

   (defmacro def-rf*
     [ctor name docstring attr-map params body]
     `(let [v# (defn ~name ~docstring ~params ~body)]
        (~ctor ~(symbol (str *ns*) (str name)) ~attr-map ~name)

   (defmacro def-event-fx
     ([name attr-map params body] `(def-event-fx ~name "" ~attr-map ~params ~body))
     ([name docstring attr-map params body]
      `(def-rf* reg-event-fx ~name ~docstring ~attr-map ~params ~body))))


@kenny ^^^ I plan to finish that document off a bit more and then open up a repo issue for discussion. Might be a week away.


One branch of my db tree is parameters that I want to allow my users to edit via a component. (all strings or ints) Does any library offer an easy way of doing this? For my current user-base, I don't need to make it pretty; just usable. So, I don't care exactly how it looks and I'm open to arranging the data and meta-data in whatever format works. I'd just rather use something ready to go, rather than wasting time coding something that will probably be thrown away soon.


Have you folks deleted the rant against redux/relay? I need to read that every now and then (and hand it to JS .....colleagues 😃)


Cannot find it anymore on GitHub


Oh maybe it was all just a dream


Haven't seen it myself, but I could probably guess what it was about having been forced to use redux at work.... 😞 Only made it worse that I've used re-frame before that.


Almost snapped the first time I saw something like this in production:

// MyComponent/actions.js
const MY_COMPONENT_MY_ACTION = "MyComponent.myAction";

// MyComponent/actionCreators.js
function doMyAction(foo) {
  return {
    type: actions.MY_COMPONENT_MY_ACTION,

// MyComponent/reducer.js
const reducers = {
  [actions.MY_COMPONENT_MY_ACTION]: (state, action) => {
    // do stuff here

// MyComponent/index.js
<button onClick={this.props.doMyAction(123)}/>

function mapDispatchToProps(dispatch) {
  return {
    doMyAction: (foo) => dispatch(doMyAction(foo))
... and the app was pretty big too.


Are there recommendations for building reusable components that need to trigger effects? For example, if I’m going to create a company-table component that needs to query for companies when it’s mounted, and may need to re-query (say, if you go to the next page). Re-frame patterns seem straightforward when there’s only one, but if this gets componentized, perhaps used multiple times on a single page, it becomes less clear how the events and effects should work


I could imagine: 1) the outer component that mounts the company-table will query for them, and pass the subscription as a parameter. The outer component passes event-handlers for changes as parameters, which dispatch events to trigger reloads 2) Have event handlers/subscriptions within the component, specifically for the table


Hi, I'm looking for examples of nested routing where functions representing the more "general" routes are hit before more specific routes. For example, if there were two routes for /admin/users and /admin/posts, the routing lib would detect that I'm attempting to enter the /admin route regardless of the sub-route, and check that my authenticated account has access. This may already be supported (currently trying to get familiar with bidi), but I haven't seen an example of it yet. Any help/pointers/links would be greatly appreciated. (Is stately my best bet for this?)


@hoopes Can you add a function to the route-changed handler that executes your special admin logic when the path .startsWith "/admin"?


yeah, i think i could. i'm trying to transition from angular 1 (!), which actually had a pretty sweet router, which you could lay out with a big JS object - i was hoping to define my routes with a big cljs map (like bidi does), but have the route matching done for me throughout, with the nested routes working their way down from the "top", know what i mean? (maybe bidi already does this, and i just haven't come across it yet - i'm pretty new here in cljs land). if functions on the route change handler are the best way to do it, that's cool, i was just looking around for best practices


I get what you're after. I don't use bidi so I'm not sure there. Though, this sounds like logic that you want to have in the backend, not the frontend.


maybe, but once i serve my giant main.js file, i'm pretty much only frontend, right? instead of the /admin check, imagine something not security related 🙂


Even if you try to restrict parts of your app in the frontend, a user can still access it because all the code is in main.js.


i.e. A user may be able to visit /admin/users in your app but no information will be shown to them because the backend will not load the required data.


oh sure - creds checking on the backend too, i was just using /admin as an example of a "high-level" point to do something that applies to the whole section you're looking at in the frontend app. I'm trying to run functions based on every URL match, instead of just the most specific one.


@richiardiandrea never been anything ranting about redux in the official docs


Uhm so maybe it really was a dream!


Gotcha. All of the routes in our app have a parent page defined like this:

(derive :page/profile-password :page/profile)
You could probably do something similar for your admin page...
(derive :page/admin :page/admin-users)
(derive :page/admin :page/admin-posts)


Then you can check if the page is an admin page via isa?.


yeah! something like that... i dunno, i'm gonna keep banging around with bidi - thanks so much for your help!


@mikethompson thanks. I hadn’t seen that. Both of my approaches follow that pattern. That is, component-will-mount just dispatches an event


The complexity to me is the globalness of the event when trying to make something reusable. “localized” events have to be explicitly so.


i.e., you’d have to have an identifier as part of the event tuple for each instance


@brycecovert yeah I understand the "locality" arguments but for me its a bad trade. Gotta go, sorry.


bad trade? thanks for the pointers!