This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-01-31
Channels
- # aatree (1)
- # admin-announcements (3)
- # aws (3)
- # beginners (36)
- # boot (227)
- # cljsrn (27)
- # clojure (57)
- # clojure-czech (6)
- # clojure-miami (8)
- # clojure-poland (17)
- # clojure-russia (113)
- # clojurescript (9)
- # community-development (1)
- # core-async (11)
- # core-matrix (2)
- # core-typed (3)
- # cursive (3)
- # datomic (5)
- # editors (40)
- # emacs (6)
- # heroku (1)
- # hoplon (50)
- # incanter (1)
- # ldnclj (4)
- # luminus (3)
- # mount (1)
- # om (132)
- # onyx (5)
- # proton (3)
- # re-frame (5)
- # spacemacs (1)
- # testing (12)
- # yada (6)
has anyone else run into this? i’m just working through the remote sync tutorial
Can anybody explain what the benefits of using datascript with om-next? I know om pretty well, but have no knowledge about datascript.
@artemyarulin: at this point I would not use it. You would have to write some custom logic for edge cases like link
lookups (see om.next wiki "thinking-with-links")
@artemyarulin: you get datalog for queries and don’t rely on idents since datascript has a schema
@denik: Thanks. But pretty much if I stick with standard om-next queries for now then if I decide to move to datascript I would have to change all the queries across all the application?
They are completely different?
i pulled out datascript recently because I ran into issues and it only took an hour for 40 queries or so
if you don’t use datomic and don’t have a really very complex front-end, you may not need datascript at all
I would have a complex frontend indeed, that’s why I’m thinking about datascript. Why did you choose to start with datascript at first? What is the main benefit for you?
comparing to standard om-next queries?
oh, yeah, it makes sense then
what is this?
ala stored procedures in big db, hm
Another reason for datascript is that I’m actually gonna write apps for mobile and DataScript could be a cross platform DB to use for both iOS and Android
Thanks in any case, I guess the right thing would be to setup and play with it for a while
yep, I think if you write react native through om it will provide just that. @artemyarulin ur welcome
@hueyp: links are not the only thing that make your data a graph
Links and idents are not related in that sense
I suggest you go over the components, identity and normalization turorial to understand what idents are for
I removed the Ident from Item
component in https://github.com/omcljs/om/wiki/Thinking-With-Links%21 and it stopped working which confuses me
@hueyp: it stopped working because Om doesnt know how to normalize the data anymore
why does the item list need to be normalized? is it not okay for something to be a vector of maps? the vector entries have to be links?
for instance if something was a component vs entity … a person has a list of addresses, but there is no identity to address, it is just a component of person
@hueyp: normalization prevents data duplication, and complex update logic that results from it.
You can always not normalize data
But then you should not be calling db->tree
I need to look more at db->tree
for sure. I can nest maps, e.g. if a person has a single address, db->tree
works fine, but as soon as I make it a collection db->tree
is unhappy
I'm pretty sure it's supported, if it's not returning anything you might 1. Not have the right idents in place; 2. Not have the correct queries
If you think it's a bug, make a minimal case and post it in this channel
but if the data structure is {:phone-numbers [{:area 123 :rest 1234567}]}
… I don’t think an ident is appropriate?
@hueyp: right but querying has nothing to do with normalization
You can still query denormalized data
It's up to you to implement the parser logic anyways
yah, but I was hoping to avoid that by keeping things in the default db format and being able to use db->tree
I thought the default db format was normalized. Things work better normalized. You only need db->tree if your data is normalized.
I don’t understand how {:phone-numbers [{:area 123 :rest 1234567}]}
is not considered normalized
You can start with initial data that is not normalized and let on next normalize it for you.
would {:app {:selected-button [:button/by-id 3] :favorite-button [:button/by-id 3]}}
also be normalized?
this the demo : https://github.com/Jannis/om-next-kanban-demo ?
That seems to be required for tree->db to do its job, which is what happens by default when you don't give the reconciler an atom.
Here is Jannis's code simplified, so no rendering, just for the purpose of getting normalized data, which takes some time and you need to know how it works:
Hello, I don't undertand what is a om.next/factory? when I need to use it? in which case I need to use validator? Is there documentation on it?
It allows you to create an instance of the React component you defined with defui
macro. Before you use it to create a React component ON can still call the static methods of the defui
component.
Hi, has any of you tried server rendering with Om Next? I want to have query-based components and use read-only app state on server to render them. Unfortunately I cannot see any way of running om next queries via parser other than using add-root!, which doesn't make sense with server rendering.
As far as I understand in normal rendering logics, query results are added to the props, available in render function. I would like to have it done, so no special cases are needed.
hmm guys, does any one get this error on latest om.next ?
Uncaught #error {:message "No queries exist for component path (my-project.components.app/App my-project.landing.page/Page)", :data {:type :om.next/no-queries}}
I'm pretty sure I have static om/IQuery
on both components, maybe I misunderstand anything ?@krcz: for server side rendering take a look at https://github.com/arohner/foam maybe you could build on this...
with the thinking in links tutorial, if you move [:viewer _]
down to SomeList
it doesn’t work … is the idea you can only embed links in sub-queries, they aren’t proper ‘roots’?
@hueyp: [:viewer {:items [[:viewer _ ]]}]
is valid
yes that's true, the reason for that is only top-level keys trigger reads from the parser
:viever
and :item
are the top-level keys here
so there is definitely the concept of top level keys, which is what I am slowing getting to 😜
this page has some nice examples
For example [{:a {:b {:c [:x :y]}}}]
(from that tutorial), only :a
will trigger a read
is there a convention on defining a top level key for ident lookups? e.g. I have an ident :item/by-id
… I want to use it as a root … what is idiomatic?
I’m thinking make it a parameterized read, [(:item {:id 2})
, but wondering if that is the way to go
that's perfectly possible
or I guess thinking about it … you assign a root and just update its ident … [:active/item]
that's how it'll probably work out
you have a list of items normalized in :items/by-id
Then you'll probably have some query like [{:items/list [:nr :name :description]} :items/active]
two top level keys here: :items/list
and :items/active
update: so you can do [{[:item/by-id 2] [:name :description]}]
… the read
method matches key :item/by-id
and then the ident is in the env
at :query-root
, so [:item/by-id 2]
, and the query is in the ast
at :query
, so [:name :description]
(defmethod read :person/by-id
[{:keys [query-root ast state] :as env} _ _]
(pprint (dissoc env :parser))
(let [st @state
query (:query ast)]
{:value (om/db->tree query (get-in st query-root) st)}))
oh yea definitely
the tutorial also helps a lot
the one from tony.kay I mentioned
if your read works in the example above, roll with it.
https://github.com/omcljs/om/blob/master/src/main/om/next/impl/parser.cljc — like this lists the AST … so I’m guessing your read methods can get QueryExpr := (EdnKeyword | IdentExpr | ParamExpr | JoinExpr)
and then it goes on to list the ast
stuff 😜
In your read function above you can plug the full-query in om/db->tree
Example: (om/db->tree '[{[:items/by-id 2] [:name :description]}] @state @state)
do you know of any kind of hook-in points for db->tree
? like if I want to make a generated field, but not a root
what do you mean by generated field?
(Have to go, will probably answer tomorrow)
good question, initial thought is something goofy like :user/full-name
but that can just be a function a component calls (e.g. query [:user/first-name :user/last-name]
, call full-name
func). need to think about it more … might not be a real need
@iwankaramazow it looks nice, but doesn't seem to support Om Next. And I don't need clj rendering, I'm experimenting with cljs backend, running ReactServerDOM render to text would be enough, I just need a way to fill in components with some provided parser, without mounting it to real DOM.
a quick glance looks like add-root!
might not care what target is, just passes it to root-render
@hueyp that seems to be a good direction, thanks! add-root! even seems to support nil targets, maybe when I figure how it behaves in such case, it could be a solution.
I’ve been reading up on Om.Next (BTW, for an alpha-release library, the community has really produced a lot of documentation and videos!). One thing I am not convinced about:
transact! component `[(todo/add {:title “Get Milk”}) :todos/list :todos/counts …]
The need for every component transact!
to be aware of all root elements that may be affected by a mutation. I understand the performance reasons for it, but can someone comment on how well it works in practice? Is there a lot of head-scratching when something is not re-rendering as it should? Sounds like a source of irritating bugs.