[ClojureScript] Re: How to require a library only if it is on the classpath?

[Christopher Small]

I realize this doesn't directly answer you're problem, as you're asking 
about how you might do this in ClojureScript, but you may still be 
interested to take a look at

https://github.com/clojure-goes-fast/lazy-require

If you figure out a solution, it could be helpful for that library to have 
a cljc implementation of the underlying idea here.

Good luck

Chris

-- 
Note that posts from new members are moderated - please be patient with your 
first post.
--- 
You received this message because you are subscribed to the Google Groups 
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at https://groups.google.com/group/clojurescript.

Re: [ClojureScript] Re: How do you use GraphQL with Clojurescript?

[Christopher Small]

My pleasure; Happy to have been helpful.

I'll clarify that I think om-next is probably going to be the most Clojuric
and well-trod approach to GraphQL style web development with
Clojure/Script. However, I personally prefer Reagent over Om. This is part
of why I started down the route of developing Datsync. I hoped that I'd be
able to decouple from the particulars of the React wrapper (om vs reagent
vs rum vs quiescent etc), and have something more standalone. But we're
quite a bit further from being generally production ready, so factor that
in as you will. And to be clear, I think Om is great, so don't let my
preferences steer you away. But maybe also consider tinkering with Reagent
a bit for contrast.

Cheers

Chris


On Wed, Jul 5, 2017 at 11:25 AM, Nick Pavlica <lini...@gmail.com> wrote:

> Hi Chris,
>   Lots of great information here!  It sounds like your preference is
> Om(next), which sounds very interesting.  I think that I'll have to dig in
> and play with it before things really start to click.  I'm sure I'll have
> many more questions once I get a better handle on Clojurescript approach.
>
> Thanks Again!!
> -- Nick
>
> On Saturday, July 1, 2017 at 3:19:59 PM UTC-6, Christopher Small wrote:
>>
>> Hi Nick
>>
>> I'll try not to get carried away here...
>>
>> First off, folks in the Clojure and ClojureScript communities are
>> absolutely familiar with, inspired by, and building on top of or in the
>> direction of GraphQL. David Nolen, the author of Om and the lead
>> ClojureScript developer, has build om-next which is more or less a Clojury
>> take on the GraphQL idea. The insight there, which Dustin hints to, is that
>> Datomic has this thing called a pull query you can execute, which is more
>> or less isomorphic (I guess if it's more or less I should just say
>> homomorphic...) to the GraphQL query. Om-next is basically just "let's
>> close that gap", and most of the gap is stuff like pagination and sorting
>> of collections. So it gives you a way of describing these things directly
>> in your pull queries. The nice thing about the pull query, is it's just a
>> data structure, so it's very composable. You can build queries up
>> programatically, which is really lovely. This pattern of building programs
>> around the composition of data structures is really a cornerstone of the
>> Clojure philosophy.
>>
>> As I think some others have pointed out here, there seem to be others
>> experimenting more directly with the GraphQL api. But om-next is really no
>> less agnostic about a lot of things than GraphQL. It's not really tied to
>> Datomic, except in that it inherits the pull query syntax. But you can
>> implement the resolvers and such to work with any backend storage mechanism
>> (and long as you can traverse the relationships). The Datomic integration
>> happens to be trivial, which is nice, and opens up other possibilities.
>> However, Datomic is not the only "Datomic" in a sense. DataScript is a cljc
>> (meaning, it can compile to and be used from both Clojure AND ClojureScript
>> (And JS actually)) implementation of an in memory version of the Datomic
>> API. It's actually surprisingly feature complete, and a great way to
>> experiment with the underlying data model, pull queries, and even Datalog
>> (a query language also baked into Datomic which is more expressive than
>> SQL, and better for querying graph relations). The folks at Mozilla have
>> also started working on Mentat, a Rust (I believe) implementation of a
>> Datomic like database on top of SQLite. It's very clear to me with all the
>> activity around these projects that while Datomic remains a very powerful
>> system with many features these other projects will likely never aim for,
>> the overall idea has started catching on, and is worth paying attention to.
>>
>> Part of what makes the om-next approach so fascinating is that Datomic's
>> data model is based on RDF. If you're not familiar with it, RDF is a web
>> standard, and the de facto data language of the Semantic Web (also manifest
>> as web standards). It's part of the vision of the computable web of data.
>> The idea is that all data should be self-describing, globally meaningful,
>> and infinitely extensible. There are vocabularies which can be described in
>> RDF data, which themselves describe the schema and meaning of other data.
>> It's super brilliant stuff, and actually really simple! Data is organized
>> as (entity, attribute, value) triples of "facts". The key is that as long
>> as your attributes are globally meaningful, you can merge information about
>> an entity without ever worryin

