Just answering because it might be a few hours before the team wakes up, they might have other ideas, but it's fairly easy to add the electric-ws-handler to your own ring-jetty-server and then you can do whatever you want.

Just make sure to read https://clojurians.slack.com/archives/C7Q9GSHFV/p1678902874125889?thread_ts=1678901838.657109&cid=C7Q9GSHFV if you go with jetty 10, else you'll run into the same issue i did the other day, I believe the examples for 9 are up-to-date

I was planning to give a look at custom transit handlers today. Good timing 🙂 I’ll keep you posted

Yab I think you are talking about ring handlers, whereas Kevin wants to customize how values are serialized on the wire. Or am I confused?

Nah your right, I misunderstood

We have made progress. We are figuring what’s the right API and we will release customizable transit handlers in the near future.

Pushed custom transit handler support to https://github.com/hyperfiddle/electric/commit/047af21723fb315e6aef2791a302b11d30148804. See https://github.com/hyperfiddle/electric/blob/047af21723fb315e6aef2791a302b11d30148804/src-docs/wip/demo_custom_types.cljc. Note the comment in the example code. Keep us posted if the current approach is not compatible with your use case.

Could you share some code? Seeing the file would help

for example here I have a component for selecting or creating an entry

(e/defn SelectOrCreate [{:keys [table where display-key id-key empty-option create-option template]
                         :or {display-key :ds/name
                              id-key :ds/id}}]
  (e/server
   (let [tbl 0 #_(new latest-table-change> table)]
     (e/client
      (let [options (fetch. table #{id-key display-key} where tbl)
            !creating? (atom false)
            creating? (e/watch !creating?)
            create-val (str (gensym "new"))]
        (<% :div.relative
            (<% :select.select {:on-change (e/fn [e]
                                             (let [v (-> e .-target .-value)]
                                               (reset! !creating? (= v create-val))))}
                (when empty-option
                  (<% :option {:disabled true :selected true} (dom/text empty-option)))
                (e/for-by id-key [item options]
                          (<% :option {:value (get item id-key)}
                              (dom/text (get item display-key))))
                (when create-option
                  (<% :option {:value create-val} (dom/text create-option))))

            (when creating?
              (<% :div.absolute.bottom-0.left-0
                  (InputGroup. {:label create-option
                                :name "Luo"
                                :placeholder create-option
                                :on-enter (e/fn [val]
                                            (reset! !creating? false)
                                            (new insert! table (template val)))})))))))))

I copied this, stubbed out functions you didn't provide, and it compiled for me. I'd next restart everything or start removing code to see at which point does it fail

also, aren't fetch and insert! server functions?

They are e/defn that have e/server blocks

Is the code you shared in a .cljc file?

Yes

problem may be at entrypoint

probably next step is to send us your whole repo and see if we can reproduce

what is latest-table-change>

It is commented out, so shouldnt affect

oh i see

Can you minimize it down to an entrypoint + a few LOC?

I wonder if a userland macro could cause this

I’ll try to get a minimal repro

must be a userlang macro, because even this fails

(e/defn SelectOrCreate [{:keys [table where display-key id-key empty-option create-option template]
                         :or {display-key :ds/name
                              id-key :ds/id}}]
  (e/server
   (let [tbl 0]
     (e/client
      (<% :div.foo "foo" (dom/text tbl))))))

the backend side touches lots of code that has macros (like the clojure.spec.alpha)

Does it fail without <℅?

the <% works in other places that use server and client

push your repo and I will take a look

@U11SJ6Q0K one way to work around any potential issue in Electric is to wrap all heavy macro calls in an ordinary clojure function, instead of calling them from Electric regions

the macro namespace in question does some very heavy lifting, and expands to a bunch of clojure.spec definition calls at ns load time, so not really an option to do that from a function

I’ll come back to this later, for now I made this app in another way, so not critical

were you calling the heavy macros from Electric? It seems like you just have a namespace somewhere (not related to electric) with macros in it?

I wasn’t calling that, the compiler just seemed to get confused whenever some code referred to the namespace that had the macro calls in it

i dont really undertstand what that means

so in my .cljc file containing electric components I have a :refer [some.ns] at the ns declaration

and if some.ns has the macro calls, it seems to get confused

you mean :require ?

I understand this is not a very good bug report, but I’ll come back to it later when I have some time