This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aleph (14)
- # announcements (2)
- # babashka (8)
- # bangalore-clj (2)
- # beginners (66)
- # calva (8)
- # cider (1)
- # clj-kondo (24)
- # cljdoc (3)
- # cljs-dev (3)
- # cljsrn (2)
- # clojure (197)
- # clojure-europe (1)
- # clojure-india (5)
- # clojure-italy (4)
- # clojure-nl (27)
- # clojure-uk (18)
- # clojurescript (56)
- # code-reviews (19)
- # core-async (86)
- # cursive (16)
- # data-science (1)
- # datomic (16)
- # docker (3)
- # events (1)
- # fulcro (101)
- # graalvm (10)
- # graphql (16)
- # jobs (1)
- # jobs-discuss (6)
- # kaocha (4)
- # luminus (1)
- # off-topic (99)
- # onyx (3)
- # pathom (9)
- # planck (2)
- # re-frame (8)
- # reagent (3)
- # reitit (3)
- # remote-jobs (3)
- # shadow-cljs (21)
- # test-check (3)
- # tools-deps (21)
- # vim (16)
@mdhaney there was some discussion of workarounds for that transit conflict at https://clojurians-log.clojureverse.org/fulcro/2019-12-27
I have a quick patch working now. I’ll submit a PR and you can take a look and let me know if you can think of a better approach, but at least this is working.
@mruzekw I use Fulcro for many reasons, too many to list here. But one of them is the option to use EQL via Pathom over the wire instead of JSON via GraphQL. This one thing made it possible for me to create an autogenerated API endpoint for 30 or so complex tables in a day vs days and days of intricate schema building and input parsing. Ugh.
(= (+ Fulcro Pathom Datomic) winning) in so many ways for me. Your mileage may vary. As for spotty internet handling, that’s more of an app concern that I don’t think Fulcro handles for you. It could be added as a plugin to the network layer pretty easily. I will eventually need to do that, but I’ve done that in various ways over the years and I see that as a nice thing to have in the box, but not a deal breaker. The original primary raison d’être of Fulcro’s predecessor Om.Next was to have graph query UI system that integrates nicely with Datomic’s pull syntax. So if you’re using Datomic it’s a no brainer. If not, hmm, I just can’t say because I haven’t done that.
I was just curious how it measured up feature-wise. I love CLJ(S) for its simplicity and beauty. And I love the model Fulcro employs, but I noticed how similar it seemed to Relay
There are some great talks by David Nolen back around the time he started it on YouTube in which he discusses the design philosophy
Why are you considering CLJS + Fulcro vs JS + Relay? Let’s assume the features were more or less equal.
Yes EQL is very similar to datomic pull syntax with the exception primarily of mutations
Yeah I mean honestly, if you’re kind of 50/50 on the tech, then the team building is a huge factor. This was a major stumbling block for a project I worked that couldn’t afford good quality CLJ talent, and wanted to hire cheap foreign JS devs. It’s a real issue
Indeed. I know the moment we want to bring on paid devs, it will likely be steeper than the JS alternative
possibly, but generally worth it. You get what you pay for. I think if you can pay a decent living wage, then it’s not a big difference, and CLJ is worth it. There are countless testimonials. But if you’re looking for the cheapest of the cheap labor, nothing beats JS for that.
You make a good point. I love the Clojure community and photography, so maybe it’s worth paying for that
You don’t come to and stay with a language like Clojure without some good deal of thought and convincing
We should’ve started a thread way back there. Yeah for me it’s really a bunch of synergistic things. There are individual things I like about other options, but when I add them all up, Clojure wins big time. And really, one of the big things is being able to leverage Java and JS things too.
Simplicity, design ethos, immutable data, data-oriented, rich extensible data format (this is big for me)
It will likely be on AWS. It will be a video hosting service, so UI and transcoding pipelines for that
My project is for non-profits and I’ll move to Cloud when/if it’s making enough money to justify. In the mean time it’ll run on a little DigitalOcean droplet
I haven’t done a side-by-side comparison, but I’m pretty sure using webpack you can get a smaller JS executable
You can do a double build with webpack and CLJS but then you have more issues with externs.
I just use shadow-cljs and it handles NPM stuff, but I’m pretty sure it doesn’t get as small because it doesn’t do tree-shaking of the NPM stuff
Right, as far as I know, there is no tree shaking except for the closure libs and the app code
yeah, that said, doing SSR with loadable modules and sending over a pre-rendered page with a small JS file and data is totally doable. I’ve rolled this custom myself in the past.
Did you need to write the Pathom resolvers manually? Or is there an automated alternative?
Yes, I set up 2 pathom resolvers, one for idents, and one for general table lookups for ~30 tables that I migrated from MySQL to Datomic. I use my own spec file to describe all of the tables and columns (entities and attributes in Datomic parlance)
I’m thinking of something like generated GraphQL resolvers with something like AppSync or Hasura
Here are my resolvers: https://github.com/thosmos/riverdb/blob/master/src/server/riverdb/api/resolvers.clj
glad to be working on something I can share. Much of my work over the years has been closed source
I just pushed my latest changes. I will probably change the lookup-resolver to build on the map-form of Datomic query. instead of the vector form. I’m surprised it’s worked so far, but can be a little hard to parse what’s going on.
I also use this little library i made to convert the specs into various things like Datomic schema, datascript schema, etc: https://github.com/thosmos/domain-spec
The idea of having just two resolvers for pretty good base API from Datomic, Pathom, and Fulcro seems like something worth sharing
I will … there’s a lot I’m doing in the app that I think is innovative 😉 hehe and yes planning to write about it
oops, not latest, this one: https://code.thosmos.com/posts/2019-12-04-spec-driven-ui.html
that was written before I made the leap from react + JS + graphql <-> lacinia + datomic to Fulcro + Pathom + EQL <-> datomic. I’m so much happier now!
yes I think so, even though I’ve built my own replacements for some of what react-admin provided
I think the crux of my decision is based on my design goal of using my domain specs to generate as much as possible. so now I have one list component that can be used for all the different tables, one dropdown lookup for references to joined entities, etc
Yeah it makes doing a bunch of similar CRUD stuff so much more realizable in a relatively short time. The universal list is in this file: https://github.com/thosmos/riverdb/blob/master/src/main/riverdb/ui/theta.cljs
Hello, I have two dynamic routers, one inside the other (composed) but I can't get it to work, I always get
couldn't find route target for new-route Any help please?
@sifou the book covers everything I can think to say…you have route-segments? You composed in initial state?
There is really only one primary incantation in Fulcro: Make sure query/ident/initial-state are right (the latter is for initial startup state).
from there everything is an API you could write yourself. Dynamic routing is just one way you could move around in the app, and it’s API is one of 3 included.