Fork me on GitHub

@vikeri So it looks like you have created a classic diamond-shaped dependency graph. To get guaranteed one pass propagation, I think you'd have to have a static signal graph, do a topological sort of it, and then process in the right order. But that's not what Reagent does. The signal graph is dynamic and unsorted (nodes can be added and removed depending on what Components are shown and what if conditions are executed within them). So there is always the chance of duplicate computation and even "glitches"


@mikethompson Alright, so to be clear, I can't be sure that the subscriptions I have as input to another subscription are calculated from the same underlying ”version” of the app-db? Is this true for all subscriptions or just the dynamic ones? Even though it is not ideal I would not mind skipping dynamic subscriptions if that would eliminate these issues.


@mikethompson Hello, regarding this message - is it normal behavior? Is it required to include file with subs in another subs if there's dependency between them?


Wrote a macro for debugging subscriptions in 0.8.x, putting it up here for anyone else who might be interested:


How would you declare more than one :dispatch vector in a handler?


In reg-event-fx, that is.


@nidu: Exactly what I wanted, thanks 🙂


And I'm just now reading about registering effects


reg-fx, that is


Which partially answers my question


I'm probably updating my project to 0.8 tonight, anything I should keep in mind?


keep calm and react on


@curlyfry: Any custom middleware?


@curlyfry: Awesome, should be pretty easy then. We really should have a reference doc to show what needs to change, but there are really only a few things. Do you want to take advantage of the new reg-sub syntax right away or are you looking for the minimal changes required to get it to build?


@shaun-mahood Kinda want to know both! All possible cool new stuff for my hobby project and minimal changes required to build for gradually introducing 0.8 at work.