[ClojureScript] Re: Having trouble with Japanese text input that reads values from a reagent atom

[Christopher Small]

You may want to take a look at the re-com input helpers. They are set to fire 
not on each keystroke, but once you either leave focus or hit enter. That might 
work out for you. You could either use the re-com helpers, or look at the 
source to see what event handlers they use.

-- 
Note that posts from new members are moderated - please be patient with your 
first post.
--- 
You received this message because you are subscribed to the Google Groups 
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at https://groups.google.com/group/clojurescript.

[ClojureScript] Re: Preparing proposal for presentation on replikativ

[Christopher Small]

Hi Christian

Would love to see this talk (embarrassed I still haven't watched the video 
you posted in Gitter though...).

As you'd suspect, I'm definitely like to see a good bit on 
DataScript/Datomic. Aside from that, I think a good focus on the strengths 
and weakness (/challenges/work-to-be-done) would be very informative, and 
help illustrate some of the implications of the approach. In particular, 
challenges in dealing with larg(ish) data sets and/or data that changes 
very frequently are very interesting.

Cheers, and good luck :-)

Chris



On Monday, August 1, 2016 at 4:57:44 AM UTC-7, Christian Weilbach wrote:
>
> Hi, 
>
> I would like to present replikativ at the EuroClojure 2016 conference 
> (1). I would talk about the motivation and how it is implemented 
> (core.async, the foundational libraries, integration with 
> DataScript...). There is the background theory of CRDTs, the general 
> problem of data replication and synchronization, the particular case of 
> DataScript/Datomic replication, mobile or web frontend development etc. 
> I will have to focus on some aspects. Do you have any particular 
> interests I should address? 
>
> Best, 
> Christian 
>
> (1) https://github.com/replikativ/replikativ 
>
>

-- 
Note that posts from new members are moderated - please be patient with your 
first post.
--- 
You received this message because you are subscribed to the Google Groups 
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at https://groups.google.com/group/clojurescript.

[ClojureScript] [ANN] Datsync: Datomic <-> DataScript syncing utilities

[Christopher Small]

Greetings

I'm happy to announce an early SNAPSHOT release of Datsync, a
Clojure(script) library for syncing Datomic and DataScript databases.

Github: https://github.com/metasoarous/datsync
Coordinates: [datsync "0.1.0-SNAPSHOT"]

The library is built around a small handful of functions for translating
transaction data between Datomic and DataScript. At the moment, all that is
supported out of the box (without a bit of thinking on your part) is whole
DB replication and sync, with all writes going through Datomic before
getting sent out clients.

Our near term goals for the project include:

* additional utilities for handling read/write authorization and efficient
partial syncing
* offline DataScript availability (true bidirectional sync)

Some other resources:

* My Clojure West talk about Datsync and some of the patterns it enables:
https://www.youtube.com/watch?v=aI0zVzzoK_E
* Catalysis; an example Datsync + Posh application template:
https://github.com/metasoarous/catalysis
* Posh; a wonderful library for implementing declarative re-frame style
signal graphs as DataScript queries (currently Reagent only, but soon will
support Rum, Quiescent, etc): https://github.com/mpdairy/posh


Hope you enjoy :-)

Chris Small

-- 
Note that posts from new members are moderated - please be patient with your 
first post.
--- 
You received this message because you are subscribed to the Google Groups 
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at https://groups.google.com/group/clojurescript.

Re: [ClojureScript] Re: re-frame why only 1 handler per [:some-event-id]?

[Christopher Small]

Great conversation; I'll just add that I think it's a pretty fundamental
part of re-frame (as I see it, thinking about the "materialized views all
the way down | derived data all the way down | streams everywhere | however
you want to sell it" approach that is behind re-frame and samza) that there
is a _single_ app db from which the entire app emanates. (Of course, we
have Mike T. himself here in this thread so he's welcome to object or
qualify his own vision here :-)) It's what (as Mike T. pointed out) what's
behind the glitch free semantics of re-frame, and brings with it some nice
conceptual properties. Of course, your criteria of building aspects of the
app as independent "modules" raises an interesting question about how you
handle state in such a situation. As I see it, there are a couple of
approaches to this problem:

