Is this the correct pattern to use to define an element that takes children?
(e/defn Border [Content]
(dom/div
(dom/props {:style {:border-width "1px"}})
(Content)))
(Border
(e/fn []
(dom/p (dom/text "one"))
(dom/p (dom/text "two"))))
;=>
<div style="border-width: 1px;">
<p>one</p>
<p>two</p>
</div>yes
you can write a trivial macro to encapsulate the boilerplate, we do this so often that we should probably figure out a macro syntax to define container components like this, i dont think we've thought much about it yet
With v3, I’ve been getting “Method code too large” errors in production builds. The error message often points at a very small function, and the actual problem seems to be with a caller of the function, or even a caller of the caller. Up until yesterday, I’ve managed to make the errors go away by splitting functions into pieces. The problem got much worse for me yesterday, and I’ve noticed that there was a new release a couple of days ago that I’m guessing is the reason. See thread for a small reproduction of the problem.
I’m happy to create a Git repo to demonstrate this — please let me know if you would like me to do that — but perhaps it’s easier just to give the following instructions…
1. Clone the starter app.
2. Replace the electric-starter-app.main namespace with the code given below.
3. Add the my-namespace app with the code given below.
4. Do a production build. This gives me a “Method code too large” error. The error message points at an Electric function that has an empty body. (I get this with a Docker build where everything is clean, as well as with a “normal” build.)
The comments in my-namespace describe ways to make the problem go away by deleting code.
So, just to pull things out from those comments, I have three ways to make the problem go away:
1. Delete the attr-map in the namespace declaration.
2. Delete Unused-function.
3. Delete one line from the body of Unused-function.
thanks for the report Simon, we'll take a look and keep you posted
Ah, if I remove attr-maps from all namespace declarations in my real code the problem goes away.
is that electric specific then?
Ah, good question. IDK. A quick google hasn’t shown up anyone else with the same issue. I’m not blocked, because I can remove attr-maps temporarily for a prod build. I will try reproducing with a non-Electric project, but maybe not very soon.
Has anybody used clojure-mcp with Electric? If yes: What are your experiences and what is your workflow / prompt to make it a smooth experience? I gave it a try, but I wasn’t able to produce good results, yet. It seems that clojure-mcp struggles with hot-code-reloading and the fact it cannot use electric functions in the repl to evaluate something.
I just thought I’d share what I’ve been building with Electric — a timeline of Ancient Greece. It’s not really the kind of app that Electric is aimed at, but I enjoy using Electric and it definitely works for this. :-) Thanks everyone for all the help answering my questions! https://timelines.nomistech.com/ Needs to be on a reasonable-sized screen — not a phone.
Can I see the complete source code of your app @nomiskatz there are some basic things I'd like to check
@dustingetz I’ve added you as a collaborator. Just trying to work out how to make it read-only…
Ah, “In a private repository, repository owners can only grant write access to collaborators.”
So I’ll leave it like that.
You should get an invite from GitHub.
Simon can you add @ggaillard ggeoffrey and @xifi xificurC to the repo pls
I’ve added ggeoffrey but can’t find xificurC.
Done. I think there might have been a glitch at GitHub.
I received and accepted the invite. Thank you Simon, we will take a look.
Out of interest, is this about the prod build issue I was having, or about whether the app can be improved (more responsive, whatever)?
FWIW, in Emacs, if you want to make some of the clj-kondo annotations go away, take a look at the minor mode at https://github.com/simon-katz/nomis-public-dev-setup/blob/master/emacs-configuration/emacs-installation/emacs-init-files/nomis-replace-text.el
we are interested in performance, it is an active priority
Very cool. Probably serves as a good example for performance optimization work.
this is very cool
The bidirectional interactivity (e.g. "autoscroll chart to hovered item") is exactly the kind of UX that is normally a pain to build.
Definitely some rendering jank on my side. Would be an interesting exercise to see what it would take to make that go away.
We certainly want this to be fast in Electric, the rendering pauses are probably the same e/for flaw that we're working on
Great UX all around.