@curlyfry: Ok cool. To get it to build, I think you need to do is replace all your (register-handler :some-id (fn [db v]...) functions with reg-event-db :some-id (fn [db [_ v]... ) (function name and shape of the arguments both changed), and the register-sub functions with reg-sub-raw. I've done it to update the docs but not with a real project yet, so if you run into any issues doing that post on here and someone should be able to help.


@curlyfry: When you want to move to reg-sub, there are a couple substantial improvements beyond the syntax (one of which I didn't realize at first): - You no longer need to have a reaction in your subscription code - You no longer need to dereference you database using @db in your subscription code, you can just use db


@shaun-mahood: Great, thanks! Slightly puzzled over why there are breaking changes when the new stuff have different names, though (and the old ways of doing things are still there)


@curlyfry: That is a good question. I think there's enough of a change in the programming model (single handler type in register-handler vs. the separation of pure handlers and effectful handlers, change from middleware to interceptors, change in how subscriptions work) that it sort of helps having a breaking change to force a reevaluation of things, but it also always sucks to be forced to change things in your project. Not sure if you use at all, but the approach they take for breaking changes in that project are probably some of the better practices I've seen - nice deprecation, very clear communication, and well thought out reasons for the changes. Have you read through the new docs yet? If so, do you think the changes warrant a breaking change at all? In my case, - my existing re-frame projects are not that large and I want to do some major refactoring in them to take advantage of the new re-frame features anyway, so it doesn't really bother me.


@shaun-mahood: Yes, I read through the docs and there are indeed a lot of changes (some arguably fundamental). It just seemed like the old way of doing stuff was still there and that upgrading and then doing a gradual migration would be possible. But I definitely see why the authors would want to force a change when the new stuff is this nice 🙂


I think the change will be close to trivial for my hobby project but slightly hairier at work


(though I think to get it to build all we will need to do is rename register-handler to reg-event-db)


Changing the handlers that perform side-effects to reg-event-fx will probably be a slightly larger undertaking


@curlyfry: Don't forget the argument changes for reg-event-db though, and changing to reg-sub-raw. Almost find and replace but not quite. I bet it would be pretty easy to build a wrapper function named register-handler that did that for you, though I haven't tried it. Might be worthwhile if your work project is significant. I'd love to know how it goes for you, it would be really nice to be able to smooth the path to 0.8.0 for existing users if we can.


@shaun-mahood: Thanks for the help! Not sure when we will be able to do the switch at work, but I'll let you guys know how it goes if/when we do.


Sounds good - I'll try to remember to let you know if we write a migration doc before that.


Hello, i've been reading this and saw a mention of replayability. So i wander how non pure handlers prevent it (i mean server requests primarily here)? Isn't it enough to just switch between recorded app-db's without retriggering handler?


so I'm running my first re-frame template. Instinctively, when I pull up a project, i jack in with cider and make a clj repl. When i went to a cljs file and jacked-in with cider-jack-in-clojurescript, it says that a buffer already exists, am i sure i want to make a new buffer


is there a way to connect to a cljs repl once i already have my clj repl up?


@dpsutton: Not sure if this is up to date, but I expect it should give you a starting point at least -


There's also a Lambda Island episode on it if you want to go that route.


i'm reading as we speak. thanks for the info


for some reason it opened up two browser buffers


When i went to a core.cljs and issued C-c M-J for cider-jack-in-clojurescript


and i have no prompt showing after figwheel connects to application, but i guess i don't know if figwheel has connected


I seem to not be connecting. I want to say i remember seeing I need to open up a browser to a certain url but I may be mistaken


ok. it looks like you need to visit to let the repl connect. I didn't see this step anywhere, but the repl from lein figwheel dev mentioned a server was started there. Should definitely be more prominent in docs


@dpsutton: Yeah there's definitely a bit of a learning curve with figwheel - not a lot, but a few issues that are pretty common when you are first using it. The other thing to watch is if you are using multiple profiles (particularly for devcards) - I often run one profile, connect to the other one, and sit there staring for a minute or two before I realize what I've done wrong. Have you got everything up and running nicely now?


looks like it


just that visit localhost:3449 solved everything. I'm still a little unsure about the two repls


wasn't really expecting that


i'm gonna go try C-u C-c M-z and see what happens on clj and cljs files


which means eval buffer and make namespace in repl


You really don't need the Clojure repl until you want to integrate the two in a real app - I almost never have a clojure repl running when working on re-frame, but there are certain cases where it's really nice.


cool. I've already got my endpoint on another site so I have no need for clojure. Not sure how that would affect deployment


but this will just be all javascript


no "server" to speak of besides service its own js assets


Oh yeah, in that case you really don't need the clojure repl at all. Are you bringing in any existing CSS or JS files or is it a fresh start?


fresh start


new front end to an existing project where i exposed its guts as json


its a static hiccup site that's fine but is a great substrate to learn on


so wrap-json on some methods and now consume it


we have a race with a coworker who's gonna build something in elm vs me in clojurescript


Oh, and deployment is stupidly easy - essentially you run lein cljsbuild min and it outputs one .js file to include.


and ps, i really appreciate you talking with me while i'm learning. super helpful and thanks for sharing your time


oh that's perfect


i was hoping there was something like that


Ok, if it's an existing hiccup site you have such a big advantage in that race. You should be able to just copy over the hiccup code you want to keep, turn them into reagent components, and then call those from re-frame for your views.


i also confused the site with just a simple frontend for running the server at first. As in you connect to a browser which actually runs your code but its not your app. Thinking the application lived somewhere else


That's actually what got me into re-frame in the first place, I had a bit of an understanding of hiccup so the learning curve to get something on the screen was trivial


They were all dynamically generated. Gonna start fresh. It was just query db, and combine with a map of how to project the db results


They just make bootstrap panels with tables. So you make a map of what columns you care about, any special needs in transforming its value, column header, and if you like a td-cell-formatter


and then just (panel-with-table "header" map db-results)


makes a static-ish reporting site super easy to create


So if you're going the SASS route for stylesheets, figwheel has a SASS watcher that will hot-load your SASS the same way it does your CLJS code. You can do the same if you want to use Garden (which I love) with lein garden auto, or bare CSS (which I think is automatic with figwheel as well, but what fun is that?)


i'm new to all of this. how easy is it to add these things later if you didn't include them on the template?


I'm very scared of trying to add all of the stuff required for clojurescript to an already existing clojure project


the project files are so much larger haha


Adding extra stuff to the ClojureScript project is not hard at all, and I've found with re-frame in particular that refactoring is extremely simple. As far as adding CLJS into an existing Clojure project, I've never actually done it - but it's been done in numerous templates, so when you get to that point there are a bunch of resources to look at. I've kind of gotten used to working on them separately, and it's so easy to deploy a CLJS only site (just HTML, JS and CSS + images etc.) that it's really a non-issue as far as I'm concerned.


yeah that sounds like my use case as well


Hi, what is the proper way to put a :key on a (fn [] ...) component?


The usual ^{:key "blah"} prefix isn't working


@dpsutton I pretty much selected all of the available options when I installed from the template and I don't regret it.


[I figure it will be easier to let things lie fallow than to try to add them later on]


Good advice. Thanks


@johanatan: Can you post the code that isn't working?


(defn a-component []
   (let [some-vars ...]
      ^{:key "blah"}
      (fn []
        [re-com/v-box ...])))


If i put the ^{:key "blah"} inside the (fn [] and before the v-box then it works as expected but that doesn't help as I'm getting a new number XX and key "reagentXX" for each time the (fn []) is rendered


@dpsutton @johanatan: I did the opposite and didn't regret it - I prefer building from a base lein new figwheel now, stealing code from different templates as I need it, so that I have a greater understanding of how things work. Try them both and see which you prefer, they're both very valid approaches and I think they depend mainly on how you think and learn.


@johanatan: Any possibility of posting the actual code, or tweaking an existing example to show what exactly is happening? Are you trying to get the key on a-component or on the v-box?


Neither, the one between the two (which is named "reagentXX" in the react dev tools).


Unfortunately I can't post the actual code but, trust me, it looks exactly like that.


I'm not sure what you mean then. Could you show me a fake sample of the output?


Do you see any "reagentXX" components in your React dev tools hierarchy for anonymous function components?


It's just like any of those.


So, there have been occasions in my codebase where using the vector form to declare a component didn't result in things updating properly and I had to fall back to function call. I'm sure there's at least one of two of those in the particular hierarchy in question and that may be a factor here too.


But it seems that there are some quirks in the underlying reagent/react code around vector form and I had to resort to function call form to get things to update properly.


@johanatan: It might be worth investigating that angle further - if it's the root of the problem then what you're seeing may just be a symptom. I don't remember ever having to avoid the vector form, but that could just be an end of the week memory issue. I've got to head out for the evening, but hopefully someone else will be able to help.


Ok, but can you confirm that the attempt to add metadata to a (fn [] ...) was correct?


i.e., the approach is valid?


@johanatan: That part is outside of my expertise and experience - if you can't figure it out in the next couple of days let me know and I can dive in to it a bit further and do some experiments.


Ok, no worries. Thanks a lot for your help!