No idea what you're looking at, but it's quite often that something in the CLJ world appears unmaintained where it's actually simply complete.

https://git.sr.ht/~dannyfreeman/clj-kondo-re-frame-hooks together with this gist https://gist.github.com/roman01la/c6a2e4db8d74f89789292002794a7142

So why do you think it's unmaintained? It's been last updated just a year ago. Does it not work?

I guess I can try them out… I was just wondering how many people actually use these custom linters

FWIW, I don't. :) There are 2 linters in the first project. The first one now has a warning issued by re-frame itself and the second one doesn't seem that useful because the app will blow up as soon as you use such an event. The second one seems a bit more useful though.

Sweet. 🙂 I think I’ll try the gist and see if I get a more helpful experience than what clojure-lsp already offers (namely, autocompleting keywords and jumping to definition)

For some context: I’ve decided to start customizing clj-kondo for some things like line length limits, and I figured I may as well check out custom linters people use for popular libraries out there.

Yeah, that makes sense.

Why would you need extra config for re-frame?

The second link has some IMO useful linters, like the :<- check (which could also be expanded to :-> and :=>, I imagine).

For me: mostly bells and whistles to improve the programming experience. While an unused sub may cause clj-kondo to warn the user about unreferenced keywords, it seems nicer to me to explicitly say “this subscription is not being used anywhere”. Or possibly catching anti-patterns like calling rf/subscribe outside of a reactive context So that’s why I ended up searching around for re-frame-specific setups

Hi, so in the past I've modelled focus using a combination of things: 1. Each component that needs focus gets a unique id 2. There is a global piece of state that tracks what component currently has focus, usually this would be modelled as a stack so you can return focus to previous components 3. Reactive subscriptions that depend on the global piece of state, and whether the component should regain focus I'm actually releasing a library in the next couple of days that helped me with 1, and tying everything together.

To properly answer the OP's questions, one would need to know why focus tracking is needed in the first place. And what "tracking" means exactly.

I would like to keep track of a focus in a cell in a table, and depending on keyboard input, perform certain actions on the table. For instance, "j" would go down a cell, "h" would go left a cell. I have other things (like cloning a cell with "c") that are not necessarily navigational, so keeping track of which element is in focus is important. And by tracking, I just mean having it be subscribable by other elements of the webpage.

Instead of keeping track of the focus, I'd: • Intercept all keyboard events of interest • In the event handler, get currently focused element • Figure out how that focused element should react to that keyboard event, if at all

👆This is good. I would also add that you need to determine whether you are dealing with input elements, and need to shift the cursor between those input elements. Or whether you are simply showing visual feedback to the user about the currently "active" cell.

Thanks, that seems like a better way to go about it.

Mouse position is a little different because it is not necessarily tied to any one component, and depends on what you're trying to accomplish. If you just want to always have the current position of the mouse represented in app state, then you probably want to attach a global "mousemove" event listener to the document, and on each event, grab the mouse position from the event and add that to your global state in your db. There's some considerations here about maybe wanting to debounce that, so you don't unnecessarily thrash your db with excessive updates. Also, depending on what you're trying to do you may want to conditionally enable or disable that global "mousemove" listener over time. For example, if you are dragging something and want to track the mouse position, you only really want the listener enabled for the duration of the drag.

Thanks! I can see how they are different.

I always thought this technique using core.async was really elegant: https://swannodette.github.io/2013/07/12/communicating-sequential-processes/ and the accompanying talk https://www.youtube.com/watch?v=AhxcGGeh5ho doesn't really deal with tracking the state, but if you're doing interactive dynamic UI with events it can be quite elegant