Will Acton

ah, I finally figured out that I can use the `crkbd` config for QMK and `corne` config for ZMK

The only thing I don't like is that this doesn't really allow for any type safety :( I was hoping at some point a de facto definition of event emitter's...

I'm still seeing this issue. Ultimately defeats the purpose of the plugin if I can't trust linting errors as someone new to the language. :(

when you use `cljs-factory`, it puts the props map passed to the factory function under a single prop `"helix/props"`. If an HOC adds more props, then it won't be included...

The problem I see is that you wouldn't be able to use any 3rd party Hooks or components which are included from JS-land. I'm also not at all interested in...

What I've done to move the needle on this is completely decouple the hiccup parser from React. The API now is like this: ```clojure (def hiccup-config {:create-element create-element-impl :is-element? is-element-impl...

Having other fns for extracting and manipulating props could be useful as well. ``` (helix.core/props some-el) ;; => props as a bean ```

Hmm. That's a tricky problem, I'll have to think about it. `.cloneElement` does a shallow merge, which means it will ignore `"helix/props"`. `"helix/props"` is only present if you are using...

Hmm. To add more context, I don't believe that `nil` is a valid `:value` for most DOM elements, hence the reason that we would prefer to coerce `nil` to `js/undefined`...

The primary problem is still knowing whether the performance impact of memoizing the calculation is less than the performance impact of running the render function again. One thing I do...