This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-09-30
Channels
- # ai (3)
- # beginners (86)
- # boot (3)
- # chestnut (1)
- # cider (29)
- # clara (2)
- # cljs-dev (18)
- # cljsrn (1)
- # clojure (104)
- # clojure-greece (3)
- # clojure-losangeles (1)
- # clojure-spec (2)
- # clojure-uk (1)
- # clojurescript (5)
- # core-async (5)
- # css (3)
- # emacs (3)
- # figwheel (7)
- # fulcro (60)
- # lein-figwheel (3)
- # luminus (4)
- # off-topic (7)
- # portkey (14)
- # reagent (12)
- # rum (1)
- # shadow-cljs (9)
@tony.kay I'm trying out the defsc
macro now, is there a way to use the params of initial-state
there?
humm, I noticed you validate the props
vs query
, can we disable the validation when there is no query? I'm having an UI component that I only need the CSS part, no query or ident
https://fulcrologic.github.io/fulcro/guide.html#!/fulcro_devguide.M05_More_Concise_UI
humm, I see
but I would actually just want to use the params
attribute as my params (pass though)
yeah, it's just for flexibility, I like to enable the parent to set the params of children as it likes
so I can do chances from a higher place
doing the map seems kind of a filter, I prefer to let it flow
The main goal of defsc was to reduce accidental common errors: forgetting to destructure something from props, or forgetting to query for it…or not giving an ident.
it's like this:
Yeah, it’s just not meant to work that way. If you want to use defui you can use it that way, but defsc is trying to error check things
gotcha, ok, but can we consider that other use case? I loved it to being a sugar to define layout components that only need CSS
you think would be an issue to ignore validations in case there is no query?
spell it out a bit more for me. You’re wanting a layout component that sits in the tree, provides CSS, but does not participate in the query. Why don’t you just go around it with the initial state, like you do with the query?
because I like to use css classes with it, and have those namespaced
no initial state here, hehe, I'm talking for a different one 🙂
this is the case:
(fulcro/defsc Box
[_ {:keys [title]} _ children]
{:css [[:.container box-container]
[:.header box-head-title]
[:.hr box-hr]]}
(let [css (css/get-classnames Box)]
(apply dom/div #js {:className (:container css)}
(if title (dom/div #js {:className (:header css)} title))
(if title (dom/hr #js {:className (:hr css)}))
children)))
the problem is that it's trying to validate the title
prop, trying to match with the query
and raising an exception, because it's not there
then comes my question: can we ignore the prop validation when there is no query?
probably. again, it then makes it a misnomer, since it was really meant for building error-checked stateful components
humm, ok, maybe I'm looking it wrong, I was thinking it as a sugar for common cases, but maybe this is not one of those
no, I was getting tired of forgetting of querying for something that I destructured, or making a typo, etc. Happens all the time with defui
defsc
is about making it possible to destructure and error check the props against query + props destructure + initial state
cool, in one of my components I used it, quite cool, the others I can just still doing the old fashion
yep…that’s it’s job. You are destructuring title, but you didn’t query for it. Non-queried things should come through computed in a stateful component
why not having one that deals with all, just being smart about it?
because swiss army knives like that are unstable. We already have defui
which is completely general
yeah, makes sense
yeah, I have some snippets that make using it pretty fast and ease
but for the very common case of a stateful component, defsc
helps ease errors because it eliminates duplication and error checks the common problems
I don’t love that it creates two ways of doing things. I would love a single thing that just works…but in my judgement defui
is the better general-purpose syntax. It looks like defrecord
et al.
one (I think you did in fact) could argue that creating defsc
is not the best of ideas in a library because it is special purpose sugar
but in practice, I think it brings a benefit that outweighs the feature creep feel of it
as soon as we start making it “morph” how it works based on what is supplied, it loses a lot of that value and I no longer want it in the lib 😜
Ideally, we’d write a defui parser that would error-check the way defsc
does. But that is a hard problem. Some people don’t destructure props, they just access them, often through an intermediate binding. Etc.
I’m releasing beta11 now. I plan on checking for issues over the weekend, and cutting 1.0.0 officially on Monday
just noticed css-merge
has been removed in https://github.com/fulcrologic/fulcro-css/commit/f99228ba88d7bdb4bae7089d7977a32fa369c5a5
what is the thinking behind that?