It depends on how much data you need.
And how much querying you need
Gotta jet; good luck!
😄 thanks for the help! ttyl
to complete my thought: Concurrent React implements async rendering (like Reagent) but also a scheduler to prioritize updates (which Reagent doesn’t have). In doing so, if you want something to be e.g. top priority (button click, keyboard event) then you need to tell React to re-render inside of the event handler
so if you are, for example, storing the state of a text input box that lives in an external data store that updates things via subscription, then you run the risk of blocking your text input from updating as the user types because some other updates come in that are the same or higher priority. async updates are automatically scheduled lowest priority.
there’s also the chance of your application state drifting from what’s being rendered on the screen. if you let React completely control the state of your application, your state updates are prioritized and executed the same as the UI updates and so they are always in sync
For reference, this is what we’re talking about, right? https://github.com/comnik/declarative-dataflow
Upon closer inspection, it seems like we need both the server and a frontend implementation (which might be clj-3df compiled to browser-compatible cljs)
I have some sketches over at https://github.com/comnik/functional-differential-programming, regarding WASM 3DF + React. But we are currently focusing on the foundations, before exploring more oft that.
Apart from integrating the inherently change-based 3DF with the more snapshot-based React, the WASM bundles are quite large still.
The backend is most important, the frontend adds the Datalog syntax. Frontend should already be cljs compatible.
We also support pull queries in the backend now, that still has to be supported in the client. In any case, reactive frontends with just DataScript worked and still works pretty well for us!
Is it correct that Datomic keeps information about attributes as part of the database, using :db/ident
, while DataScript uses a separate schema for that?
I am looking at https://docs.datomic.com/on-prem/getting-started/transact-schema.html vs http://udayv.com/clojurescript/clojure/2016/05/06/datascript101-chapter2-uniqueness-and-indexing/
Yes @urzds, datascript schema is separate and not queryable afaik
In datascript, you only add things to the schema when you need special functionality like cardinality many. Otherwise, you don't need to declare attributes in the schema, you can just start using them.
Ah, in Datomic I need to declare everything?
Is it correct that I can specify refs as [:unique-key "value"]
or {:multiple "val1" :keys "val2"}
, and in the former case (`[]`) the referenced element has to exist already, while in the 2nd case (`{}`) it will be automatically created if missing?
(It appears like that in DataScript, but I couldn't find any docs / specifications that seem to enforce this.)
(ds/q '[:find ?tx ?id ?v ?ts
:where
[?e :entry/value ?v ?tx]
[?e :entry/id ?id ?tx]
[?e :entry/ts ?ts ?tx]]
app-db)
☝️ this query doesn't work under advanced optimizations. any ideas why?#datascript/DB {:schema nil, :datoms [[1 :entry/id 15 536870914] [1 :entry/ts 1557849697260 536870914] [1 :entry/value {:value 1, :meta nil} 536870914]]}
is the DB for instanceand that query returns #{[nil nil nil nil]}
created an issue: https://github.com/tonsky/datascript/issues/298
Datomic describes it: https://docs.datomic.com/on-prem/transactions.html#nested-maps-in-transactions