This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-01-23
Channels
- # aws-lambda (5)
- # beginners (212)
- # boot (3)
- # cider (130)
- # cljs-dev (24)
- # clojars (2)
- # clojure (287)
- # clojure-dusseldorf (23)
- # clojure-italy (11)
- # clojure-russia (10)
- # clojure-spec (9)
- # clojure-uk (45)
- # clojurescript (59)
- # core-async (1)
- # cursive (13)
- # datascript (1)
- # datomic (46)
- # emacs (12)
- # events (9)
- # fulcro (196)
- # graphql (3)
- # hoplon (79)
- # jobs (5)
- # jobs-discuss (7)
- # jobs-rus (2)
- # keechma (26)
- # keyboards (9)
- # leiningen (2)
- # luminus (9)
- # off-topic (20)
- # om-next (1)
- # onyx (15)
- # re-frame (16)
- # reagent (18)
- # reitit (1)
- # remote-jobs (2)
- # rum (3)
- # shadow-cljs (13)
- # sql (135)
- # unrepl (46)
- # vim (1)
- # yada (23)
oh i see, thanks
also, i noticed the routers (vial trial and error) the routers and the keywords they use to key screens have a sort of naming convention
it looks like the router screen keys have to be the name of the route plus a suffix that matches the router name
otherwise i kept getting an unknown route message on the screen
like this example here http://book.fulcrologic.com/#_a_complete_ui_routing_example
:status-report
has to have -report
at the end to work
is that expected or am i just crazy? 😅
i was able to rename :status-report
to :summary-dashboard
but i had to rename the router as well
so, when you change the name of the route, the ident function has to be updated to generate the correct ident to match
Did you watch this old video: https://www.youtube.com/watch?v=j-_itpXEo6w&list=PLVi9lDx-4C_T_gsmBQ_2gztvk6h_Usw6R&index=12
it’s on Untangled, but it explains how you can use unions to do routing…the current routing implementation is based upon this.
so in that example in the book, i could just change all the instances of :status-report
to :foobar
and nothing else and it would work?
i’ll watch that video, thanks for helping 😄
I came across this looking at the state of Fulcro Template, seeing a field join in the table :main
, that was not an ident but a map.
:main {:page {:id :main, :current-user {:uid 2, :name "Joe", :email "<mailto:[email protected]|[email protected]>", :password "letmein"}}},
I think so too (now) - it s/not be there but it is. I was thinking it s/be an ident. But there's no need for a field if it is a link, I think.
Good idea if that state map-entry for the :main table looks wrong to you. A denormalized :current-user. Why is it there? I haven't altered any code, except putting (get-state)
in cljs.user.
Every user.cljs has a dump of some sort to see the state, just looking at the state.
ok…well, I’m not sure what is going wrong for you then. The state is correct on a pristine template when looking at it via Fulcro Inspect.
So, you are claiming that you start a pristine template, load the page, log in, and see that state?
@currentoor making sense of routers?
the server state runs the link queries, then normalizes the tree…but there is no user query so it ends up being there
instead of sending a tree as initial state, send the normalized db…and install it as an atom instead of as a plain map
yes, this is all data generated by the server…server makes normdb -> mutations -> tree -> render + initial state
it currently sends the tree as initial state (because that is easier when writing the code to work either way)…but it could just as easily send the normdb instead
I can see the refresh after logging in is causing the problem, regardless of the colon.
yeah, it isn’t much code, but I’d have to step through it carefully to figure out where to change it.
feel free to fix the SSR if you want and send a PR…I’m not really worried about it to derail other things to fix it
Hey — I’m looking for the sources of the book but couldn’t easily find them in the repo… Anyone have a pointer for me? 🙂
@martinklepsch Think it's in the main repo. https://github.com/fulcrologic/fulcro/tree/develop/src/book
Hm. I meant like the source text files (asciidoc I guess?) not the sources for the examples
yes! thanks, tomatoes on my eyes it seems 🙃
@martinklepsch I had trouble finding the source of the book too
Maybe that should be more discoverable?
what about having a badge to "fork me on github" linking to the source?
that would be very discoverable
remember that your URL is localhost
with some port…so different apps that you play with that use the same URL can cause all sorts of fun
@thosmos tip: use .
domains to avoid cross local site caching, if you use anything .
it will point to localhost, examples:
... this way you can keep site resources separated (local cache, cookies, url history...) even though they will be all in localhost
effectively
@wilkerlucio oh wow, first time I've heard that! thanks!
no problem, happy to help 🙂
is an intention with inspect that you will eventually be able to edit state values and have the UI update?
not planned, but sounds like an interesting feature, you wanna open a issue?
interesting, I had not though about enabling adhoc transactions, but seems cool, and easy to implement
for example, slide db history back a few steps, edit code (hot code reload), re-interact
I'm opening a issue for that 😛
@tony.kay for what you are talking, I have a slightly bigger idea, that would be "process recording"
after we have snapshots, that would be the next level, we record a initial db and interactions, and replay from that
yup, we are finding many ways to say the same thing, hehe 🙂
@thosmos about the error, I remember an error similar to that in past, are you using the latest inspect?
beause I think that issue was fixed
the latest is -alpha4
@wilkerlucio i’m on -alpha4
and i can confirm that i also see that error, despite everything appearing to work fine otherwise
thanks, we might have to check again, I remember something like that was happening before because the process of init app state was triggering a mutation before the app was initialized, causing it to don't find the app
but maybe this is something different
yeah, that was the problem before, app wasn't ready to take the transactions
app id should never be nil, if user don't provie the inspect will generate one
I could find out by trying it (and am doing that now) but is there harm in starting the figwheel and main server at the same time in intellij?
or should I start one or the other and wait?
I know I should be able to deduce this from the excellent docs, but a bit uncertain about a good workflow for building a learning project that stores pets and their preferred foods in an actual datomic Starter database.
what I'm imagining as a possibility is that I run 'lein new fulcro favefoods', then build up the Pet, PetList, Food, and FoodList components via defsc and then their factories; add the Root element; add the ui-pet-list and ui-food-list to the Root; enable a server; figure out how to get the pets and their favorite foods to store in an in-memory Datomic database on a server; then move the in-memory database to, say, a PostgreSQL backed Datomic instance.
If I could click on a pet, see their favorite foods, be able to add a favorite food and have it stored in the database, as well as click on a food and edit it, I'd have a great start on being able to build apps with Fulcro.
does this sound reasonable? I'm totally unsure how devcards play into this scenario... do you start these things there and graduate them to something else, or do you morph the devcards into the final product, or something else?
@macrobartfast: All I can say is that from experience I know I'm gonna use devcards a lot more in the future. Perhaps first up your big application could be done just using initial state, client only. Your components would not even need to display what they have as at this stage you are just making sure that state is correct. Then put in buttons for your state changes. If you need a server at this stage just make one that serves static/example data. Then concentrate on one component at a time by having a devcard for it. Here your render method would start to have more than just buttons, and you would be concentrating on the css. Once you have a nice working demo application introduce the server and more realistic data.
ok, pondering all that... thanks!
is there a way to add a set of default entries to a table and still use the initial app state collocated protocol?
i have a :widget/by-id
table and it has a number default widgets already built in, and now i’m porting the app over to use the collocated initial app state stuff
i suppose i could just assoc
the default stuff in on a post initial load mutation? is that a bad approach?