Fork me on GitHub
#fulcro
<
2017-10-04
>
rastandy07:10:11

Congrats for the 1.0 release!

rastandy07:10:10

I’m not sure I’ve found a bug, better asking people before filing a false bug report.

rastandy07:10:50

I’m finding that when correctly read EDN response from servers, contains custom record types, these types are lost in favor of standard maps when fulcro client dedups data into the db

rastandy07:10:17

is that something other people are experiencing?

mitchelkuijpers10:10:57

@rastandy That is something that you need to fix in transit-clj and transit-cljs yourself. Fulcro uses transit and transit gives you options to add extra read and write handlers.. But I would suggest just using maps or adding a post-mutation and then change it into a record

rastandy10:10:00

@mitchelkuijpers edn is read correctly from the transit endpoint, the problem arises, I suppose when the om or fulcro machinery (I don’t really know) dedup the data in the app state.

mitchelkuijpers10:10:54

So you have added custom read and write handlers?

mitchelkuijpers10:10:34

Because if I do:

`
(defn str->clj
  [string]
  (transit/read (reader (ByteArrayInputStream. (.getBytes string)))))

(defn clj->str
  [data]
    (with-open [out (ByteArrayOutputStream.)]
    (let [w (om/writer out)]
      (transit/write w data)
      (.toString out))))

(defrecord Point [x y])

(-> (clj->str (Point. 1 2))
    (str->clj))
this returns {:y 2, :x 1}

rastandy10:10:33

yes, I added write and read handlers, and I can see them being read and written through the wire

rastandy10:10:36

correctly keeping their instance types

rastandy10:10:03

I have a custom fulcro.client.network/Network implementation and I can see in my response-ok function that my record types are still preserved in the response, just before passing them to the “ok” function provided by the framework

rastandy10:10:57

I have code like this:

rastandy11:10:01

when I print I can see my custom records in the browser console

rastandy11:10:37

of course my transit/reader has been augment with the read and write handlers for my types

mitchelkuijpers12:10:59

Ah ok, just wanted to make sure, they probably do a merge on a map somehow, but not really sure on the internals. I do think you can override the merge somewhere

rastandy13:10:14

@mitchelkuijpers right, a merge is something I should look for in the sources. Also an “into {}” call

mitchelkuijpers13:10:35

I think you can override the default merge

rastandy13:10:05

I’ll take a look at that. thanks for the suggestion @mitchelkuijpers

roklenarcic14:10:42

I've found a bug in Fulcro CSS: At the bottom of documentation it gives an example in using the Garden's selectors: (local-rules [this] [[(garden.selectors/> :.a :$b) {:color "blue"}]]) should result in: .namespace_Component__a > .b {

roklenarcic14:10:59

I've tried this: [(garden.selectors/& :.badge-neg :$badge) {:background-color "#ce8483"}] and the result was: .ledger_ui_root_Person__badge-neg$badge {

roklenarcic14:10:13

as you can see it incorrectly put $ where . should be

roklenarcic14:10:23

if I change it to [(garden.selectors/& :.badge-neg :.badge) {:background-color "#ce8483"}] I get .ledger_ui_root_Person__badge-neg.badge { which is what I expected.

roklenarcic14:10:36

from the first spec

timovanderkamp15:10:44

@roklenarcic You are right, i've tried to reproduce this and it only seems to go wrong with the &-selector. If you can make an issue for this i will look into this soon. For now you can use a work-around for this: [:.a [:&$b {:background-color 'blue}]] -> .namespace_Component__a.b {...} [:.a [:&.b {:background-color 'blue}]] -> .namespace_Component__a.namespace_Component__b {...}