Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handle "native" props better for different renderers #9

Open
lilactown opened this issue Jan 27, 2020 · 4 comments
Open

Handle "native" props better for different renderers #9

lilactown opened this issue Jan 27, 2020 · 4 comments

Comments

@lilactown
Copy link
Owner

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
Copy link
Contributor

darwin commented Jan 27, 2020

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 added a commit to darwin/helix that referenced this issue Jan 28, 2020
@darwin
Copy link
Contributor

darwin commented Jan 28, 2020

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

darwin added a commit to darwin/helix that referenced this issue Jan 31, 2020
@darwin
Copy link
Contributor

darwin commented Jan 31, 2020

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)

darwin added a commit to darwin/helix that referenced this issue Feb 3, 2020
darwin added a commit to darwin/helix that referenced this issue Feb 8, 2020
darwin added a commit to darwin/helix that referenced this issue Feb 16, 2020
darwin added a commit to darwin/helix that referenced this issue Feb 26, 2020
darwin added a commit to darwin/helix that referenced this issue Mar 23, 2020
@lilactown lilactown changed the title Always convert props to camel case Handle "native" props better for different renderers Apr 28, 2020
@lilactown
Copy link
Owner Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants