Clojurians Log v2

@lilactown just saw you merged my PR, thanks, btw. I started wondering if $$ macro is really needed, shouldn’t $ fall back to dynamic code when static codegen is not possible?

the $$ is really only there for when you need to take it as a value

people are using it way more than I ever imagined, but that’s AFAICT mostly due to my lack of documentation

well, are you aware of the technique where you provide both macro and fn with the same name and compiler decides for fn if macro cannot be used? core lib uses this quite a lot

yep, could go that route now. I was also hedging in case $ didn’t work for some reason, but it is pretty baked now

I’m still pondering the kebab->camelCase proposal

it’s really a question of what’s more confusing: the macros silently changing the actual API of your components, or having to mix kebab and camel and remember which to use where?

is it that hard? in cljs code you use only kebab, in js land you use camel, according to conventions in given language

but I agree, that it might look like a magic for someone new (not familiar with details how it works)

I would propse doing no conversion at all by default, and to have an easy opt-in for something like I proposed - not sure if you want to support both, e.g. because of documentation and maybe even greater confusion for newbies

I’m still not done with my prototype code (didn’t find time), but I’d like to implement the opposite way during the weekened and start testing it on my codebase, I wonder if I find any issues with the approach

the implementation of the bean with custom key translation will be easy, I guess

I think in the happy path, always using kebab feels good because your code reads very consistently. in the sad path, though, or more complicated scenarios, it can get frustrating trying to figure out and debug when and why your code is changing underneath you. for instance, we recently built a fairly complex component at work using helix, that ended up doing some complicated stuff with cloning children prop manipulation. the dev that did this was new to helix (and CLJS), and there were a number of places where they got confused if they should e.g. use :class, :className . And it ended up depending on if they were creating the element or cloning the element.

of course, providing a helix version of clone-element that also used the same props API as $ would help here. but it also complicated the debugging process, because it was opaque when and why certain props would change without reading and understanding helix’s source code

how was he able to get his hands on raw props not wrapped in the bean?

using raw function as component?

they were using https://reactjs.org/docs/react-api.html#cloneelement to clone an already instantiated element with some new/changed props

and reading props that were set on a child element

ok, these are valid cases where js convetions leak into cljs

but I think this could be mitigated simply exposing props-bean in public api, people doing interop-y stuff should be aware that they want to wrap js-land props with that bean

but I understand that this might be too much to ask

I mean, the current state is not ideal right now either

depending on if you’re reading/cloning a helix component element, or a native element, and you want to override the class name, you will want to use either :class or :className 😵

well, even with native element I want to wrap it into props-bean, all cljs code should use cljs conventions

props-bean is kinda js->clj

actually this is my goal personally, to be able to write idiomatic cljs code all the time when I’m actually in cljs

no matter if component at hand came from helix or not

could create some tools for manipulating props / children / etc.

@lilactown I think I screwed that displayName patch: https://github.com/Lokeh/helix/commit/a3ba54ce6c2fa222b4137cfa2e03a3247160d688

here I don’t return the object at the end

that’s why you had doto there

ah, I missed that

do you want me to do another PR or you fix it on your own?

just that doto is misisng

https://github.com/Lokeh/helix/commit/ee1ca47ee5d86023470a61773c95e2d6b0001425 fixed