Handle "native" props better for different renderers

[lilactown]

We could remove a lot of the work involved with using different renderers (react-three-fiber, react-native, etc.) and make interop slightly easier if we defaulted to always converting kebab-case to camelCase when using $ / $$, and always transforming camelCase to kebab-case in defnc body via a bean with custom key->prop and prop->key as suggested by @darwin.

There might still need to be some determination of whether an element is "native" in order to decide whether to recursively convert the :style key, but this could be handled by helix.dom and / or other wrapper macros on a per-case basis.

[darwin]

Just random thoughts:

I think there should be a well-documented set of rules for renaming keys and it should give us two-way mapping. $ and $$ will do mapping one way into js-land. And custom bean will implement mapping the other way into cljs-land.

btw. The mapping doesn't need to be shallow, handling :style should be part of that mapping. The only trick would be to properly handle sub-maps, e.g. when cljs code asks to pull :style it gets a "sub-bean" with the same rules still in place. Also the bean could be made read-only so user won't accidentally try to write to it.

As an escape hatch there should be a way hot to quote individual keys when coverting into js-land[1]. And the custom bean should give us some escape hatch to get properties using js-land key names.

[1] #8

[darwin]

@Lokeh FYI, I started experimental work on that props translation. See the above commit.

[darwin]

I just completed the experimental work and ported[1] my code to use this branch[2].

Good news is that implementation of the props-bean wasn't that hard[3], but I had to use val-hook-2 branch of cljs-bean[4]. I think we can make that work go into next cljs-bean release.

[1] binaryage/cljs-react-three-fiber@c79db08
[2] https://github.com/darwin/helix/tree/experimental
[3] darwin@596648c#diff-4e2696d03555bd7c23ee60920d4655feR114-R146
[4] mfikes/cljs-bean#67 (comment)

[lilactown]

In helix 0.1.0-SNAPSHOT, there is a $d macro which implements the specific transformation of props for DOM (or DOM-like) elements.

The strategy here is to be explicit about what prop transformation you want to use when rendering the component as an element; e.g. there could exist an $rn for react-native, $r3 for react-three-fiber, etc.

This way, the $ macro does not need to try and reconcile all of the differences that each platform's elements has in regards to prop conventions.