Prevent keywords as values from being converted into strings on change?

[ryrobes]

Hi, I was curious if it was possible to avoid keyword values from being cast into strings for the return model on-change?

{:my-key :my-value} will always be changed to {:my-key "my-value"} even if that part of the tree isn't being modified - probably not possible, since keywords as values are not a thing in js (edn -> js -> edn is "lossy" in a way I suppose), but thought it was worth asking.

Edit: Looks like even "keys" for vectors get the same treatment, empty maps get removed altogether, and some other strange mutations are happening.

Raw incoming EDN to model:

{:json-test {:root {:map-key1 [:vec-keyword1 :vec-keyword2 :vec-keyword3 :vec-keyword1 ["thing1" "thing2" :new-map {:key11 [1 2 3 4]} :vec3 [:test1 :test2 2 3 4]]]}, :other {}}}

After update w json-editor (changing string "thing1" to "thing1a"):

10x diff - only before:

{:json-test {:root [:map-key1 [:vec-keyword1 :vec-keyword2 :vec-keyword3 :vec-keyword1 "thing1" nil :new-map nil :vec3 [:test1 :test2]]]}}

10x diff - only after:

{:json-test {:root [:map-key1 ["vec-keyword1" "vec-keyword2" "vec-keyword3" "vec-keyword1" "thing1a" nil "new-map" nil "vec3" ["test1" "test2"]]]}}

Added an image since the EDN formatting is going to get ruined.

Oh, and if I try and be cheeky and add a colon to the front of a keyword that I know is going to be stringified, most of the rest of the map gets destroyed in the update process.

Thanks Isaac! Cheers.

[superstructor]

@ryrobes Thanks for the report.

Initially I marked this as a bug. However after further thought I realised this is a json editor. Maybe re-jsoneditor should not be doing any transformation at all; i.e. "json in, json out". Either way, the npm dependency on which this is based uses a js object as its internal model so there must be some transformation somewhere between the two worlds. Currently re-jsoneditor does (clj->js x) and (js->clj js-x :keywordize-keys true) which I have now realised is probably too much.

So beyond clj->js and js->clj, which is arguably already too much, its up to the library user to transform their own datastructures.

I'll leave this open as maybe there should be a way to set the model using a raw js object to avoid the clj->js and js->clj transformation ?

[ryrobes]

Yeah, I can totally understand that - but to play devil's advocate, how many CLJS apps are using raw JSON aside from external facing edge cases? I'd be willing to be that most of us are passing around EDN internally. That being said, it def limits the situations this can be used in. So close to being a great user friendly structural map editor, yet so far.

That being said, I'm still going to try and use it - but I can't bork my maps in the process, if I come up with a clean workaround of some sort that enables this, I'll submit a PR. Thanks!

[superstructor]

A PR would be welcome, if there is a workaround. 👍🏻 @ryrobes

[ryrobes]

I ended up doing a somewhat simple temp workaround by using a different converter that add string artifacts to preserve keywords (https://github.com/wilkerlucio/edn-json) and converting it on the way in w edn->json, and then uncoverting it on the way out json->edn after I removed the double colon that gets added in the string / sanitize process.

Something like:

[com.wsscode.edn-json :refer [edn->json json->edn]]

; stuff

(defn remove-dbl-keywording [data]
  (let [dotted->dashed #(-> % str (clojure.string/replace "::" ":") (subs 1) keyword)
        transform-map (fn [form]
                        (if (map? form)
                          (reduce-kv (fn [acc k v] (assoc acc (dotted->dashed k) v)) {} form)
                          form))]
    (clojure.walk/postwalk transform-map data)))
    
; stuff
    
[jsoneditor 
   :model (edn->json map-data)
   :on-change #(rf/dispatch [::update (json->edn (remove-dbl-keywording %))])] 

There are still some usability issues, so I'm not sure about integrating it into the wrapper w a PR just yet - but this at least will preserve the EDN and allow proper read/write of EDN structures.

(not quite user friendly for ppl who don't understand EDN and JSON, but at least the maps are safe!)