This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-09-30
Channels
- # aleph (1)
- # announcements (7)
- # aws (4)
- # beginners (52)
- # calva (11)
- # cider (20)
- # clj-kondo (36)
- # clojure (53)
- # clojure-austin (1)
- # clojure-brasil (1)
- # clojure-conj (1)
- # clojure-europe (27)
- # clojure-italy (17)
- # clojure-nl (11)
- # clojure-norway (2)
- # clojure-spec (41)
- # clojure-uk (39)
- # clojuredesign-podcast (2)
- # clojurescript (22)
- # clojutre (14)
- # community-development (24)
- # cursive (6)
- # data-science (1)
- # datomic (38)
- # duct (3)
- # figwheel-main (8)
- # fulcro (34)
- # funcool (8)
- # jackdaw (3)
- # jobs (2)
- # off-topic (84)
- # pathom (3)
- # re-frame (4)
- # shadow-cljs (8)
- # tools-deps (5)
- # vim (7)
If I define a button component like so:
(defn button [props & children]
[:button {:type props} children])
And then render the button like so
[button {:type "button"} "Button"]
The rendered HTML is type="[object Object]"
- what am I doing wrong?because you are passing {:type "button"}
as a props into component. this end up with {:type {:type "button"}}
and then renderer converting provided type into string. in JS world trying to stringify object will give you that string "[object Object]"
(assoc props) ;; => props
if you are making a component that is using props passed as an argument - you can leave it as is: (defn button [props & children] [:button props children])
but I can not see any reason to do that)
Quick question: is it idiomatic to use a map as first argument of remove? Like this:
(remove {:foo 42 :bar 50} [:foo :hello :bar]) ;; => (:hello)
I thought it was, but clj-kondo highlights that as an error
this is idiomatic since map is a function in clojure: ({:foo 1} :foo) ;; => 1
I was thinking, now that I've finally internalized that sets and maps are functions in clojure, I'm trying to shoe horn them everywhere š
huh wait, I don't get a false positive with this:
$ clj-kondo --lint - <<< '(remove {:a 1} [:a :b])'
linting took 25ms, errors: 0, warnings: 0
clj-kondo --lint - <<< '(defn crawler [url results] (let [data {:foo 42} results (assoc results url data)] (if (seq data) (let [links (remove results (:links data))] (reduce (fn [results url] (if-not (get results url) (crawler url results) results)) results links)) results)))'
I do get
<stdin>:1:119: error: Expected: function, received: associative collection.
linting took 9ms, errors: 1, warnings: 0
Yes indeed. Also, I'm in the middle of watching your recent talk and decided to install clj-kondo before even finishing. So far it's great!
Cool! I made an issue here: https://github.com/borkdude/clj-kondo/issues/479 It will be fixed in the next release, I'm pretty sure.
If you're interested in a binary with a fix, let me know. You can also build it yourself from master.
hey, design question, should my repository namespace validate ( using spec ) the params which is going to DB or service layer should do that ?
Personally I would do it as close to the storage for which you're validating as possible. If possible even inside the db itself.
yeah, sometimes I think to validate on my system boundaries ( http handler ) , other on database layer assuming that my code ( service layer ) gonna produce the proper data to be inserted
@borkdude so your http handler do not validate nothing ? you pass to database namespace to handle ?
That could also work. You can also validate extra stuff only in dev, just to get some extra sense of what's going on
We do validate/coerce incoming data from http. For storing fields to a SQL db we use HugSQL which errors on absent keys, for jsonb blobs I usually do a select-keys to ensure no extra crap gets saved beyond what I'm interested in
On the DB level we have non-nillable fields which also protects you from stupid errors.
I think I had some extra spec checking on the DB level just to ensure things didn't break when I changed anything to my code. But that's turned off in prod
yeah, agree 100% with you .. first time I wrote I had spec on every function, currently Iām conforming/coercing only on http handlers . everything inside Iām leaving without spec ( but yeah, sometimes Iām falling on stupid errors as you said )
from a security perspective: always be validating. i.e. validate at all system (component) boundaries. firstly, the schema of the data provided via http is not always the same as what the db wants. so the validation won't be checking for the same things. if you don't validate both schemas... schema ambiguities/mismatches are where encoding/injection bugs breed. another reason to validate multiple times, is the often false assumption that data will only come from a specific source, like http. i've been bitten by that a few times. e.g. adding a plugin framework to a system bypasses the http api and its validation. now there's a new vector for injecting invalid and unvalidated data into the system. validation at the db would help in that case, but i would still think that's not quite enough. tl;dr: data crossing all boundaries should ideally be validated
Hey, whats the most used clojure lib for building a desktop gui? I'm not looking to get into anything crazy, just need a directory input, a file input, and a button that will work on linux and window 7/10
three popular gui options are cljs with react in electron, clojure with seesaw (swing), and clojure with fnfx (javafx)
I think there might be another good javafx option but the name isn't coming ot me
aha, that's the other one, thanks
@noisesmith @borkdude thanks guys, I'll check them out
I just defined a tuple entity in datomic. I'm using the free on-memory spec
{:db/ident :dados/external-id-name
:db/valueType :db.type/tuple
:db/tupleAttrs [:dados/external-id :dados/name]
:db/cardinality :db.cardinality/one
:db/unique :db.unique/value}
but when I transact to database I got an :db.error/not-an-entity Unable to resolve entity: :db/tupleAttrs
There is a #datomic channel that might have more participants able to help you with questions on Datomic.
thanks @andy.fingerhut I will post it there.