This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-10-04
Channels
- # aleph (2)
- # beginners (80)
- # boot (18)
- # cider (6)
- # cljs-dev (14)
- # cljsrn (5)
- # clojure (114)
- # clojure-android (5)
- # clojure-dev (8)
- # clojure-greece (6)
- # clojure-italy (9)
- # clojure-russia (108)
- # clojure-uk (82)
- # clojurescript (158)
- # css (1)
- # cursive (21)
- # data-science (1)
- # datomic (66)
- # emacs (9)
- # ethereum (3)
- # fulcro (26)
- # graphql (7)
- # hoplon (25)
- # juxt (2)
- # keechma (34)
- # lein-figwheel (4)
- # leiningen (2)
- # off-topic (4)
- # om (5)
- # onyx (14)
- # parinfer (2)
- # pedestal (17)
- # planck (3)
- # portkey (14)
- # re-frame (23)
- # reagent (12)
- # ring (8)
- # rum (1)
- # shadow-cljs (506)
- # spacemacs (2)
- # vim (11)
- # yada (6)
I learned emacs, java, linux and LaTeX at the same time and only b/c clicking on a text file in redhat 5.2 opened up emacs by default.
What do vim users (or really users of any non Emacs editors) do to configure indentation of macros usage?
@cddr vim-clojure-static (bundled with vim) has options like g:clojure_fuzzy_indent_patterns = ['^with', '^def', '^let']
and g:clojure_special_indent_words
https://github.com/guns/vim-clojure-static readme is instructive
If you want to not fight with emacs users, you should also set let g:clojure_align_subforms = 1
I haven't done this yet, becuase I will eventually conquer the emacs foes. I also think it's far more sane of a default.
> The later one in particular now means that ClojureScript has a dependency on JDK 8. 🙂 time to update
https://github.com/bbatsov/clojure-style-guide/issues/126 this is an interesting read regarding the two modes
> Simpler rules, no need for have special cases for macros with body forms which are indented with 2 spaces (so it's complex to set up this rule when editor doesn't have built-in support) This is my favourite reason to not do it
I'm okay with 1 or 2 with very mild preference for 1. You guys decide I'll stick with it
I've been trying graphql these past few days and its been quite fun and interesting experience
can you summarise your impressions @guy?
ok so my gut feelings about it. First impressions of graphql, they are quite desperate to show how they are better than rest. A lot of the tutorials repeat that they are better over and over, which can be a little off putting at first. Then it takes a little while to understand the different way it works. Things i found nice about it, I can see clear benefits to speed of coding and maintenance of a project. Having a clear contract between front end and back end with an edn schema in the middle is quite nice. The front end can start building things with a spec/schema backed contract, being able to see the shape of the data almost right away. It feels like its easy to extend and update to add new or update objects and mutations/queries. Things i found hard. There is a lot of support for other languages our there, with some really nice js clients (which makes sense as it was facebook project iirc). So when googling you have to work a bit harder. I found the #graphql and the graphql slack to be helpful and people to be friendly. You have to read and reread the main docs to understand the whole concepts when working with lacina. I found the lacina docs to be pretty bare bones so i had to look at ruby/js/etc examples to get a feel for it. Overall i'm enjoying it and its been quite a fun journey so far. It gives me a chance to use clojure spec as well in the resolver-functions which is something i've not used before too. Apologies for the wall of opinons/text
@mccraigmccraig i hope that helps
yep, thanks @guy
something I'm trying to get with graphql lacinia is, if I already have core.spec definitions of most of the objects that end up in a query, is there a way I don't need to repeat myself with a new edn dialect? Maybe it's a solved problem already
Morning all 🙂
In the edn schema you have to specifify if things need to be non nullable in different thigns
For example, a game query is described with something like https://github.com/hlship/boardgamegeek-graphql-proxy/blob/master/resources/bgg-schema.edn#L19 That is not necessarily a full spec for a board game, but it overlaps with one if you happen to already have a board-game as core.spec somewhere. I was just wondering if I could just generate/derive the query from the specs.
I think about it this way: there's an impedence mismatch in the contracts that are provided by spec & graphql. In order to align them you have to:
1) constrain your specs throughout the application to use the subset which graphql can understand: I think this is very restricting, and is not an obvious design choice when adding a spec that it's going to screw up everything else.
2) write a very powerful clojure parser that can infer (valid-age?)
means that this needs to be a number in graphql.
Essentially, conversion requires alignment of contracts. Spec's contract is extremely open, meaning that it's a lot of work to align it with other contracts. This is the power of spec.
I'm glad I've finally figured out how to word it such that someone else can understand my concerns. I think it's quite a subtle point.
presumably (i'm not a spec user yet, so have to presume) you could go the other way and generate a bunch of specs from your graphql. would that be useful ?
Yep. Going the other way is easier in some sense. Depending on what you're after, it might be useful.
If you want one true™ :user/name
, then nope. If you're happy to have :user.graphql/name
just for generation purposes, then go for it.
I haven't used specs heavily on the project I'm on but my understanding is that they can be composed. Something like valid-age?
would be like
(s/def ::valid-age (s/and integer? (greater-than 18))
When generating the graphql (or any "lossy" schema syntax), you can just look at the first predicate in the s/and
and use that
Not sure I have explained this very well but what I mean is implemented in this PR for spec-tools
https://github.com/metosin/spec-tools/pull/69/filesThey can. But I feel like you shouldn't replace clojure.core/and with clojure.spec/and.
That's just a weird gut instinct I have though. Like, why should I be changing the way I write my predicates for spec?
2 is a little facetitiously worded, but I think the point holds up. Every predicate you add for validation needs to also be added to the parser for spec->gql, just in case. And those found in libraries too.
i’d probably go for something like “test that data generated from specs matches the graphql definition”
not sure is doable, just noticing the repetition (between something like graphql edn, core.spec and sql create table if you have them). Wondering if one could add a graphql plugin to https://github.com/andrewmcveigh/speculate
@otfrom hey, i just noticed you guys are right round the corner in bermondsey, right? we're in the biscuit factory. i should buy you a beer
Anyone about got any experience with enlive and DOM selectors? I need to grab all the nodes that match the following selector:
body > table > tbody > tr:nth-child(2) > td > a
but I am not particularly clear on the enlive approach to the selector syntax… Any pointers / ideas..?
@dominicm - Yeah, I think it ought to be, but I am just not completely clear on how…
The documentation and the tutorials I have found do seem to be making the assumption that there will be CSS classes and / or ids…
got a PR which bumps dependencies on a module of mine, but also added a linter and changed a bunch of source code formatting
this is a module which is a bit untidy, but basically stable and has barely been touched over the last few years
so I said fine, and started merging linter stuff - but I wish he’d opened with that explanation 😄
Software engineers are not always known for their communication skills! 🙂 I've been doing OSS work for over 20 years and it definitely has its highs and lows in terms of interactions with my peers...
Out of curiosity, what formatting is the norm when naming collections or functions where the name consists of multiple words?
E.g: (def some-descriptive-name { :foo "bar" })
vs (def some_descriptive_name { :foo "bar" })
vs ???
kebab-case is the clojure norm @yogidevbear
though i often end up with a bit of snake_case around from using :keys
destructuring on maps gotten from dbs where field names are usually in snake_case
Okay cool. That's what I figured