This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-06-14
Channels
- # announcements (2)
- # aws (12)
- # aws-lambda (5)
- # beginners (42)
- # calva (56)
- # cider (16)
- # clj-kondo (1)
- # cljs-dev (45)
- # cljsjs (1)
- # cljsrn (25)
- # clojure (171)
- # clojure-europe (3)
- # clojure-italy (16)
- # clojure-losangeles (2)
- # clojure-nl (49)
- # clojure-spec (2)
- # clojure-sweden (3)
- # clojure-uk (11)
- # clojurescript (84)
- # component (11)
- # core-async (12)
- # core-logic (2)
- # cursive (8)
- # datomic (41)
- # events (2)
- # fulcro (48)
- # graalvm (1)
- # graphql (1)
- # hoplon (12)
- # jackdaw (1)
- # jobs (1)
- # jobs-discuss (45)
- # joker (5)
- # keechma (10)
- # nyc (3)
- # off-topic (14)
- # pathom (16)
- # qa (1)
- # re-frame (22)
- # reagent (12)
- # reitit (4)
- # remote-jobs (1)
- # shadow-cljs (40)
- # spacemacs (3)
- # timbre (3)
- # tools-deps (29)
So good !
@uwo I think you might be misunderstanding something…lookup refs are a server concern. Using something like :account/id
as the id attribute of something is perfectly reasonable, and can just be the value (not the lookup ref from the server).
The entity on Fulcro would just be {:account/id some-uuid ...}
, and the form field would just be :account/id
the fact that relations in fulcro also use idents that look like lookup refs then “jsut work” when you get the diff on the server
alpha-7 is on clojars, and the template app has been updated to use the dynamic router and ui state machines…it’s still a bit messy and incomplete, but might be interesting as reading material
Today’s effort was mainly writing more code and fixing issues as I found them. UI state machines is better tested (it had issues), and dynamic routers have fewer required parameters on route targets.
In the case I had in mind, we have no need to store the entity on the client. The lookup ref would only be a value on form. This comes up lot for us: forms with fields for selecting domain entities that needn’t be stored on the client
@uwo So, form state should consider any non-join attribute as an opaque value, including those that look like idents. If that isn’t the case, then I would consider it a bug, and would certainly accept a patch.
The synergy of libraries in the new template is so beautiful. https://github.com/fulcrologic/fulcro3-template/blob/master/src/main/app/model/account.clj#L30 . ghostwheel is new to me. I'm going to use it.
@geraldodev Thanks…I’m still working on getting the error messages to be readable with ghostwheel…expound is great, but when I log with timbre it totally munges the thing into a string and messes up the formatting to be unreadable…quite maddening. I’m trying not to maintain my own logging code, but man I wish the ecosystem was a bit more stable with respect to sane error messages 😜
If you find a solution to that, I’d be interested, we experience the same thing. Maybe use tap>
to send down the nice expound ‘exception’ if it occurs instead of raising/etc. and attach a tap handler to print it to *out*
if it matches?
The problem happens when I need to catch exceptions to prevent logic problems (e.g. I have a try/catch because I’m calling user code), and I’m in cljc. I do (log/error e ...)
and timbre stringifies the js exception (which makes it an unreadable blob). I don’t want to code a solution at each call point, which means writing my own macro, which means maintaining my own logging code….a thing I was trying to get away from 😕
I haven’t had the time to dig deeper, but I probably will today just because it costs me sooooooooooo much time and frustration.
so the root of the problems stems from treating log messages as strings. I just read a blog post about an alternative logging library in cljs land: https://lambdaisland.com/blog/2019-06-10-goog-log here log objects are serialized to strings via dynamically adjustable handlers, which could in theory pprint expound exceptions
sure, it would be nice to solve this at timbre level so expound users won’t feel the pain
that’s where Om Next started….didn’t work well for what you just said: you have to maintain your own logging lib. Not doing it if I can avoid it. Timbre is quite good’
I’m interested, we are currently using clojure.tools.logging on server-side. If we can’t fix that with your workaround we’ll definitely switch over to Timbre. Keeping 👀s on the next alpha release 🙂
Yeah, this is going to fix it…simply overriding :output-fn
with a more complicated thing…working on it
Call to com.fulcrologic.fulcro.ui-state-machines/alias-value did not conform to spec:
<filename missing>:<line number missing>
-- Spec failed --------------------
Return value
false
should satisfy
nil?
-------------------------
Detected 1 error
(log/merge-config! {:output-fn (fn [{:keys [vargs level ?err ?ns-str ?line] :as data}]
(if (instance? ExceptionInfo ?err)
(js/console.log (ex-message ?err))
(log/default-output-fn data)))})
Is it possible to use form validation when your fields aren’t like ::name
and are :name
?
I suppose the alternative is I can pass a spec ns to the get-spec-validity fn rather than a field name
For those out there struggling with cljs error messages as I have been, the result I just got is so heartening that I thought I’d pull it out of the thread. If you’re using timbre you can override the output function and detect all sorts of things abt the error. I’m using ghostwheel/epound and the errors were just globs of crap…I just added this to my dev preload file:
(log/merge-config! {:output-fn (fn [{:keys [vargs level ?err ?ns-str ?line] :as data}]
(if (instance? ExceptionInfo ?err)
(js/console.log (ex-message ?err))
(log/default-output-fn data)))})
and went from 60kb unreadable spec error messages to messages more like this:
Call to com.fulcrologic.fulcro.ui-state-machines/alias-value did not conform to spec:
<filename missing>:<line number missing>
-- Spec failed --------------------
Return value
false
should satisfy
nil?
-------------------------
Detected 1 error
(expound does the real heavy lifting, but without a custom output fn it just gets tangled up i nthe middle of an unreadable mess of other things and stack trace)
going to refine that…I still want the stack trace and such…but I want that to be the last thing output so that the I don’t have to scroll to see the most important info.
@njj form validation is completely customizable..you can do what you want. If you mean “does form state currently have something to make non-spec keywords work with namespaced specs?” the answer is “no”
On the logging…I guess technically this should be an appender with a custom output fn…this is supposed to convert it to a string, but I don’t want string conversion…raw output to js/console.log is what I want…so, not technically a correct way to configure it, but it is for development cljs only anyhow
Here’s what I ended up with so far for fixing the logging…any further changes will appear in the preload on the template: https://github.com/fulcrologic/fulcro3-template/blob/master/src/main/app/development_preload.cljs This is working pretty well for me.
I changed my mind…these support functions are now in Fulcro itself: https://github.com/fulcrologic/fulcro3/blob/develop/src/main/com/fulcrologic/fulcro/algorithms/timbre_support.cljs
Wrote a new Intro chapter in the book today. Anyone caring to comment/proofread/learn/make-fun-of 😜 : https://github.com/fulcrologic/fulcro-developer-guide/blob/master/DevelopersGuide.adoc#fulcro-from-10000-feet
I started exploring fulcro recently and this helps a lot, thank you! Btw, do you have any good tips for an introductory book or article about graph theory?
Glad to hear it. I do not have any book recommends. The graphs we’re using in Fulcro probably don’t need much in the way of textbooks to understand…just nodes and edges connected in whatever way makes sense for your application.
Thank you for the reply! It’s really nice to get confirmation that everything is designed to be so approachable. Cheers