Fork me on GitHub

Does a subscription triggers a re-render of the component in which it is derefed whenever it is recomputed regardless of whether or not its output has changed? from the doc on subscriptions and if that is the reset! they are talking about here


Hey dear re-framers! I'd need some advice on effect order. I have a use case where defining effect order would be needed and I could not find a good solution to make it unnecessary (see: I'm working with blessed-react on a terminal app, using reagent and re-frame. In blessed you have on-screen components, and I'm implementing a method to switch to a view (= screen content), then move the input focus to a specific component, defined runtime. The view switching is done through app-db, re-frame and reagent style and I'm changing the app-db through an event to achieve this. As part of the same "show-and-focus" event-fx, I need to also call a method on the component through a reagent-style ref for it to get focused. Problem is, that before the re-rendering happens through the app-db change, that component is not available, so I can not call the method before the update completes. I'm pretty sure this pattern also comes up on web a lot (change app-db -> new thingy shows up in DOM -> call something on the thingy [in one event]). Is there a clear pattern to use here?


Is calling the focus function in the component's didmount not suitable?


@regen, thanks, possibly that's what I'll do for now, but I wanted to find a cleaner approach without digging into react lifecycle stuff.


I do have a "focus-to" kind of event in re-frame as there are other use cases for this, so I probably just dispatch it on the lifecycle method - still looks a bit impure 😉


the "view-switch" usecase I've described above would also mean that I can declaratively describe a "default" focus target upon switching, so if there are multiple instances of the component in a view it's a lot cleaner - the component doesn't need to know if or whether it will be focused, it's the view definition that does that instead... that's where it should belong


Hi all, I'have a compojure-api+mount which I'd like to "upgrade" to support SPA app through re-frame


I'm having a hard time integrating my existing handler with shadow-cljs


My handler is generated, ie (defn make-handler [app-cfg])..., the way this currently works is because I have a main fn that takes care of booting up mount. for repl, I have an init-fn that's a bit hacky


(declare app)

(defn init []
  (mount/start-with-args (mount/args))
  ;;dynamic def!
  (def app (indie-dashboard.handler/app config)))


and then I can use app as handler


How can I achieve the same with the re-frame lein template?


So app is actually available only on the backend, right? If so, it's kinda hard to give any answer here since you're basically asking "how do I write an SPA?".


Actually, somewhat concise and useful answer could still be given: 1. Use HTML5 history API to handle all your links within your app that lead to another page within the same app (I use kee-frame for this) 2. All relevant backend handlers should now return the same HTML, maybe with different initial data for different pages (that is, unless you use module splitting - then each HTML could load a different JS file) 3. When the current page URL changes, just fetch the new data and handle it in your browser app.


Hi, my problem is that my handler requires mount/start to be configured


and the fulcro re-frame lein template uses a (def'd) handler, I use a (defn handler [arg..])


I still don't get what the problem is. mount/start can run on the backend for both an SPA and a regular web application. Why do you think that would be a problem for SPAs?


when developing locally, the re-frame app template requires a handler for shadow-cljs


I just need to know how to wire my handler


in prod, I know my app would run as usual and serve the js files on top of the already existing api endpoints


Ah, I see. shadow-cljs web server is there just to help you in simple cases. If your app has some state, it's probably better to not use shadow-cljs web server at all. After all, you already have a fully fledged web server - why would you want to use shadow-cljs web server?


If you go with the default shadow-cljs approach, you would probably run: 1. shadow-cljs start 2. shadow-cljs watch build-id 3. whatever-command-that-starts-your-server


In my case, I have embedded shadow-cljs into my development setup, so I just have to run (3).


Thanks, I understand, my mental model was a bit off


shadow "just" spits js


Yep. Well, it also has its own server that serves changes to the browser via a WebSocket connection. But it's likely that you won't ever need to deal with it in any way - it all happens automatically.