Fork me on GitHub

Are there charting libraries that work well with Fulcro? I'm making progress with D3 but the API seems too low-level and complex for my foreseeable needs. I was looking at - looks nice, but it's purely JS and I'd prefer to avoid the JS interop syntax if possible. Others that have been suggested: •

Jakub Holý (HolyJak)16:10:10

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):

❤️ 1

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.

Jakub Holý (HolyJak)21:10:19

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


Hey I was studying fulcro/pathom and decided to create a frontend only app that could be deployed on Github Pages and read my pages and blog posts directly from markdown files. Keep in mind this is a frontend made by a "mostly" backender learning fulcro, but I hope It helps or inspire someone eagering for something like this. If you want a preview of it running in gh-pages

👏 6

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 🙂


The RAD defsc-form macro creates a defsc that has an ident based on the :com.fulcrologic.rad.form/id it is given. But I want a form that's based on an app state entity that's a singleton. For background: the entity is a user account that's used as an actor in a UISM (actors need to be singletons), and there's only ever going to be one of them. My decision here would be to not muck with RAD (would have to alter the macro), but just create a normal Fulcro Form here. Just wondering if that's the best decision??


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.

👍 1

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

[ {[:current-user '_] (comp/get-query Person)} ]
A link query is a singleton. You are essentially saying that any entity with a proper id should always be referred to in a normalised way (by its ident of the form [entity/id id]). Here Person has a :person/id attribute that isn't being used, in the same way that I skipped using the ::account/id.


it is not a singleton


that is a link query to a top-level edge of a normalized 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.

💡 1

I have a reloading related question. I have noticed that when I add a column to a report definition, in ro/columns , the visual column is added, but it doesn’t get added to load query unless I hard reload the whole page. is there a workaround for this?