* Have the top level of your application state (app-db, whatevs) reflect
the collection of modules that you have in the application. So maybe it
would be a map with keys corresponding to your different modules. You could
build up helpers around this structure which make it fairly straight
forward to add module data to the top level app db. There's still a bit of
thinking to do regarding how you orchestrate/register the handlers for each
of these modules (ideally this would be deterministic as far as state
updates go). But there are already a lot of ideas in this thread which can
be applied towards a solution given this app-db structure (methinks).
* If datascript/datomic are appealing to you, you could use a datascript db
on the client together with qualified attribute names reflecting the module
breakdown. If you set things up right, you don't really have to think about
"organizing" data for one module versus the other. You can look into the
posh library which gives you some nice tools for creating reactive
datascript queries (materialized views/signals/etc) for use in your reagent
components. It's really quite lovely :-) However, at the moment it's not
out of the box interoperable with everything in re-frame. But we're
currently in the process of figuring out how we'd get such interoperability
(or at least implement the abstract re-frame pattern using these pieces).

Chris


On Tue, Mar 29, 2016 at 3:40 PM, Luke Horton 
wrote:

> I see, thanks for that. I guess I was avoiding that strategy initially
> because it sort of felt like monkey patching in ruby/js, which is just
> bound to break eventually. It's not monkey-patching in this respect,
> though, it's just app-specific api design.
>
> --
> Note that posts from new members are moderated - please be patient with
> your first post.
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ClojureScript" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojurescript/qIvYyk5Ptek/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojurescript+unsubscr...@googlegroups.com.
> To post to this group, send email to clojurescript@googlegroups.com.
> Visit this group at https://groups.google.com/group/clojurescript.
>

-- 
Note that posts from new members are moderated - please be patient with your 
first post.
--- 
You received this message because you are subscribed to the Google Groups 
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at https://groups.google.com/group/clojurescript.

[ClojureScript] Re: re-frame why only 1 handler per [:some-event-id]?

[Christopher Small]

There's a whole section in the wiki dealing with more custom handling, routing, 
etc: 
https://github.com/Day8/re-frame/wiki/Alternative-dispatch,-routing-&-handling

That should help.



On Monday, March 28, 2016 at 1:13:39 PM UTC-7, Luke Horton wrote:
> Why does the re-frame framework restrict a 1:1 between dispatches and 
> handlers?
> 
> At first I found it a little weird. I can think of lots of realistic cases 
> where:
> 
> ```
> some event happens -> module a responds; module b responds;
> ```
> 
> Then I thought... well, if one module has a handler that changes the app-db, 
> every other module only needs to subscribe to the same query, and they won't 
> ​*need*​ to also handle that event, it will happen reactively:
> 
> ```
> some event -> module a responds (change db value) -> module b reacts to 
> change;
> ```
> 
> But then I remembered that very frequently I need to handle this behavior:
> 
> some event -> module a responds (starts fetching new data) ... eventually 
> updates db;
> 
> Which I can't seem to fit into the paradigm of 1:1 handler to event.
> 
> If we only have a 1-handler per event restriction, how can I also have:
> 
>  some event -> capture event in module a (start fetching new data);   ???   ; 
>  capture event in module b (start fetching a different set of data); 
> 
> Receiving the data would be relatively straightforward ... dispatch separate 
> events (from a receiving chan) for [:a-data] and [:b-data], but how we 
> implement in a decoupled manner the initial "go get data" across different 
> modules is lost on me.
> 
> Any suggestions / patterns for solving this would be helpful.

-- 
Note that posts from new members are moderated - please be patient with your 
first post.
--- 
You received this message because you are subscribed to the Google Groups 
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at https://groups.google.com/group/clojurescript.

Re: [ClojureScript] Pdf Generation with Clojurescript

[Christopher Small]

On Wednesday, December 23, 2015 at 8:59:08 AM UTC-7, Chris Murphy wrote:
> There is a library from an earlier version of iText:
> https://github.com/yogthos/clj-pdf
> 
> This is an example using a more recent (commercial) version of iText:
> https://github.com/chrismurrph/example-itext-pdf-report
> 
> Regards ~ Chris
> Chris Murphy
> 
> On 23/12/2015 7:08 PM, Matthew Molloy wrote:
> > Anybody tackled this?  There is a js lib called http://pdfkit.org/, I could 
> > write a wrapper.
> >

The yogthos/clj-pdf library is Clojure only, not Clojurescript.

I would love to see a Clojurescript library for generating PDFs. That might 
come in handy for a project I have coming up.

If you do build something wrapping the JS PDFKit library, it might be nice to 
have an API modelled around the clj-pdf library. Perhaps it would even be 
possible to extend the clj-pdf library with a cljs implementation based on 
PDFKit?

Chris S.

-- 
Note that posts from new members are moderated - please be patient with your 
first post.
--- 
You received this message because you are subscribed to the Google Groups 
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at https://groups.google.com/group/clojurescript.