This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-02-14
Channels
- # announcements (7)
- # babashka (13)
- # beginners (98)
- # biff (20)
- # calva (3)
- # clj-kondo (5)
- # clj-otel (6)
- # cljs-dev (96)
- # clojure (22)
- # clojure-austin (30)
- # clojure-conj (4)
- # clojure-europe (53)
- # clojure-nl (2)
- # clojure-norway (63)
- # clojure-uk (3)
- # clojurescript (18)
- # cursive (10)
- # data-science (11)
- # datalevin (2)
- # datomic (7)
- # deps-new (1)
- # fulcro (3)
- # graphql (1)
- # gratitude (4)
- # hyperfiddle (43)
- # kaocha (4)
- # malli (15)
- # pathom (6)
- # polylith (2)
- # reagent (3)
- # reitit (2)
- # releases (6)
- # remote-jobs (1)
- # rewrite-clj (45)
- # ring (4)
- # shadow-cljs (47)
- # sql (5)
- # xtdb (8)
Hey, yes! Will DM
Hi đ I'm just now reading through the Hacker News discussions and saw @dustingetz mention this: > Mechanically, Electric is comparable to Solid.js except the reactive engine is general purpose, not coupled to DOM rendering, which is a special case of incremental view maintenance. Just a couple hours ago I saw this tweet about the new Solid.js dev tools: https://twitter.com/thetarnav/status/1625177986197778434?s=20 (and asked myself for the first time if there is any similarilty there or if you just both use the same words "signal" and "reactivity" đ ) Thought I'd share this here in case you missed and congrats on the release!
Thanks! The technical approaches are similar, we've experimented with DAG visualizers in the past, that is likely how an Electric debugger should work
That (and everything else) sounds very promising, looking forward to all that's to come
Questions: Will it play nice with a react native app? Looking at the reagent demo it looks like this would be possible. Also nearly all the example have db transact/query code mixed with UI in the same file much like a PHP file. It wouldn't be a problem to extract that out into a separate namespace to reuse and expose to a traditional REST api for mobile apps? I'm not familiar with the computer sciencey magic that's going on to make all this possible so I'm not capable of assessing the tradeoffs vs a traditional backend and mobile app/web frontend codebase. I really love what I see and if these concerns of mine are non issues I'll probably spin up a pet project pretty soon and see how all of this plays together. There's probably a lot of low hanging fruit with regards to documentation/demos for unsophisticated fullstack people like me because the demos make it look a lot easier to grasp than the introduction does. I don't have a computer science background but have immense experience building web apps. I'm typically one to let tech mature before giving it any attention but what I see is compelling.
> Will it play nice with a react native app? Sure, the reagent demo could be adapted to react native. > Also nearly all the example have db transact/query code mixed with UI in the same file much like a PHP file. It wouldnât be a problem to extract that out into a separate namespace to reuse and expose to a traditional REST api for mobile apps? You can call any clojure code from electric clojure. Just move the query in some shared namespace, so you can call it from both your REST endpoint and your electric Clojure program. > Iâm not familiar with the computer sciencey magic thatâs going on No magic đ have a look at Missionary to see whatâs under the hood (https://github.com/leonoel/missionary) > if these concerns of mine are non issues All concerns are valid. Thank you for sharing them. Feedback is welcome and helps us a lot. Donât hesitate to share what you are trying to build and the difficulties you are facing, so we can improve. Thank you for the kind words đ
I think once it has a bit more reagent/hiccup support I could see myself plugging this into an existing project I'm working on for sections I want "live." I could see using electric as my main websocket backend, running alongside my existing backend instead of going through the hassle of using sente and a mix of re-frame events/subs.
... and you just dropped the reagent demo as I was typing this đ Will see what I can do with it.
> Will it play nice with a react native app? Sure, the reagent demo could be adapted to react native. > Also nearly all the example have db transact/query code mixed with UI in the same file much like a PHP file. It wouldnât be a problem to extract that out into a separate namespace to reuse and expose to a traditional REST api for mobile apps? You can call any clojure code from electric clojure. Just move the query in some shared namespace, so you can call it from both your REST endpoint and your electric Clojure program. > Iâm not familiar with the computer sciencey magic thatâs going on No magic đ have a look at Missionary to see whatâs under the hood (https://github.com/leonoel/missionary) > if these concerns of mine are non issues All concerns are valid. Thank you for sharing them. Feedback is welcome and helps us a lot. Donât hesitate to share what you are trying to build and the difficulties you are facing, so we can improve. Thank you for the kind words đ
This demo is now available in the Electric Clojure repo. https://github.com/hyperfiddle/electric/blob/fee5c441ad809def70b17ce4f7b7c537f3a37a09/src-docs/user/demo_reagent_interop.cljc.
Is it possible to pass in an e/fn
block or something equivalent to work within reagent? For example sending data to server from an existing form input.
I tried and I'm getting this error: {message: 'Invalid p/fn in Clojure code block (use from Electric code only)'
As of today this is not possible. As a workaround, you can pass a callback or an atom from electric clojure to your reagent component. You can then use e/watch to react to changes on the atom.
đ Would be thankful if someone could point me in the right direction for implementing auth. Iâve read some of the source code and couldnât figure out a way to extend e.g. the ring handlers. https://github.com/hyperfiddle/electric/blob/master/src/hyperfiddle/electric_jetty_server.clj#L15
We will take a look at making a simpler demo, what specific requirements are you looking for?
If you send me a gist of what you have that would be helpful
My requirement is:
A server-side route that redirects the user to Steam for login. It needs to go via the server so I can store some data in a session cookie.
It's pretty simple in ring, just two endpoints. One for logging in and one for the auth callback.
This requires being able to specify routes, middleware and handlers. Not sure if it's out of scope for this project, in that case I apologize .
is there a ring-starter-app of some sort that we can fork, so that the question simplifies to "make Electric work in this repo with auth"
Hey we took a look this morning, we think the electric_jetty_server file has what you need. Can you add me to your repo so I can take a closer look at what you have and understand your specific context?
Hey I will come back to you on this. I'm currently unable to look into this for a while, got some other things I need to prioritize. I'll come back with an example repo.
đ I am trying the starter app. It just started and I can do multiplayer grocery-listing. So sweet! I'm trying to grasp what is happening still, my mind is blown. To get a feel I tried to do (def id id)
in the TodoItem
function. I can evaluate the function and the namespace in both CLJ and CLJS, but it blows up with âExceptionInfo: Unable to resolve symbol: idâ if I then try to restart the app. Same if I save the file and let shadow-cljs reload things. I'm guessing this is not supposed to work. Still, it confuses me a bit, because (println id)
works just fine, both in server and client forms. Can someone fill me in a bit on why I get this error?
def
is shadowed by Electric due to a legacy bad decision, sorry
you can use println
We need to fix it, it's just a legacy cleanup task
workaround:
(defn ddef [v] (def pez v))
or even
((fn [] (def pez v)))
what's happening is the (fn []) takes you back into an ordinary Clojure context (so no Electric magic in that region of course)
I was about to ask, but didn't think I would be able to get the answer, but this makes sense. đ
So, from both println and this embedded inline def I am now concluding that the code that goes immediatelly in the e/defn
body has an implicit server context?
it inherits the caller's context by default
we recommend you adopt the convention of calling your Electric functions from the server for now, this recommendation will be lifted soon
The October 22 demo video is among the coolest demo videos I have ever seen, btw. Not only is it mindblowing tech, the whole thing is wrapped in the story I need to begin to have an idea what it is all about and what is brought to the table. And delivered in just the right pace for me and with a clarity that is rare to experience. Fantastic.
which video?
This one: https://www.youtube.com/watch?v=fq4_W4vLA6g Maybe earlier than October. But anyway đ
Ohhh the hytradboi talk, thank you!
Earlier today I was watching this video about how React.js came to be. https://www.youtube.com/watch?v=8pDqJVdNa44 (It actually features David Nolen, who helped with making people understand the greatness of the project.) Very cool. And extra cool that I had watched that ^ video about streaming DAGs yesterday. It felt like I knew something they didn't know, haha.