This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-08-16
Channels
- # atom-editor (6)
- # babashka (31)
- # beginners (34)
- # calva (1)
- # cider (21)
- # clj-kondo (5)
- # cljsrn (2)
- # clojars (6)
- # clojure (35)
- # clojure-europe (3)
- # clojure-norway (2)
- # clojurescript (4)
- # conjure (10)
- # cursive (8)
- # data-science (78)
- # fulcro (23)
- # graphql (10)
- # helix (2)
- # luminus (1)
- # off-topic (50)
- # other-languages (1)
- # pathom (8)
- # re-frame (9)
- # reagent (9)
- # reitit (1)
- # rewrite-clj (6)
- # shadow-cljs (134)
- # tools-deps (53)
- # vscode (1)
- # xtdb (4)
ok, duplicate items are not fulcro's fault.. it's a pebcak situation: turns out I never considered result order when I switched to pathom's batch resolvers, so the state was never populated correctly to begin with. That being said, I think the union routers are quite a bit snappier and will probably keep them.
something that surprised me with the union routers is that each "screen" component needs an :initial-state
, since it's nil
unless explicitly set to {}
. Would it be reasonable to default to {}
? or any interest in a PR for the book to add a note to always set initial state on screens
initial state could infer a to-one or to-many (could be a vector of empty maps). Defaulting the wrong way would cause other weirdness. There is no good default, and sometimes you don’t need it, which would generate bloat. I would consider a dev-time warning, but i’m not sure how to prevent false-positives there
It is possible for one/many to be known. And at the same time I find it a big help for readability of components - instead of get-query
use get-one
or get-many
. Then can't default the wrong way.
so you’re right, we could add those helpers and have them augment query metadata, which would in turn enable more dev warnings as well.
I see that data targeting utilities such as appending idents, ensuring they are deduped, and so one, are all linear operations on vecs. Would it be interesting to rather imagine sorted sets sorting idents on information contained in their metadata? Reads would be slower I assume but it would allow for sublinear time for the common write operations other than appending (prepend, insert/remove from the middle, maintaining a sort order...)
I think that pushes the system even further into magic-land, and people already struggle enough with normalization. Having to look at “hidden” things to figure out why something works is not something I want “more of”
Realllllly long lists could certainly have optimized cases in those utils, and you can certainly add such a thing to your own app, but it doesn’t seem a fit for core.
It would simplify quite a few common things (I find deduping to be particularly important when working with normalized data)
This is a beginner question I have the rad-tutorial working fine locally but I am trying to figure out how to deploy with an uberjar - I created the jar (I think) with depster - I tried to invoke the app with java -cp fulcro-rad-tutorial.jar clojure.main fulcro-rad-tutorial/main/com/model.cljc - I am sure this is wrong but it seems the last argument contemplates a file such as core to run but I don’t see a main file. I have looked and haven’t seen easy instructions about how to deploy a Fulcro- rad App — Any suggestions?
Not sure if the demo has a "main" endpoint to use as a JAR
You need somehow call development/start
function from the jar.
that repo does not have a production entry point. See the Fulcro Template for what that would look like.
It seems to me that it would make more sense to do two deployment one for the frontend and a jar for the backend
If I click a button and it disappears does that mean my queries are set up incorrectly?
Props (and possibly computed) are all that determine what is rendered for a component. So debug those in the render function. Also use Fulcro Inspect to see what the props are, because all props come from app state.
You might be able to see what the mutation does to the app state using Fulcro Inspect. The queries really just determine the shape of your app state.
Hello I'm developing a "realworld" app: https://github.com/gothinkster/realworld using fulcro/pathom It's almost 100% complete. Still missing some mutations and somethings around comments. It's open for contributions/PR/issues 🙂 Any doubts DM me https://github.com/souenzzo/eql-realworld-example-app/