hyperfiddle 2023-09-05 | Slack Archive

pez11:09:33

How do I test greater/less than with RCF? I tried :<, but that clearly wasn’t it. And checking the source code there doesn’t seem to be any other comparison “operator” available than :=. I’m probably thinking the wrong way about the whole thing.

xificurC11:09:01

only := and :throws for now, sorry. You can (< x y) := true, which gives a vague true not false failure report so it's not perfect but works. There's work in progress in RCF to improve this but currently no time left to finish

pez11:09:15

Thanks. I’ll make do with what I have. 😃

telekid17:09:16

Upgrading from v2-alpha-349-ge9996713 to v2-alpha-428-g22937f75, I get a Failed to load user.cljs RangeError: Maximum call stack size exceeded error. The issue appears to be exactly that: I can make the error appear and disappear by adding and removing an empty (dom/div) at a particularly deep (but not unreasonably deep!) leaf node in my application.

telekid17:09:29

The number of nested components is what I believe to be fairly typical for a web-app, I'm not doing anything wild here

Dustin Getz17:09:24

what web browser

telekid17:09:27

chrome

telekid17:09:16

happy to give you access to a branch on github if that would be helpful

Dustin Getz17:09:12

yes please add me

Dustin Getz17:09:00

what sha do i check out to repro by adding a single div and at which line

telekid17:09:30

1. README at https://github.com/hypo-sh/hypo/tree/main/server shows command to launch nrepl server with cider + shadow middleware; then connect as normal 2. Start app by calling (user/main) and nav to http://localhost:8080/ui/ , then view console. You shouldn't see any errors 3. Upgrade hyperfiddle version to current version here: https://github.com/hypo-sh/hypo/blob/main/server/deps.edn#L25, then restart and reconnect repl and restart app 4. Check console; you should now see call stack size error reported 5. Comment out https://github.com/hypo-sh/hypo/blob/2287a11934b01eedc55577cd72aeff0091b6b1a9/server/src/hypo/server/ui/recording.cljc#L224-L228 and save to see issue go away. Replace that form with a simple (dom/div) to see the call stack size error return

Dustin Getz18:09:39

perfect thank you

Garrett Hopper18:09:55

Just ran into this with the issue being turned on/off by adding/removing a core.match dependency, FWIW

👀 2

caleb.macdonaldblack06:09:15

I’m running into this one as-well in chrome. I have a bunch of nested dom components I noticed it with v2-alpha-422-g96e5c0a5

👀 2

Dustin Getz12:09:03

Quick update - we're escalating this issue, we first saw it several weeks ago on our largest project but didn't expect external users to hit it so soon. We don't expect it to be hard to deal with. Please continue to report any new information.

🙏 2

xificurC15:09:06

@UABU2MMNW can you add me to your repo as well? Since you've gone through the trouble of preparing a repo with complete reproduction steps (much appreciated!) I'd like to use it for driving the fix

telekid16:09:30

gladly, dm me your github email

telekid16:09:10

nvm, found you

xificurC17:09:44

update: master (unreleased) contains an optimization that reduces bundle size by ~15% on electric demos. If people could try it out to see if it resolves the stack size error that'd be very helpful! @UABU2MMNW I tried it in your repo but I couldn't reproduce the initial stack size exceeded error locally after bumping to v428 🤷

Dustin Getz19:09:37

@U797MAJ8M

👍 2

telekid00:09:37

> I tried it in your repo but I couldn't reproduce the initial stack size exceeded error ah, strange

Dustin Getz19:09:12

We pushed changes related to this to master, if you have this error please try out the commit

telekid13:09:52

@dustingetz can confirm, resolved the issue in my project. (I made sure to reproduce the issue on v2-alpha-428-g22937f75 prior to upgrading, too.)

grounded_sage20:09:05

I'd like to understand a couple of things. @dustingetz I saw in messages here you saying e/for is kind of a footgun. What are the problems that people hit with this? Also I am wanting to understand the usage of e/offload more. With the addition of Datahike is seems to require it for every transact . Is the assumption that you want to have this for everything that isn't reading data? It also seems to cause some repeating transactions when using some values handled by e/watch against the db connection. I suspect this is a user error but it's not expected behaviour. Especially since those transacts are inside of an (dom/on "click" ...)

Dustin Getz21:09:57

• e/offload moves a blocking computation to a threadpool (see docstring), so as not to block the reactive computation. databases are slow and blocking (even transact) so all database operations must be offloaded

Dustin Getz21:09:59

• e/for-by should be used instead of e/for for all use cases. e/for simply macroexpands to (e/for-by identity ...) (see source code). It's a foot gun because identity is rarely the right "react key", and if you provide the wrong keyfn electric will rebuild the children of the for loop too much which can cause flicker and loss of local state

Dustin Getz21:09:37

• repeating transactions are probably caused by cycles in the "DAG". A common form of accidental cycle is a side effect on a reference (atom or database) which causes queries to refresh which causes the side effect to happen again. This interacts badly with how the electric-ui "callback" patterns work. The next iteration of electric-ui does not use callbacks at all to avoid this and other problems. In the meantime use e/snapshot to break cycles. search this channel for e/snapshot to see past discussions

grounded_sage01:09:50

snapshot patched that problem. Thanks!

grounded_sage01:09:49

so e/offload queries as well. That was what I thought.

grounded_sage01:09:04

I will have to delve a little more into the for. That might be what is causing my flicker.

grounded_sage09:09:17

Snapshot fixed the flicker issue 🙌

grounded_sage09:09:25

Spoke to soon. Not quite the fix I need.

2023-09-05

Channels