I don't know about any library that doesn't use JS underneath. I would ask in #find-my-lib and in Zulip the SciCloj folks. Share where you get :)

Oh yeah, I fully understand that it'll ultimately be js under the hood, just prefer something with a clojure interface instead of making the interop calls myself. I'll ask around and try the ones I mentioned. Will share my decision in this thread.

Here's an article, a JS charting library article translated into Fulcro (hope that makes sense): https://medium.com/@cjmurphy?p=787d02281f7c.

We skipped oz and just use Vega

I don't really see what oz would provide for a natively web software. It makes it easy to see a chart from a clj process/repl, but the API is exactly on the same level as Vega itself, but often lags behind releases

That said, I'm not convinced that Vega is viable long term. The support/community seems really, really dead, or I haven't found the right place to ask for clarifications. We don't have a better option so far, though. It is powerful, if you get it to do what you want.

Interesting and sad. Thanks for sharing! I had hopes for vega :'(

Flipping awesome — thanks for making this! I love how simple you’ve made this!

Hey thanks a lot for your feedback it means a lot to me 🙂

Actors do not need to be singletons. Form would not work if they needed to be that. You can certainly invent a constant id for an entity, a user account almost certainly is not a Singleton. You only have one user ever for your app????

One user in app state yes, with the ident [:component/id ::panel/CurrentUser]. So that's the ident I'm wanting the RAD form to use. When in app state it does have an ::account/id, just not currently used in the ident. I could certainly change the ident, even though there will only be one. Of course on the server there are many!

That is an incorrect use of the Singleton concept. You need a top level KEY current-user that points to a normalized user, which in turn has a normal Ident with an ID element. RAD works perfectly with that with no modifications. You're inventing complexity that you don't need

Good point I'll go with that. Thanks.

Given what you've said, isn't this (from the book) a poor example?:

[ {[:current-user '_] (comp/get-query Person)} ]

it is not a singleton

that is a link query to a top-level edge of a normalized person...it is exactly what I was talking about in my first comment

A link query is a walk of a top-level edge to an arbitrary entity (that need not be a singleton).

A join on an ident whose ID can never vary would be s singleton: [{[:component/id :some-ui-thing-that-only-exists-once-ever] (comp/get-query ThatUIThing)}]

The database in question loads the current user, which has a distinct ID that can change (depending on who logged in). The db (normalized) would be {:person/id {some-real-id-that-changes-based-on-user {user props}} :current-user [:person/id some-real-id-that-changes-based-on-user]}

But if you, say, could impersonate another user (common support feature, for example), then :current-user could actually change during one run of the application.

to point to a different user

Brain fart. For some reason I started to think the LHS join key mattered for normalisation. If the join query inside another component has the RHS as (comp/get-query Person) then of course app state will have an ident at the LHS keyword. It doesn't matter whether that keyword (`:current-user`) is at the root (as here, indicated by [:current-user '_]) or actually part of the referring component.

Do you refresh dynamic queries in your shadow refresh hook? I mean https://github.com/fulcrologic/fulcro-rad-demo/blob/develop/src/shared/com/example/client.cljs#L45

no, thanks