Fork me on GitHub
#fulcro
<
2020-07-16
>
Eric Ihli13:07:54

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.

Jakub Holý (HolyJak)14:07:42

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?

tony.kay16:07:13

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?

Björn Ebbinghaus17:07:48

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…

tony.kay18:07:32

@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

tony.kay18:07:50

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

tony.kay18:07:46

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

tony.kay18:07:05

I’ve made numerous videos on approaches you could use to roll your own

tony.kay18:07:37

This is some work-in-progress I’m aware of: https://github.com/JJ-Atkinson/fulcro-subscriptions

mgxm20:07:38

Is there any repository/project that I can take look to see how to write components tests?

tony.kay21:07:16

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.

tony.kay21:07:12

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.

tony.kay21:07:33

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.

💯 3
tony.kay21:07:31

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

tony.kay21:07:41

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.

mgxm22:07:39

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 specs, using 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 Thank you.