are you struggling to compose UI components? Electric's main primitive is a lambda (e/fn), which should compose out of the box. re forms with validations - we don't have demos to show here yet as most of these were client specific. Using an atom per field works for field-level validation, you could also use an atom per form for form-level validation

yes I'm really enjoying being able to compose UI with functions. I'm trying to figure out routing at the moment which I've heard folks use reitit for. If anyone has a minimal routing example I'd like to see it

Also for managing app data is it best practice to use atoms scattered around? Or a client-side app db? Or is it recommended to use a streaming database and be reactive on the server-side db?

if you search in:#hyperfiddle reitit there's a setup from @U050CJFRU and @U06B8J0AJ

there is no best practice, all of it works. Depends on your requirements really. Do you need data to stay on the client? Do you need it to survive machine restarts? Should the data be visible across multiple tabs? Multiple devices? Multiple users?

I suspected that might be your answer 😅 guess I'll need to experiment. Thanks for the help!

haha sorry!

Need persistence so will need a server side db

I'm excited to try out Rama, but planning to use it for a hobby project first

yeah, electric should work great with rama. Once differential electric lands it will fit like a glove

given enough resources (money, time) I'd build an electric IDE with many more features... Well, pulling my head back from the clouds, maybe one could extend clj-kondo or tree-sitter to get some functionality. I also wrote a https://gitlab.com/xificurC/hf-electric.el/-/blob/master/hf-electric.el?ref_type=heads for emacs to add a colored background to client/server code. To programmatically prevent leaks one can hold secrets in a non-transferable value, something like

(ns secret)
(deftype Secret [v])
(defn seal [v] (Secret. v))
(defn open [s] (.-v ^Secret s))

(e/server
  (let [secret (secret/seal "hunter2")]
    (e/client secret))) ; <- one will see a transfer warning and receive nil

ah, very clever!

yeah and now that I think about it a bit more, it isn't clear statically (without compilation, at least) where transfers happen

our analyzer infers transfer points without compilation. In theory the analyzer could in the future provide the analysis information through some API. Not on the roadmap

if this is important to you, wrap secrets in a deftype and do not install a serializer for the deftype

or write secret processing code in a .clj file

you can use e/discard for now, the difference is only interesting outside of electric. At the missionary layer e/discard is a flow of nils whereas e/inhibit is a flow that only emits a single nil

Ah, interesting, thanks for the explanation.

e/inhibit is not useful in electric v2

Gotcha. Is it actively harmful?

or v3 either, it's a temporary utility for a client project that pulls forward some differential stuff into electric v2

Nice, this caught my eye just yesterday as well. Have to remind myself that alpha means API will change a lot.