[ANN] re-graph 0.1.8 - the GraphQL client for Clojurescript

[Oliver Hine]

Hi everyone,

I'm pleased to announce the release of re-graph 0.1. 
8. re-graph is a GraphQL client for 
Clojurescript with re-frame bindings and support for queries, subscriptions 
and mutations over websocket or HTTP

This release *fixes*:

   - Query and mutate API functions #38 
   , thanks @qiuyin 
   
   - Retrying queries over websocket when the websocket is not ready #39 
   


It's available now on Clojars.

Thanks and enjoy,
Oliy

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] re-graph 0.1.8 - the GraphQL client for Clojurescript

[Matching Socks]

It dresses up HTTP failures in the GraphQL error structure so the user has 
to cope with only one failure channel.  Is that what everyone does?  
Anyway, I did not see that spelled out in the Readme.  It looks like a 
useful feature!

By the way, I see it uses cljs-http, which in turn uses clj->js and 
js->clj.  I vaguely remember that those functions can be unreliable (or 
unpredictable) under advanced compilation.  CLJS-2062 
(https://dev.clojure.org/jira/browse/CLJS-2062) has a comprehensive 
explanation in a comment from "Thomas Heller", and also a workaround.  But 
re-graph, by indirectly using js->clj, may be at risk.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Noob question on the --> macro implementation

[Ujjwal Thaakar]

I didn't understand what you meant by

> where seq?, as distinct from seq, does not check whether there is anything 
> in the sequence.


On Sunday, January 27, 2019 at 5:31:15 PM UTC+5:30, Matching Socks wrote:
>
> Gary might be on to something. The immediate context is
>
> (if (seq? form)
>   (with-meta `(~(first form) ~@(next form)  ~x) (meta form))
>   (list form x))]
>
>
> where seq?, as distinct from seq, does not check whether there is anything 
> in the sequence.
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Noob question on the --> macro implementation

[Ujjwal Thaakar]

Sorry I had completely forgotten about this post and just saw it now. I 
think this explanation makes sense although in most cases the thread value 
will also not be a function and if it is then it could be treated as 
invoking the threaded function's call and the result passed on to the next 
form.

On Sunday, January 27, 2019 at 5:23:24 AM UTC+5:30, Gary Fredericks wrote:
>
> There's probably also a difference in what happens if the form is empty. 
> The current impl results in a compile error about calling nil, whereas the 
> suggested implementation would result in calling the current thread value 
> as a function, I think.
>
> On Saturday, January 26, 2019 at 5:13:23 PM UTC-6, Sean Corfield wrote:
>>
>> I suspect it’s done for consistency with the source of -> (which has to 
>> use first/next because it threads the expression between them) – using 
>> first/next/x in ->> is therefore a closer parallel to using first/x/next in 
>> -> so it’s easier to see the similarity (and correctness) of the code.
>>
>>  
>>
>> Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
>> An Architect's View -- http://corfield.org/
>>
>> "If you're not annoying somebody, you're not really alive."
>> -- Margaret Atwood
>>
>>  
>> --
>> *From:* clo...@googlegroups.com  on behalf of 
>> James Reeves 
>> *Sent:* Saturday, January 26, 2019 11:08:25 AM
>> *To:* clo...@googlegroups.com
>> *Subject:* Re: Noob question on the --> macro implementation 
>>  
>> I believe he's just saying it's simpler and possibly more efficient.
>>
>> Unless I'm missing something subtle in the way this is resolved, I 
>> believe Ujjwal is right that:
>>
>> `(~(first form) ~@(next form) ~x)
>>
>> Is equivalent to:
>>
>> `(~@form ~x)
>>
>> On Sat, 26 Jan 2019 at 19:04, Andy Fingerhut  
>> wrote:
>>
>>> When you ask "am I right?" about your proposed change, what is it that 
>>> the current behavior does not do, that your change would do?  Do you have 
>>> some use case in mind that works with your change, but doesn't with the 
>>> current implementation? 
>>>
>>> Andy
>>>
>>> On Sat, Jan 26, 2019 at 10:50 AM Ujjwal Thaakar  
>>> wrote:
>>>
 Hi, 
 I'm trying to learn Clojure and I just curiously typed  
 (source ->>)
  in the REPL and was wondering about this: 
 https://github.com/clojure/clojure/commit/749a0ad8b66c781d8176833f0ad26cfe6b9b24e3#r32075784

 Am I missing something?

 -- 
 You received this message because you are subscribed to the Google
 Groups "Clojure" group.
 To post to this group, send email to clo...@googlegroups.com
 Note that posts from new members are moderated - please be patient with 
 your first post.
 To unsubscribe from this group, send email to
 clojure+u...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 --- 
 You received this message because you are subscribed to the Google 
 Groups "Clojure" group.
 To unsubscribe from this group and stop receiving emails from it, send 
 an email to clojure+u...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

>>> -- 
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clo...@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with 
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+u...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> --- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to clojure+u...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>> -- 
>> James Reeves 
>> booleanknot.com
>>
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from th

Re: Noob question on the --> macro implementation

[Ujjwal Thaakar]

Yes that was my only point.

On Sunday, January 27, 2019 at 12:39:12 AM UTC+5:30, James Reeves wrote:
>
> I believe he's just saying it's simpler and possibly more efficient.
>
> Unless I'm missing something subtle in the way this is resolved, I believe 
> Ujjwal is right that:
>
> `(~(first form) ~@(next form) ~x)
>
> Is equivalent to:
>
> `(~@form ~x)
>
> On Sat, 26 Jan 2019 at 19:04, Andy Fingerhut  > wrote:
>
>> When you ask "am I right?" about your proposed change, what is it that 
>> the current behavior does not do, that your change would do?  Do you have 
>> some use case in mind that works with your change, but doesn't with the 
>> current implementation?
>>
>> Andy
>>
>> On Sat, Jan 26, 2019 at 10:50 AM Ujjwal Thaakar > > wrote:
>>
>>> Hi,
>>> I'm trying to learn Clojure and I just curiously typed 
>>> (source ->>)
>>>  in the REPL and was wondering about this: 
>>> https://github.com/clojure/clojure/commit/749a0ad8b66c781d8176833f0ad26cfe6b9b24e3#r32075784
>>>
>>> Am I missing something?
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clo...@googlegroups.com 
>>> 
>>> Note that posts from new members are moderated - please be patient with 
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+u...@googlegroups.com 
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> --- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to clojure+u...@googlegroups.com .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com 
>> 
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> -- 
> James Reeves
> booleanknot.com
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Keys spec with :additional-keys boolean option

['somewhat-functional-programmer' via Clojure]

I assume you are forced to use XML (if you are choosing the format, I 
wholeheartedly recommend EDN!).  If you /do/ control the choice of XML/EDN but 
want to interoperate with other languages, check out: 
https://github.com/edn-format/edn/wiki/Implementations - maybe you could use 
EDN anyhow if you have forgiving consumers (hat tip to Alex Miller who pointed 
this page out again recently).

If you must use XML, have you considered the approach of using a generic XML 
data structure (which would by definition have the in-memory definition mirror 
the serialized version)?  You could write a transform function to turn it into 
something you'd rather use from clojure, or simply define accessor functions 
into your data.  I've used data.xml (https://github.com/clojure/data.xml) 
before along with specter (https://github.com/nathanmarz/specter) to 
transform/modify/access XML data.  Though I have to admit, every time I do, I 
curse immutable data structures -- they are unwieldy for /modifying/ highly 
nested structures (XML!).  Specter is the best library I've seen for modifying 
deeply nested structures, and is worth the learning curve (you'll use it 
everywhere once you get used to it -- it's really fantastic), but still isn't a 
perfect fit for XML.

Here's an example of something simpler I wrote to read out the bits of maven 
pom files that I cared about:

(defn collapse-xml
  "Collapses xml data in the form from clojure.data.xml (:tag :t :content 
[\"some whitespace\" {:tag :another-element ...}])
into {:t {:another-element \"value\"}}

   This works well for many configuration style xml files, but you will lose 
all textual content surrounding elements.  For example:
This is some bold text. Is a terrible use case for this, as 
it will return {:p {:bold \"text\"}}

   This does work very well for pom files however."
  [m {:keys [tag content]}]
  (assoc
   m
   tag
   (if (every? string? content)
 (let [s (clojure.string/join content)]
   (if (clojure.string/blank? s) nil s))
 (reduce
  collapse-xml
  {}
  (filter map? content)

If you are using mainly "configuration" style small XML files like maven pom 
files, something simple like this could give you an ergonomic /accessor/ 
clojure data structure (not one suitable for editing and transforming back to 
an on-disk representation though).

Every time I have to use XML from clojure I have yet to find a solution that 
feels clean.  I yearn for xpath and a mutable API (maybe just using a good set 
of Java APIs via interop is really the best answer here).

Given that I can't find a clean solution for XML in clojure, I find the idea of 
trying to use clojure.spec for validation purposes for XML data even more 
difficult to imagine than if the serialized representation were simply EDN to 
begin with.  In fact, I think that's the only time I've gotten any value out of 
clojure.spec in my own projects -- I've used it for verifying serialized EDN 
and found its validation error message output useful (though /so/ verbose for 
large specs!).  I relentlessly spec'd out my projects' data structures in the 
beginning when spec was released (I started my clojure journey when 1.9 was in 
alpha and spec just released), not even looking at plumatic schema or other 
alternatives since clojure.spec was going to be built into core.  However, what 
I ended up with was pages of attribute specs which mostly looked like int?, or 
string?, or keyword?, or map key lists (though some regexes and ranges!).  From 
the reader's perspective it was tough to see what the data was actually going 
to /look/ like.  And then, where to actually use the specs?  Runtime 
performance was too slow to use everywhere...  My most egregious use of spec 
was in multimethods or cond forms, essentially trying to dispatch on the /type/ 
of a map (not knowing in advance what I would get).  Needless to say I have 
stopped using spec as I couldn't manage to figure out a way forward for me 
where its benefits outweighed its costs.  I kept trying to use it as a type 
system, which I think it is ill-suited for (and even if it were suited to it -- 
it's too slow to use as such).

I have since settled on using truss, a wonderful little library 
(https://github.com/ptaoussanis/truss) and have never looked back.  I highly 
recommend looking at it -- you get great error messages for essentially 
run-time type assertions only where you need them (or are currently debugging). 
 That plus typical spy-like macros go a long way (see another great library by 
same author as truss, timbre (https://github.com/ptaoussanis/timbre) which 
includes a nice spy macro).  I made one that defs the value being spied in the 
current namespace if an optional condition is met on the data value.

I had high hopes I would grok clojure.spec enough to get more value out of it 
than time I put into it.  But as of now, simpler solutions have served me far 
better.

‐‐‐ Original Message ‐‐‐
On Monday