Clojurians Log v2

Something I'm working on for clj-kondo: user-level hooks for calls. E.g. for re-frame:

Very nice!

Nice! Although, IIRC re-frame itself doesn't restrict the event IDs in any way - it can be a keyword without namespace, a symbol, a vector, whatever.

Ah, but given that it's user-level code, then it doesn't matter that much. Whatever a particular user decided to do.

yeah, it gives the user choices about their own code style

^ there the code is in its own file

Would it possible to make clj kondo be aware of all events?

Like using the event registry and check if the dispatch always sends a valid event?

Idem for subscriptions? (I am just asking)

@neo2551 Theoretically one could write a hook for reg-event-fx and register all the keys into some state. And a hook for dispatch will then check the state. But this depends on the order of how the code is linted

clj-kondo currently does not care about order of how files gets linted, it doesn't sort them in terms of namespace dependencies

and I guess re-frame already emits warnings for this at runtime right?

I guess if there is a hook at the end, then you can compare all registered events and all dispatched events and discover discrepancies

but this only works when you lint all relevant files at the same time

as of now, some hacky solution would be to use println or prn in the hooks for both dispatch and reg-event-fx and then write a little script to compare the outputs

Thanks :)

Pretty new to re-frame, I’m trying to do something like https://github.com/nilenso/pencil.space/blob/lobby/client/cljs/src/game/events.cljs#L30. I’m trying to fire a series of side-effects when this event is dispatched. Two questions: 1. I assume I can’t assume any particular order for their firing? 2. How do I handle dispatching multiple fx like this which share the same key? Is this even a good idea?

1. If you mean the effects in ::create-or-join, then yes, the order is not defined. If you really need some ordering, just chain events, i.e. use the :dispatch effect and in that event use the next effect. 2. You can either employ the event chaining described above or make the effect handler accept multiple sets of arguments.

Hrm, I considered doing 1., but that was making my chained dispatches coupled with the next effect

This seems super useful, I’m using a 100% namespaced kws and I often run into situations where my qualification errors aren’t correctly caught during build-time.

Not sure I follow. You should end up with "private" events - you will not call dispatch on them from anywhere.

using the renatal lein template (react native), i switched a few things around and my events aren’t firing when i dispatch from my repl. are there common pitfalls for this or is it a known issue by chance?