This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # adventofcode (246)
- # aleph (5)
- # aws (7)
- # beginners (161)
- # boot (3)
- # calva (42)
- # cider (40)
- # clara (10)
- # cljdoc (7)
- # cljs-dev (40)
- # cljsrn (6)
- # clojure (170)
- # clojure-dev (8)
- # clojure-greece (2)
- # clojure-italy (15)
- # clojure-kc (2)
- # clojure-new-zealand (13)
- # clojure-nl (13)
- # clojure-russia (3)
- # clojure-spec (5)
- # clojure-uk (160)
- # clojurescript (72)
- # clojurex (1)
- # cursive (7)
- # data-science (9)
- # datascript (1)
- # datomic (120)
- # devcards (4)
- # emacs (18)
- # figwheel-main (10)
- # fulcro (34)
- # kaocha (3)
- # luminus (1)
- # lumo (6)
- # music (1)
- # nrepl (23)
- # off-topic (2)
- # pedestal (4)
- # re-frame (42)
- # reagent (36)
- # reitit (10)
- # ring-swagger (21)
- # shadow-cljs (124)
- # spacemacs (6)
- # tools-deps (14)
- # unrepl (3)
- # vim (2)
@petr people from time to time talk about running re-frame on the server, but I don't think it is a very good fit.
There's a thread on the re-frame GitHub repo about it if you're looking for more details
@danielcompton thanks for the reply. I figured as much. Would have just been convenient for deployment. I'll see if I can find the thread
It sounds like it's pretty tightly tied to Fulcro - but if you can get it working with re-frame that would be pretty awesome! I'm planning to look at it when I get a chance but not sure if I will attempt to use it with re-frame or not.
Yeah, I'm trying to figure out if it's a good philosophical fit for re-frame. We've had some annoyances traversing a big app-db before so thought it might be handy.
I should also say that we're using re-graph and lacina-pedestal so I'm wondering if it would complement or conflict with that
If you haven't seen them, both https://www.youtube.com/watch?v=mgSSVTDZvkI&t=9s and https://www.youtube.com/watch?v=EDojA_fahvM were great talks that might give you other ideas with that stack
I'm not sure if this is supported natively but IIRC an event can contain any arbitrary data from the dispatcher. You could add a
:who field to the event to indicate where the event came from if it is relevant to the event handler.
that's true - my app is not big yet, so i can add that to the couple places that ship the evt
I would offer one word of caution: If you event handler needs to know where the event came from, it might be a code smell. That is not 100% true and I can't really say without having looked at the code but, generally speaking, I try and be agnostic as possible WRT my event handlers caring about who or what dispatched the event. Again, not saying it is wrong, just something to think about and maybe see if you can implement things in such a way that your event handlers do not need to know who is dispatching the event.
it was more for debugging - i know i'm getting this event, and it's doing the right thing, but where the hell is it coming from, and why?
if i use fn-traced in all my events, will i have any problem in production? or the compiler transpile it to a normal function when we use it on production build?
@mateus.pimentel.w: Should be compiled back to a normal function in production (as long as you set up the dependencies properly based on https://github.com/Day8/re-frame-debux/blob/master/README.md#two-libraries )
should i use fn-traced on effects and co-effects too? ( I think that it is only for events, haha, but asking just in case. Probably not. )
@mateus.pimentel.w: Try it and see what fits your application best - I over traced and under traced until I found the sweet spot for me. Some things I thought would be good to trace were totally overkill, other things I thought didn't need tracing ended up being the things I needed to troubleshoot.
When rendering timestamps to relative dates (`now`,
5m ago, etc), I run into a problem of the db not changing but me wanting to re-render, since time has changed. I'd like to
@(subscribe [::refresh.event/ms 1000]) in my view to have it render at least every second, but implementing this subscription has me wondering how I can do it without touching the db.
Yeah, I could update the db every 100ms or something to trigger the subscription to check if it should change, but that's just going to clog up my event queue and put junk I don't want in my db. In short, is there a way for me to make a reaction around an atom which changes via a JS timer so this can be accomplished without changing my event log and my db?
There's a timer example on https://reagent-project.github.io/ - is that kind of what you are looking for?
Thinking too much in terms of re-frame and not in terms of reagent. Thanks, @U054BUGT4.
Would be nice to be able to use
subscribe for it, though, in the format I mentioned. That way it feels like all other subscriptions.
Then you don't need to think in re-frame terms at all - modify that example to take what you need, and when you want to use it then grab the current value of the atom.
Yeah, I was just hoping I could. Sounds like I might need to just work with the
r/atom directly though.
Yeah - you can create the atom for the state and the underlying reagent component as part of your UI component. There are good examples in https://github.com/Day8/re-com for how to handle different local state like that.