Comments (6)
@mfikes It would be great for me if val-hook-2 could get into next release. I started using it:
lilactown/helix#9 (comment)
No hurry. I can consume this lib via deps.end using git sha.
from cljs-bean.
Cool! I have a few questions.
With respect to key conversion, consider the following, which illustrates preservation of namespaces keywords:
cljs.user=> (require '[cljs-bean.core :refer [->clj ->js]])
nil
cljs.user=> {:my-ns/foo 1 :my-other-ns/bar 2}
{:my-ns/foo 1, :my-other-ns/bar 2}
cljs.user=> (->js *1)
#js {"my-ns/foo" 1, "my-other-ns/bar" 2}
cljs.user=> (->clj *1)
{:my-ns/foo 1, :my-other-ns/bar 2}
- Does your
key->prop
andprop->key
behave differently than the above illustrates? (No need to provide exact details; I'm just curious if it differed.) - Did you find a need to pass these into either
->clj
or->js
? I ask because onlybean
lets you do this currently. Perhaps you are usingbean
and passing your own converters and also passing:recursive
true
, and not even using->clj
or->js
?
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.
cljs.user=> (->js {:foo/bar #inst "2019"})
#js {"foo/bar" #inst "2019-01-01T00:00:00.000-00:00"}
This seems to get into areas that even ClojureScript's js->clj
and clj->js
don't currently offer any control, right, and where Transit might offer the needed control? (Happy to consider ideas that might make the capabilities in CLJS Bean more useful here, but just trying to more clearly define the problem to be solved.)
from cljs-bean.
Thank you for the detailed feedback!
My key->prop
and prop->key
do the very same thing I just discovered cljs-bean does by default. So no need for that anymore, deleted them now!
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.
from cljs-bean.
This project started off with the simple idea of "converting" js->clj by implementing thin wrappers supporting protocols like ILookup
.
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 ->js
is currently no more than the idea of "unwrap and return the internal JavaScript (in constant time) if possible, and if not, delegate to clj->js
."
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 clj->js
might be outside of the scope of this project, and better handled by things like Transit (especially if your problem is clj->js->clj).
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 assoc
, get
, nth
, and so on). In that spirit, you might find yourself needing to craft a JavaScript object, wanting to use the facilities in this library, building up said object using assoc
etc, but then somehow wanting to have fine grained control over what happens when things get converted.
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.
from cljs-bean.
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
from cljs-bean.
Alternative experiment is in https://github.com/mfikes/cljs-bean/tree/val-hook-2.
The primary difference is that, instead of user-supplied ->val
user only supplies a transform
fn that is used inside of ->val
.
from cljs-bean.
Related Issues (20)
- Upgrade test-check, eliminate NaN-avoiding generators
- Simplify unwrapping code
- Improve perf of ->js by unwrapping non-recursive beans
- Malformed cljdoc edn
- No need to refer exclude array
- Can assoc map or vector while remaining a bean
- Writing ->clj to transit doesn't work HOT 4
- Document that values are immutable but not persistent
- Add fast paths for primitive values
- Update docs to give example of associng a bean HOT 3
- bean :recursive true and ->clj behaves differently HOT 4
- ->clj with React events HOT 3
- Avoid contains? in -contains-key?
- Question marks in key cause issues with Transit HOT 1
- Working With Arrays HOT 7
- Include prototype fields on bean, optionally HOT 1
- Data prints as expected but cannot be access as expected? HOT 2
- How to use bean and ->clj on objects like js/Error? HOT 3
- Is it possible to support custom keyword functions as in bean.
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from cljs-bean.