This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aws-lambda (7)
- # beginners (80)
- # boot (134)
- # cider (11)
- # cljs-dev (5)
- # cljsjs (3)
- # cljsrn (19)
- # clojure (144)
- # clojure-austin (2)
- # clojure-berlin (3)
- # clojure-greece (6)
- # clojure-italy (3)
- # clojure-russia (95)
- # clojure-spec (57)
- # clojure-uk (120)
- # clojure-za (2)
- # clojurescript (71)
- # component (1)
- # css (1)
- # cursive (22)
- # datascript (2)
- # datomic (101)
- # dirac (9)
- # docker (3)
- # emacs (10)
- # events (2)
- # immutant (3)
- # leiningen (2)
- # om (63)
- # om-next (1)
- # onyx (6)
- # pedestal (55)
- # portland-or (3)
- # protorepl (2)
- # re-frame (30)
- # reagent (10)
- # ring-swagger (1)
- # rum (31)
- # spacemacs (5)
- # specter (9)
- # untangled (90)
- # yada (2)
@sova that’s just saying it’ll pull a collection
iirc it should return
[name1 name2 …] instead of something weird like
Oh cool. Ah that makes some sense. Man, I just found Datascript... super stoked to have a client-side "db"
yeah at navis/untangled we’ve tried datascript but found it slow and unnecessary for the client db when simple map lookups work fine and fast but maybe @tony.kay might have more to say on that
when you say "map lookups" ... data is stored on the client-side but in a different way?
@sova why do you care about a client-side datomic database (e.g. Datascript)? There are good use-cases...I'm just wondering what yours is
Thinking forward to mobile versions, I want users to be able to browse lots (~100s) of articles without the need to constantly ask the server. And it will probably help me in learning read/mutate better, since I know Datomic well, but am still having trouble wrapping my mind around how it interops with omnext
Really the main benefit is offline enjoyment of resources.. perhaps there are alternatives
Datascript gives you a high-end parser of Datalog to do complex data operations. Using it for holding a collection is like putting in a thumbtack with a 50lb sledgehammer
Haha, well that's an illustrative way to put it. Do you think it'll slow down things considerably to "bog down the browser" with a Datascript instance?
So, it will increase app load time (bigger js footprint), but not terribly. The thing is, how do you plan to use it?
If using Untangled, you're going to...what...write a mutation that does a datascript query to copy data from datascript into your UI?
If using Om Next, you write parser emitters for the query that would query datascript, but that is going to make your UI slower, because running a query is a heck of a lot slower than looking things up in a map(what Untangled does)
and how do you populate your Datascript database? With a network request. Well, Untangled already gives you that ability, and can pull the result into it's app database (and cache it there).
so, it has a cool factor, but from my perspective you've done nothing but added incidental complexity
For completeness: a good use-case for datascript is you want to download a bunch of data for analysis that will use the user's CPU. Put it in datascript and write the data analysis in cljs, and then you actually want datalog support on the client.
Correct me if i'm not, but there's basically the Datomic-friendly read (for :remote true) and then there's the local client-side atom read ... I just like the idea of the code reuse, but it might verywellbe overkilll.
I see what you mean for a good use-case. There really isnot a lot of computation in my application. Just a lot of text sharing between server and client.
the response to the client read from datomic is automatically merged into the app database. There is no work for you to do.
In stock Om next, there is a ton to do (network pipeline, merge augmentation, satisfying client read, etc.)
Have you followed along on the dev guide tutorials and written a full-stack app yet?
db->tree is cool. Don't knock it :wink:
2. Untangled calls
db->tree for you. So you don't have to
I'm working on an app, but starting from scratch (is good for the learns.) It just seems like an unbridge-able chasm at the moment to negotiate between the app-state atom and my datomic store
Man once I get this working I am going to write some awesome articles about doing all this stuff (to help the documentation efforts of all these wonderful things)
Yeah? Okay, that's good to keep in mind, that datascript would kinda be a move in the opposite direction.
It's a little tough to find out exactly what knowledge I need to make everything tie together. Currently seems like a Rubiks' Cube
there's a playlist of these, but this one demos doing server integration. Imagine datomic satisfying the server query (1-2 lines of code)...the rest is the same
Hmm. So there are just a few magic lines to add to ask Datomic for all the goods... Is that where (db->tree) comes into play? Translating the graph-DB (datomic) into the app-state atom?
Okay. The pull is the magic. So there's a generic query line that talks to the DB and the pull syntax can get any biscuit I need based on color, shape, wheat, etc... (to use bread as an example)
you see it looks just like Om queries...and returns data in the map structure you need
Ah yes. Okay. Still some fuzziness in my head about how it all fits together, but that makes sense. Om.next query is essentially a datomic query and what comes back is that beautiful map...
yep. So typically what you do on the client is send a query from some sub-portion of your UI (say you want to pull the items in a todo list)...you send the query for Item, along with a parameter (the entity of the list)
The server does a pull query anchored at that entity, which gives you back the items
Then, you can (on the client) add in a post-mutation that creates a list of idents of those items, and places them in the place you want to show them. Possibly is sorts them. Possibly it filters them. etc. etc.
adding a bit of linkage so your UI sees what you want it to see is just a slight bit of graph joining...which is typically as simple as
(swap! state assoc-in [:todo-list/by-id 42 :items] [[:item/by-id 1] [:item/by-id 2] ...])
but understanding what I just said above means you need to understand, very clearly, the graph db format...which really is quite simple: top-level tables as maps, and idents for pointers
good luck...I'm going to get some food. I'd really recommend watching the videos on YouTube if you have not. I walk through quite a bit of this in detail.
I don't understand what you mean when you say "along with a parameter (the entity of the list)" ... My datomic store has many individual elements (i refer to them as blurbs) and each one has a :blurb/title, :blurb/content, :blurb/author ... i do want to bring them to the clientside but I have no ":blurb/list" element in datomic, is that something that exists (only) in the client side atom
Thanks for that video! one thing that became clear was that :whatever/by-property is actually an Om-next special syntax that messes wth the atom state :property .... i was really curious about that. like by-id (and how it knew)
@sova Nothing special about it. It is a name to remind the person coding that the table has keys that are IDs. The ident function (that you write) makes these up. If you index by id, then usually you'll name the table
If you have no ownership of blurbs, then you'd just query for them all and send them down, and yes, then your client code would "make up" a :blurb-list top-level key
usually you have some kind of ownership...at least to the logged-in user, or a topic, etc etc
Is it possible to access the database connection inside untangled-datomic’s migrations without using