Fork me on GitHub
#hyperfiddle
<
2023-02-14
>
dumrat09:02:18

I saw it mentioned that there are Zoom onboardings

👍 2
Dustin Getz15:02:51

Hey, yes! Will DM

dumrat09:02:24

Any details?

Mario Trost10:02:09

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!

👀 2
Dustin Getz14:02:37

Thanks! The technical approaches are similar, we've experimented with DAG visualizers in the past, that is likely how an Electric debugger should work

👍 4
Mario Trost07:02:26

That (and everything else) sounds very promising, looking forward to all that's to come

Omar11:02:51

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.

👀 2
Geoffrey Gaillard11:02:55

> 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 🙂

Omar14:02:52

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.

Omar14:02:35

... and you just dropped the reagent demo as I was typing this 😉 Will see what I can do with it.

đŸ€ 2
👍 2
😆 2
â˜ș 2
Geoffrey Gaillard11:02:55
replied to a thread: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 🙂

Omar00:02:10

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)'

Geoffrey Gaillard01:02:47

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.

👍 2
dangercoder21:02:13

👋 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

👀 2
Dustin Getz21:02:25

We will take a look at making a simpler demo, what specific requirements are you looking for?

Dustin Getz21:02:31

If you send me a gist of what you have that would be helpful

dangercoder21:02:55

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 gratitude-thank-you.

Dustin Getz21:02:36

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"

Dustin Getz14:02:27

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?

dangercoder21:02:51

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.

Dustin Getz21:02:09

ok, no worries

thanks3 2
pez21:02:24

👋 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?

Dustin Getz21:02:59

def is shadowed by Electric due to a legacy bad decision, sorry

Dustin Getz21:02:08

you can use println

pez21:02:51

I'm a heavy inline def user 😃

Dustin Getz21:02:54

We need to fix it, it's just a legacy cleanup task

Dustin Getz21:02:15

(defn ddef [v] (def pez v))

Dustin Getz21:02:27

((fn [] (def pez v)))

pez21:02:01

Thanks! I'll try right away.

Dustin Getz21:02:33

what's happening is the (fn []) takes you back into an ordinary Clojure context (so no Electric magic in that region of course)

👍 2
pez21:02:35

I was about to ask, but didn't think I would be able to get the answer, but this makes sense. 😃

🙂 2
pez21:02:10

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?

Dustin Getz21:02:29

it inherits the caller's context by default

pez21:02:11

Ah, yes, and it is called from the server I now see.

Dustin Getz21:02:18

we recommend you adopt the convention of calling your Electric functions from the server for now, this recommendation will be lifted soon

🙏 2
xificurC08:02:37

@U0ETXRFEW inline defs landed on master

metal 2
pez21:02:15

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.

🙂 4
pez21:02:14

This one: https://www.youtube.com/watch?v=fq4_W4vLA6g Maybe earlier than October. But anyway 😃

👍 2
Dustin Getz21:02:37

Ohhh the hytradboi talk, thank you!

pez22:02:50

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.