Fork me on GitHub

this is awesome!


@peterbak @colin.yates : In won't the subscriptions be re-done on each change to the temperatures or id->fruit ratom? They are derefed outside of the final reaction that is the result of the subscription function. Or maybe I still don't understand how reactions work.


@sooheon: your link do not work


@sooheon: how are you calling panels when the url changes?


@hugobessaa: Hey thank you, I realised that my problem was using a form-2 function without also sending the argument to the inner function. In the fractalify codebase, actually it seems that he sent the args to just the inner fn, while re-frame docs recommend supplying to both. Both ways seem to work in my app—is there a practical difference?


AFAIK you need to keep them with the same arity


Actually I don't think they need to be the same arity. The "outer function" just holds the initial values, and the inner render function will hold the values that are updated by react


That's why if you forget to repeat the arguments, the component will never seem to update


because you're actually using the initial values


I guess if you don't define the parameters for the outer function, the component just won't get any initial values? No reason to really do that though


I'm just guessing though. I thought both of them need to have the same arity. 😛


How much of a problem is it to subscribe in a form-1 component that has arguments?


As far as I understand that means that the subscribe code is executed each time the component is re-rendered, instead of just using the reactions these subscriptions return. However I don't know how big a performance impact that really is.


On our page every keystroke leads to around 100ms of JS activity in the profiler.


subscribe returns a ratom. You will want to subscribe once and let reagent do it's magic to just render your components when that ratom value changes. See It superficially explains how form-2 works


are there any viable solutions for 2-way syncing the local data store with the server?


that's a million dollar question

jaen20:01:39 is the closest thing to that. I've also remember dato and posh in that general niche. I'm also doing something like that, but not in the open ATM.


i am also writing a solution but my gut tells me that i am reinventing the wheel at numerous places


@jaen: looks like posh is only client side , dato looks good but doesnt seem ready


Hmm, yeah, it seems posh is only client-side indeed. is ATM the most advanced solution. I recall the maintainer mentioning that the synchronisation part can be used separately from the DOM part, but I didn't yet have any time to look into that.


@shaym I’ve done that using as the backend data store and kept it in sync with a local ratom. Worked pretty well for building some basic multiplayer (2-6 player) turn based games