-
Notifications
You must be signed in to change notification settings - Fork 9
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
prop->key and key->prop for values #67
Comments
Cool! I have a few questions. With respect to key conversion, consider the following, which illustrates preservation of namespaces keywords:
With respect to value conversion, it sounds like your use case might involve objects that don't naturally have a representation in JavaScript, or maybe you desire to control that representation. An example of that might be the following where you might not want a date instance appearing in your JavaScript object, but perhaps you might want to express it as a string.
This seems to get into areas that even ClojureScript's |
Thank you for the detailed feedback! My I really like that cljs-bean has this as default behaviour. And it makes sense, when you know that your prop key is supposed to be a (potentially) namespaced keyword, it is natural and simple to encode and decode as a string. With property values it's different because you don't know that your value string is supposed to be a keyword. For things like date instances and keywords you would need to parse every single value with custom predicates to look for patterns that would trigger custom decodings. Probably expensive, and also introducing some API complexity. And as you're saying, other libs does this well and are probably a better tool for the job. |
This project started off with the simple idea of "converting" js->clj by implementing thin wrappers supporting protocols like The ability to convert back from clj->js was motivated by a suggestion of Will Acton's in #10, which essentially resulted in CoW wherever feasible, while maintaining an internal JavaScript representation, and converting to a conventional persistent data structure when not. So So, given this, it might be fair to say that CLJS Bean might be good at problems that start from JavaScript, such as js->clj->js. But your example of clj->js->clj, as discussed above, raises additional concerns surrounding control over value conversion. Not adding anything new really by saying the above, just trying to clarify my thinking by spelling it all out. I think I'm still of the opinion that fine-grained control of clj->js, especially in areas beyond what currently controllable in But, then again the high-level "stance" of this project is to try to make it easy to relatively efficiently interoperate with JavaScript without causing you to need to learn new APIs (by essentially allowing you to use all of the usual functions like It is not currently clear to me how to do this, apart from your suggestion alluding to some sort of API that calls back with the key along with the value, so that you have all the hooks you need to control value conversion. Maybe this ticket is worth sitting on until it becomes clearer which, if any route should be taken. |
This branch has an experimental change that allows clients to pass a function that will convert JavaScript values to ClojureScript values: https://github.com/mfikes/cljs-bean/tree/val-hook |
Alternative experiment is in https://github.com/mfikes/cljs-bean/tree/val-hook-2. The primary difference is that, instead of user-supplied |
@mfikes It would be great for me if val-hook-2 could get into next release. I started using it: No hurry. I can consume this lib via deps.end using git sha. |
In the app I'm working on we use custom converters to be able to preserve namespaced keywords through a cljs->js->cljs roundtrip. In cljs-bean this fits perfectly, we were able to reuse our code by plugging it in as
prop->key
andkey->prop
converters.That's for the keys, which is obviously the most common and sensible use case. But we also occasionally need to do the same for property values. So for us it would be pretty great to be able to extend the
cond
statement in the->val
function.The text was updated successfully, but these errors were encountered: