This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aws (17)
- # babashka (2)
- # beginners (131)
- # bristol-clojurians (1)
- # calva (16)
- # chlorine-clover (6)
- # cider (10)
- # clara (5)
- # cljsrn (82)
- # clojure (176)
- # clojure-dev (14)
- # clojure-europe (13)
- # clojure-italy (13)
- # clojure-nl (4)
- # clojure-spec (10)
- # clojure-sweden (32)
- # clojure-uk (32)
- # clojuredesign-podcast (2)
- # clojurescript (34)
- # community-development (2)
- # conjure (17)
- # cursive (4)
- # datomic (51)
- # emacs (6)
- # figwheel-main (26)
- # fulcro (16)
- # graalvm (11)
- # jobs (2)
- # jobs-discuss (30)
- # kaocha (4)
- # meander (23)
- # off-topic (34)
- # pathom (5)
- # re-frame (10)
- # reagent (3)
- # reitit (6)
- # releases (3)
- # sci (36)
- # shadow-cljs (27)
- # sql (9)
- # testing (6)
- # tools-deps (28)
- # vim (8)
After a few hours of working on a project, I experience freezing in Chrome when I reload the page.
It only occurs on page refresh. The page loads completely and I have a few seconds of interaction. Then the page freezes. If I watch
htop, I see one Chrome process chewing 100%+ processor and 3 others ~20-25%. Memory usage for Chrome steadily grows by about half a percent per second while the page is frozen. I first notice this after about an hour of working and the freeze only lasts a second or so. The longer I work the longer the freeze. After several days of not rebooting, I got an out of memory error. Restarting Chrome doesn't fix the issue. It happens regardless of whether Fulcro Inspect or devtools are open. Clearing browser history has no affect.
Any ideas? Next time it occurs, I'll try Firefox and restarting the shadow-cljs watcher. Also I'll try disabling the Fulcro Inspect extension; maybe it's causing the issue even though devtools isn't open.
Unfortunately not. That sounds as a good plan. What about cpu profiling to see where is it? Coot there be an infinite loop somewhere in your code or something?
sounds like GC spinning looking for RAM in js. Chrome restart will fix anyting Chrome has, but other apps/os could be causing the pinch to begin with. Oh, localstorage is perhaps a culprit? It might be cached in RAM?
Is there a way to write a “reverse query”? find all entities with joins to my current entity? I vaguely remember this was discussed in this channel at one point…
@mroerni you have the database. There is no EQL for it, but it is easy enough to just look through the database for the ref value you’re interested in
If you need it as something that is “kept up to date”, then some strategy where you keep that derived value up-to-date in the db would make it possible to query for it. The point is that Fulcro’s interpretation of EQL is runnning on the UI’s dime, so it does not supply anything that would be slow…finding reverse refs on every animation frame makes no sense
There is ongoing work on creating a subsystem for Fulcro that does efficient computation of derived facts and puts them in the db, but there is nothing standard yet
This is some work-in-progress I’m aware of: https://github.com/JJ-Atkinson/fulcro-subscriptions
Is there any repository/project that I can take look to see how to write components tests?
1. mostly “don’t” is my advice. 2. If you do, remember that they are meant to be pure visualizations of props, and your query says what that should be. Write specs for each prop with generators, and you can “fire data” at them and make sure they don’t crash 3. If you do (2), it can be useful to put that in Workspaces so someone can press “show me generated data on this component” and you can see what it looks like. Other UI testing is mostly a waste IMO. Some number of full-stack smoke tests at the UI are nice, and I recommend http://cypress.io for that.
well, “waste” is a strong term…what I really mean is “way too expensive to make for the benefit they bring”. (2)/(3) is the only approach I’ve seen that is both “inexpensive” and provides at least some real value. Note that once you have generators for props, you could use the Fulcro component registry to “find all component” and auto-test them this way with a single function.
Full stack smoke tests can be very very useful, but they are a different thing altogether, and should probably only be written against things that are production stable (i.e. you won’t change much, but you’d like to know if you accidentally break them) because they are expensive to build and can break for random reasons…they create a lot of churn when done against rapidly-changing code.
The hot code reload abilities of CLJS and Fulcro make it quite easy to get most components “right” pretty rapidly, and tests on DOM stuff just mainly slow you down
For the casual reader, I will point out the most significant and important bit of all of that:
once you have generators for props, you can use the Fulcro component registry to "find all components" and auto-test them this way with a single function.
Everything related to UI is relatively new to me, I don't touch anything since 2008 I think..
I'm doing almost as you said, heavily using the workspaces to test and create my components, but instead of
malli as generators and validators form my forms and backend stuff.
I was missing something to ensure that all my components worked together and don't get any regression on the final application.
And seems that http://cypress.io is exactly what I was looking for.
I'll check it