Fork me on GitHub
#om
<
2016-01-26
>
jimmy01:01:18

@tony.kay: Can you reference me when you complete the wiki for focus-query. I might need the same thing for my application. Thanks simple_smile

tony.kay01:01:38

The docstring that was already on it was sufficient, though

jlongster02:01:18

this is not a valid query, right? [:items [(:field {:arg 1})]]

jlongster02:01:37

has a param on a sub-select

jlongster02:01:01

om doesn't throw, but the ast has :dispatch-key of (:from_acct {:id 1}) which seems wrong

dnolen03:01:58

you can’t have a query root w/o a join like that

andrewboltachev03:01:22

;; Idea for "hideable" components:

(defui Tabs
  ; No IQuery presented
  Object
  (render [this]
          (om/factory-show-if
            this ; reference to parent component
            '(= :route-path "news") ; this has some specific format
            NewsTab)
          (om/factory-show-if
            this
            '(= :route-path "about")
            AboutTab)
          )
  )

andrewboltachev03:01:58

It would be possible to figure out, which queries are active based on values of other queries. If framework would suppot that, then routing wouldn't need to set-query!

andrewboltachev03:01:31

show-if stolen from Angular (it has thing named ng-if)

andrewboltachev03:01:05

Do you think guys such is possible (and makes sense) to implement in Om Next?

jimmy03:01:57

@dnolen: I encounter a weird problem regarding read. When a component hits the server :remote, the data is fetched and displayed correctly. But when it's being re read from local state ( the data is already in local state ) then the props of that component is reset to nil even if I can see that there is data in read function. What could possibly go wrong here ?

andrewboltachev03:01:58

;; 2nd sketch

(defui Tabs
  static om/IRelativeQuery
  (relative-query [_] ;; query, that depends on state itself
    `[:case
      (= :route-path "news"
          ~(om/get-query NewsTab)
          )
      (= :route-path "about"
          ~(om/get-query AboutTab)
          )
      ]
    ) ; looks ugly, but it's just to show the principle

  Object
  (render [this]
          ;; ...
          )
  )

jimmy03:01:57

@andrewboltachev: how about just using simple if and set-query! ?

andrewboltachev03:01:18

@nxqd: I tried to use set-query!, wrote a lot of code but it failed for me. I'm for sth simpler anyway

jimmy03:01:13

how does it fail ? because due to what I see it should work. People use set-query! to change route of the app, it should work the same way for local component

andrewboltachev03:01:07

@nxqd: Hard to remember all things, it just were messy. When component were rendering it were receiving old query, for example

andrewboltachev03:01:15

As for me, it seems like we need to add it one more thing: ability to "hide" components

jimmy03:01:46

in the concept of om, tree > ui

andrewboltachev03:01:47

I.e. to hide component and it's query

jimmy03:01:55

if you want to hide something, you just hide its query

andrewboltachev03:01:16

set-query! is "destructive" operation, i.e. there's a reason it has bang in it's name

andrewboltachev03:01:45

but declarative is always simpler

andrewboltachev03:01:10

Anyway that's in my opinion, based on what idea I had just now. Thanks for your response @nxqd !

tawus04:01:24

Hello everybody. I am trying to get my head around om.next. I have experience with om (om.prev). I tried om-tutorial by @tony.kay. It is really helpful. Now I am looking at the parsing.cljs from om-tutorial. https://github.com/awkay/om-tutorial/blob/master/src/main/om_tutorial/parsing.cljs. I still have not been able to understand what is going on there with db-paths. Can somebody help or share some pointers !

tawus04:01:45

@tmorten: I am doing something similar with forms. I used componentWillReceiveProps for copying the props to state. I too stumbled on the anti-pattern article and am interested in knowing whether what we are doing falls into that pattern.

jlongster04:01:01

@dnolen: thanks, oh, I actually meant [{:items [(:field {:arg 1})]}], which is a valid query I see

tmorten04:01:30

@tawus: Are you talking about queries? If so, check out this from @anmonteiro: http://anmonteiro.com/2016/01/om-next-query-syntax/

tony.kay04:01:01

@tawus: what, in particular, is your question?

tmorten04:01:56

@tawus: I don't know if getInitState is working at this point, anyway. I get a warning and my getInitState is never called in the component

tony.kay04:01:00

db-path is something I invented in that particular example code. It is not Om-specific. In fact, you’d be better off using db->tree for most everything at this point, and ignore how I did it there unless you need special parsing.

tmorten04:01:49

@tony.kay: Speaking of db->tree, do you know how deep db->tree will go into the tree...does it have a limit?

tmorten04:01:33

For some reason some of my items deeply nested are showing up as empty, i.e. :persons [{}]

tony.kay04:01:36

Though there is built-in graph loop detection on recursive queries

tmorten04:01:59

That's what I have then...it would be recursive

tony.kay04:01:24

I recommend dumping your raw database and make sure it is all normalized as a graph using (cljs.pprint/pprint @reconciler)

tony.kay04:01:42

by recursive, I mean you used or a limit number in the query

tmorten04:01:47

It is indeed. and they are inside the top level idents

tmorten04:01:37

Or I should say the nested items are appearing there, just not inside my component props

tawus04:01:28

@tony.kay: That was my actual concern. Do I need to do all this to get things to work. (as I said I don't understand that parsing.cljs part yet) . BTW, Thanks for writing the tutorial and making things easy for newbies !

tony.kay04:01:58

@tawus: Trying to get permission to open-source our other helpers we’re developing at work. They make it pretty dreamy. But the basic blocks are there. Our production code has a grand total of about 6-8 lines of read code…there is a little extra work you have to do around idents, but for the most part db->tree is the work horse.

tony.kay04:01:20

@tmorten: I’m running alpha29 off tip of master. There may have been a patch related to recursive queries in there since the last release. I wrote a bit of that recursion code, and I don’t remember where it merged…but it is pretty well tested

tmorten04:01:54

@tony.kay: I'll take a look at alpha29 and see if that fixes it. Thanks again for your help

tawus04:01:15

@tony.kay: That would be really helpful. Are you using datomic ? I am into early stage of development of our new app (web, mobile) and we are using rest api (liberator) at the backend. Will most of the stuff/helpers apply to rest based services too ?

tony.kay04:01:20

We’re using Datomic, yes. The helpers we have will not work as well in the particular use-case you’re describing, as we assume you’ll want to talk EDN over the wire to the server…since that makes the plumbing trivial. Technically, you can morph it on the client (via the parser or in send), but that is definitely not what we are aiming for.

tony.kay04:01:49

I could see SQL adapters being pretty easy on the server, but REST…yuck 😉

tony.kay04:01:10

We supply REST endpoints for our legacy apps, but I don’t use them from new code

tawus04:01:05

Hmm... thanks. May be it is time to look at datomic. simple_smile

jimmy04:01:07

@tony.kay: I encounter a weird problem regarding read. When a component hits the server :remote, the data is fetched and displayed correctly. But when it's being re read from local state ( the data is already in local state ) then the props of that component is reset to nil even if I can see that there is data in read function. What could possibly go wrong here ?

tony.kay04:01:57

I am a bit spoiled by it, but I’m not necessarily suggesting you dump your entire back end…just that the abstraction of using EDN over the wire is nice. REST is a less-expressive thing, so using the EDN on the wire is nice. Once on the server, it isn’t that hard to transform it to real operations…esp for the mutations. Queries are a little harder, but not that bad…and you can always ignore the “details" of the query and send back what you “know” the client wants.

tony.kay04:01:26

@nxqd: Common problem: forgetting to wrap the return value in {:value … }

tony.kay04:01:58

other possible problem: failing to pass the data down through the tree (manually)

tony.kay04:01:57

path optimization (if turned on) could also trip it up if you do it wrong

tony.kay04:01:04

lots of things simple_smile

jimmy04:01:13

@tony.kay: can you elaborate more on the latter ? I double check the function, it does return value the through {:value }. And since, it does display data correctly when the component mounted, this should work correctly. The problem occurs when the component is re rendered.

tony.kay04:01:35

do you have pathopt true on reconciler?

jimmy04:01:53

no, I don't have one

tony.kay04:01:11

I would suggest printing some trace statements through your read code and see how it is being called. Om focuses queries when it does re-rendering, so your read code may be making an assumption about what it is being asked that is wrong for the re-render.

tawus04:01:32

I understand. We have used liberator-om, pedestal-om and tried a few other things.Trying a datomic/ring-compojure at this stage of development shouldn't be a big problem as long as the returns are worth it. Also along with react native, it looks like something worth trying.

tony.kay04:01:29

can’t speak on react native…I got out of mobile a while back…tiring business simple_smile

tony.kay04:01:21

We’ve done a lot of work to make our stack easy and simple. Datomic was a big help when combined with Om next…actually it was the other way around, since that’s the order of our adoption.

jimmy04:01:43

@tony.kay: I have put the trace to print out the returned {:value, it does print exact same thing when component first mounted and when it's re rendered.

tony.kay04:01:18

@nxqd latest version?

jimmy04:01:26

yeah I'm on latest om

tony.kay04:01:39

alpha28, or tip of master?

jimmy04:01:44

tip of master

tony.kay04:01:22

k. me too. I’ve not had such a problem, so it is likely in your code. If you dump the tree of data (props) in your root, is the data there?

jimmy04:01:39

the data is in the root props

tony.kay04:01:49

Ah, well, then it isn’t in your parse/read then simple_smile

tony.kay04:01:10

are you using om/computed to pass callbacks, or did you mess with the props directly with assoc?

tony.kay04:01:32

from it’s parent

jimmy04:01:46

oh no it's pretty straight forward, I pass the props directly from parent

tony.kay04:01:05

That was a mis-leading question…re-render doesn’t necessarily go through root on RE-render

jimmy04:01:45

yeah indeed, it only refreshes the props of component which has related query.

tony.kay04:01:20

and you are seeing the re-render go through read correct?

tony.kay04:01:36

i.e. your read is getting hit on the re-render

jimmy04:01:46

yes I put a print on the read function

jimmy04:01:02

i does print out exact same data and ( application state )

jimmy04:01:17

in my cases, I just change the set-query between 2 same pages.

tony.kay04:01:28

ah…set-query

tony.kay04:01:38

so this isn’t just a re-render, you’re modifying the query?

jimmy04:01:42

page 1 > page 2 ( data displayed correctly ) then I back to page 1 then to page 2 again

jimmy04:01:50

now the props of page 2 is nil

jimmy04:01:19

yeah I do use set-query! to change the route.

tony.kay04:01:39

I remember there being a pitfall there…but I have not played with set-query! lately so I don’t remember exactly what they were.

tony.kay04:01:03

It has something to do with the fact that the query is declared statically, yet becomes dynamically stored on the component once mounted.

jimmy05:01:39

but due to what I see, even if it changes, if the query is the same and read function returns same data. Then ui should displays things correctly ? but in this case component's props returns nil. I must have missed something here

tony.kay05:01:11

If you can distill it down to a small reproducible bit of code and put it in github gists someone will probably be able to spot it, or will confirm it as a bug

tony.kay05:01:41

@nxqd: You know how to use checkouts?

jimmy05:01:03

you mean I should checkout earlier version of om next ?

tony.kay05:01:36

no, I was going to suggest you use checkouts so that you can put debug statements in Om code for easy tracing in your code

tony.kay05:01:54

the function default-ui->props is used to obtain data for rendering a component.

jimmy05:01:26

yeah I think it should be the way. And I want to learn more about the source code as well.

tony.kay05:01:29

you could try tracing your data through that and see what’s up

jimmy05:01:51

yeah, thanks for helping though simple_smile your tutorial and video is incredible helpful as well

jimmy05:01:01

time to dig to source code 😄

tony.kay05:01:29

have fun! Thanks, glad they helped.

andrewboltachev09:01:03

Hi guys. Can anyone suggest routing approach that doesn't involve reading data for all routes at once?

taylor.sando10:01:26

I would store the active page/route in the application state. In the root component I would query for the active route, something lke :app/route. Using the idea from, https://github.com/jdubie/om-next-router-example/blob/master/src/om_router/core.cljs, I would also construct a big map that could map route to component, however you want to only look up a single value in it--which should come from the app/route value. In order to do this, what you want to do is use componentDidMount and componentDidUpdate, and listen to changes to :app/page in the props. Using the value of :app/page, I would look up the query in the route->component map, and I would call set-query! on the root component, and add what came out of router->component to the query. So your initial query would be [:app/route] After, set-query!, the query would be something like:

[:app/nav
    {:app/page [{:user/home [:user-attr1 :user-attr2]}]]

nano10:01:26

@taylor.sando: Worth mentioning is that the routing example repo you mention doesn't cover child components with parametrized queries.

francoiswirion10:01:14

Are there plans on having ->Component constructor functions from defui?

anmonteiro11:01:56

also not sure why you even would need that

francoiswirion11:01:45

I just thought about how to cut down on the om/factory ceremony for every Component

anmonteiro11:01:00

@francoiswirion: om/factory is mostly about creating a React element from a React Class, but it also has some Om specifics that are need for Om to work properly under the hood

francoiswirion11:01:15

ah ok - but are there (apart from add-root!) any situations where defui wouldn't be followed by a respective om/factory call? If not, couldn't defui call om/factory itself? I was just thinking of defrecord and its automatic constructor definition side effect.

anmonteiro11:01:28

@francoiswirion: there are places where you actually need the class itself

anmonteiro11:01:40

e.g. om/class->any

anmonteiro11:01:30

anyway, assuming you always define classes with capital case and factories with lower case, the following should work:

anmonteiro11:01:34

(defmacro deffactory
  [name & forms]
  (let [lc-name (-> name cstr/lower-case symbol)]
    `(do
      (om.next/defui ~name ~@forms)
      (def ~lc-name (om.next/factory ~name)))))

anmonteiro11:01:18

it can even be extended to support defui's ^:once metadata and factory's options map

francoiswirion11:01:54

yes, defui would continue to generate the class itself as before of course

francoiswirion11:01:38

thanks for the macro! and thanks also for your post on reloadable code, I wasn't aware of ^:once

maleghast11:01:21

I just started digging into Om.now in this tutorial - https://github.com/omcljs/om/wiki/Basic-Tutorial - and I was wondering if anyone could tell me why the tutorial uses a core.async channel to handle DOM deletions, but not for additions? i.e. I am trying to understand if I’ve missed something and there is a specific reason for NOT using a channel to handle additions to the DOM?

maleghast11:01:42

(I am Clojure proficient, but new to ClojureScript)

hmadelaine14:01:25

Hi @maleghast in the tutorial it is said "Contacts don't need to be able to delete themselves, however they should be able to communicate to some entity that does have that power.” In the case of the creation, this is a classic form. Do you plan to learn Om.Now to maintain an existing App ? You do not plan to lean Om.Next ?

tmorten14:01:49

Any body know how to pull in a root table into a query? The entire map? Tried [:person/by-id _]

anmonteiro14:01:49

@dnolen: was going through the issues and was wondering if #436 wouldn't be something good to have soon-ish (in line with the invariant stuff, making Om more beginner-friendly)

nha14:01:51

What is the way to refer to an om.next component in another namespace ? (def comp (om/factory Comp )) ? And then how to use it ?

anmonteiro14:01:20

@nha: require the namespace and your-ns/comp. It's just a function like all others

anmonteiro14:01:34

@dnolen: refers to "Warning if IQuery, IParams & Ident don't appear with static"

peeja14:01:05

This is a bit of an oddball thought, but has anyone discussed keeping style with components, and rolling it up to the root component like a query?

peeja14:01:35

I feel like I want to keep style with components in the same way I want to keep queries with components.

iwankaramazow14:01:13

@peeja: you mean something like the webpack extract text plugin ?

peeja15:01:56

@iwankaramazow: Possibly. That would be a static version of the idea, which is probably better. You could also render a stylesheet dynamically in response to app state changes, using a React-but-for-CSS approach, but that may not be valuable.

peeja15:01:05

Alternatively, has anyone tried giving components' DOM elements automatic class names or attributes based on the component name, to make them easily selectable from CSS?

dnolen15:01:24

@anmonteiro: yeah happy to see someone work on that one

dnolen15:01:32

just need to tweak the macro to check for that problem

anmonteiro15:01:55

@dnolen: happy to do it, just checking in. I was thinking that it would be a good use of the new invariant as well

dnolen15:01:30

@anmonteiro: invariant is a runtime check though, and that ticket is a macro aka compile time check

anmonteiro15:01:52

@dnolen: ah you're right, it won't work; I hadn't thought about it

anmonteiro15:01:12

should we throw, then?

anmonteiro15:01:36

by throw I mean a JVM exception

anmonteiro15:01:46

like you have in collect-statics

jimmy16:01:40

hi guys, I face a problem that : I use core async to communicate events between parent and children, the problem is when I try to get states of child component, the this seems to be outdated ( om/get-state is behind the current one 1 version ). How can we fix this ?

mdhaney17:01:04

@peeja: no need for a separate query-like system for styles - just use queries! Using references, you can easily define "mix-ins" like in LESS/SASS and just refer to them in your component queries, alongside your data and other app state.

tmorten17:01:09

Hello all: has any one else been having issues where db->tree isn't going into nested items in the state? I get [{}] when try to vie from my props in component...

mdhaney17:01:27

@tmorten: are you sure you're letting Om normalize your data? If you pass an atom to the reconciler, normalization is turned off by default, and my understanding is that in that case db->tree doesn't do anything (I.e. follow links/references)

tmorten17:01:21

I have :normalize set to true in reconciler

mdhaney17:01:51

Hmm, in that case I don't know. There are circumstances db->tree can't handle. Someone listed them here the other day, can't remember them right now. Would be nice to have in the wiki.

maleghast17:01:07

@hmadelaine: Thanks, that makes sense. As for Om.Now versus Om.next, I am starting with the stable one, going to see what I can get out of it, and then I will turn my attention to Om.Next. In general I tend to veer towards more stable libraries. I have limited time for investigation and learning, so I like things that I look into to nto change too much underfoot.

tmorten17:01:11

@mdhaney: I am also not passing in an atom

jasonf18:01:27

Hey guys, could anyone let me know how a parser remote :send callback function should present it's data? My UI is currently not displaying the fetched value and I'm not clued up enough to know how the data should be returned, nor how to debug it!

tony.kay18:01:17

@jasonf: There are existing examples of this on the net. The Om tutorial here has a full-stack simulator (all browser side, but fully simulating interactions with a server). https://github.com/awkay/om-tutorial

tony.kay18:01:26

If I understand your question correctly, you're asking what form the data should take when passing it to the callback in send? If so, it should look just like the return map from an Om query...e.g. query = [:a] then callback should be called with { :a 1 }...etc

anmonteiro18:01:18

@tmorten: is your data correctly normalized? If it is, are you passing the correct query to db->tree, according to the piece of data you're trying to denormalize?

anmonteiro18:01:54

If your answers to my questions are both "yes", make a minimal case that demonstrates your issue

jasonf18:01:55

ah awesome, thanks Tony. I somehow haven't stumbled across that tutorial before. You understood my question correctly, and I've attempted to return my data in that format and it hasn't worked. The query has come from a child component however, where [:a] is relative. Does that make a difference?

anmonteiro18:01:02

I'm happy to look at it and figure it out

tmorten18:01:24

@anmonteiro: I am using a root query with a handful of sub-queries...so it is possible I don't have the right query setup down the line. The data is definitely there when I d'ref reconciler

anmonteiro18:01:23

@tmorten: it is important that the query is consistent with the data being denormalized...

jlongster18:01:24

why does db->tree take 2 state args? sorry if this has been asked before, the API docs don't really explain it

dnolen18:01:39

query normalize-tree-node tables

wilkerlucio18:01:45

@jlongster: being the params [query data refs], the data is your real data, while the refs are the ident map, that allows you to send some deep part with the data as base and the refs aside

mdhaney19:01:34

@jasonf make sure you wrap the data with {:value data}, just like you would with a parser on the client.

jasonf19:01:58

@mdhaney: I've tried the too! I think my lack of knowledge is around the root of the data. The component making the remote query isn't the root component, is one node down in the tree. From reading @tony.kay's tutorial docs, this isn't correct and I need to make it relative to the root.

mdhaney19:01:33

@jasonf right, there is always 1 root query that gets sent to the server (same is true on the client, actually). As your app gets more complicated, it's likely you'll need to re-root some of your queries. @tony.kay has a nice description of that here https://awkay.github.io/om-tutorial/#!/om_tutorial.G_Remote_Fetch

jasonf19:01:39

@mdhaney: indeed, going through that as we speak. Wish I'd found this 2 months ago! simple_smile

mdhaney19:01:04

@jasonf something that helped me was to just start simple - single remote with straightforward queries - until you understand the mechanics of everything (there are a lot of moving parts). @tony.kay tutorial is great for more real-world scenarios where you have multiple remotes, tempids, etc. to contend with, but it can be overwhelming until you understand the basics first.

jasonf19:01:06

@mdhaney: agreed, and I thought I was starting simple! I'm currently querying for a server's version number. I'm getting the query to the server fine, it's responding fine, but then it doesn't get displayed. I guess the complexity is that it's on a sub component of the root, which I didn't foresee as an issue. Interestingly, @tony.kay's remote docs don't make mention to {:value ...}. Is this because the tutorial code wraps that under the hood?

mdhaney19:01:05

@jasonf I think so. I've just started really looking into his code and multiple remotes. Will probably begin refactoring towards that next week (have a demo on Monday, so can't do it until after that)

tony.kay19:01:31

@jasonf: The remote docs are sadly unfinished...the parsing is very similar on client and server...the same parser code is used, so the return values from your read/mutates have the same requirements.

jlongster19:01:22

does anybody here use params on sub-keys? like [{:items [(:prop {:arg 1})]}] ? seems like params would usually be the top-level

jlongster19:01:42

I suppose I can see some use cases for that though

jlongster19:01:51

well, heh, nevermind

jlongster19:01:01

if you compose queries up to the root that will easily happen

tony.kay19:01:46

@dnolen: David, merge-idents doesn't propagate the query, it tries to derive it from the indexer/UI. This seems like a bug...we missed this one when porting merge! to take a query. You ok with a PR on that, or is there something I'm not thinking of?

tony.kay19:01:26

I've got a use-case where stuff isn't getting normalized because the UI query isn't the right one to use for normalizing

hmadelaine19:01:02

@maleghast, IMHO if you have no prior knowledge about Om, you should dive into Om.Next, it will be in beta soon.

dnolen20:01:46

@tony.kay: I took a look, yes PR welcome

tony.kay20:01:17

ok, doing now

ulsa20:01:44

in the second part of the om.next tutorial, when incrementing Mary, I get:

=> (parser {:state st} '[(points/increment {:name "Mary"})])
{points/increment :not-found}

ulsa20:01:42

what am I missing?

ulsa20:01:44

@st is normalized

ulsa20:01:59

using 1.7.228 and 1.0.0-alpha22

jlongster20:01:57

@tony.kay: what do you mean by "the parsing is very similar on client and server...the same parser code is used" do you actually share the same parsing code between client/server? (the same read function?)

tony.kay20:01:17

I meant the Om parser is the same code

tony.kay20:01:24

the one dnolen wrote

jlongster20:01:14

@tony.kay: are all of datomic's API synchronous? I'm trying to figure out how to run async queries on the server but still use the parser there with a read function

dnolen20:01:29

re: datomic’s API

jlongster20:01:35

k, need to look at some example code then, thanks

jlongster20:01:48

some docs made me think they were

ulsa20:01:14

oh, I see now that I get an error in JS console:

No protocol method IMultiFn.-add-method defined for type function: function om_next_tut$core$mutate(p__21496,key,params){
...

ulsa20:01:50

Is there something wrong with the multimethods?

(defmethod mutate 'points/increment
...

tony.kay20:01:30

@ulsa: Did you remember to do a defmulti?

tony.kay20:01:43

did you require it if in diff namespace?

ulsa20:01:22

no, all in one ns, then load file (in cursive)

ulsa20:01:36

and gets an error in browser console

tony.kay20:01:45

add-method is a method of the internal implemetation of multimethods.

tony.kay20:01:17

the object you're trying to call it on (which should be a multimethod object...made by defmulti) is borked for some reason

tony.kay20:01:16

look at the source...defmulti just makes an object the implements a protocol, and defmethod is essentially just a call to add, which in turn just adds it to a dispatch table

ulsa20:01:48

(defmulti mutate om/dispatch)

(defmethod mutate 'points/increment
  [{:keys [state]} _ {:keys [name]}]
  {:action
   (fn []
     (swap! state update-in
            [:person/by-name name :points]
            inc))})

(defmethod mutate 'points/decrement
...

tony.kay20:01:56

make sure you didn't accidentally defn somewhere else on that same name?

ulsa20:01:18

just restarted repl to eliminate that

tony.kay20:01:36

that was my next suggestion simple_smile

ulsa20:01:11

weird, just following tutorial and it breaks on this

anmonteiro20:01:51

@ulsa: just copied the tutorial code and ran it successfully with current master

anmonteiro20:01:05

I'd rule out anything wrong in your environment

ulsa20:01:33

maybe 1.7.228 is too old?

ulsa20:01:52

or did you mean om master?

anmonteiro20:01:02

I meant Om master

anmonteiro20:01:16

also using CLJS 228

jlongster20:01:32

how would you run queries within a read function if the query API is async? here's an example, but datascript's d/q function sync: https://github.com/awkay/om-tutorial/blob/master/src/main/om_tutorial/simulated_server.cljs#L22

mdhaney20:01:48

@jlongster Datomic queries are synchronous. Transactions are always async (return a future). AFAIK there is no async query function built in - you'll have to build your own with futures or core.async

jlongster20:01:08

ah makes sense, thanks

ulsa20:01:27

@anmonteiro: I get the same error with Om master

anmonteiro21:01:01

@ulsa: make sure to clean your build?

anmonteiro21:01:17

I don't use Cursive, so can't help you there

anmonteiro21:01:40

but I've seen people reporting Cursive caches builds in this channel; and that was the cause of some trouble they were having

ulsa21:01:48

I tried in terminal, got same error there

ulsa21:01:08

cleaned resources/public/js, no luck

anmonteiro21:01:38

@ulsa: we're talking about the normalization tutorial, right?

anmonteiro21:01:44

are you copying the whole tutorial code?

ulsa21:01:38

yes and yes

ulsa21:01:50

got it to work just now after reloading the browser simple_smile

anmonteiro21:01:19

@dnolen: the patch for #436 actually caught a bug in Om's devcards where an Ident declaration didn't appear with static. Fix also included in the patch

ulsa21:01:38

@anmonteiro: I don't know exactly, but it seems even if I get a prompt from figwheel, I still need to reload the browser anyway, it works now, both from terminal repl and from a cursive repl; the latter is very convenient btw

ulsa21:01:27

just pointed a Cursive clojure.main repl to the same script/figwheel.clj as in tutorial

ulsa21:01:29

btw, tutorial works with om alpha28 too

selfsame21:01:57

any interest in a published version of this html sugar macro? https://gist.github.com/selfsame/12c5ae9179b86760d1e0#file-demo-cljs-L15

dnolen21:01:18

@selfsame: trying to keep all templating stuff out of Om Next

dnolen21:01:38

the only thing along those lines I’m considering is server side rendering support, but that won’t be a DSL or anything

selfsame21:01:47

ah so that would be a #C03S1L9DN topic?

dnolen21:01:26

you’re just talking about shipping a library for other people to use simple_smile

dnolen21:01:33

totally appropriate for this channel

tony.kay21:01:40

@dnolen: Have you ever tested merge-idents with real code?

dnolen21:01:17

@tony.kay: I think at some point I tried it with something yes

dnolen21:01:50

but it’s also one of those things not under a test I believe

dnolen21:01:52

so we should fix that

tony.kay21:01:54

ok...the use-case I'm fixing is a little diff from the original reasoning...was just making sure it works already simple_smile

tony.kay21:01:08

it isn't obvious that it does, but I'll write some tests

dnolen21:01:56

@tony.kay: changing the behavior is not super desirable

dnolen21:01:08

the idea is just that the server can return ident -> new values

dnolen21:01:14

and that will get merged - that’s it

tony.kay21:01:37

agreed. The normalization is failing when I pass in a query, and it is because of the reduce.

dnolen21:01:52

right I understand the missing query problem

dnolen21:01:58

so definitely want to just fix that

tony.kay21:01:03

exactly, I understand

tony.kay21:01:01

It probably works as written...I think I just am confusing myself around the reduce...

dnolen21:01:25

if there’s not a test, hard to know if it works at all simple_smile

dnolen21:01:44

so I’m not eliminating the possibility that it regressed

tony.kay22:01:58

@dnolen: it works...was my misunderstanding...just got it working with a query

tony.kay22:01:22

@dnolen: PR 590 (with tests)

tony.kay22:01:48

welcome. Also tested against our code live in progress, and works fine

malcolmsparks23:01:13

I've got a quick question if anyone is able to help. What does: ' data in the format of an EDN result of a query expression' mean in the context a remote callback, from https://github.com/omcljs/om/wiki/Om-Next-FAQ

malcolmsparks23:01:35

I feel a bit stupid here, I can't quite figure it out

malcolmsparks23:01:00

got everything else working on the remote end, just can't finish off the last bit

anmonteiro23:01:18

@malcolmsparks: it just means that the data passed to the callback must be already unmarshalled

anmonteiro23:01:34

i.e. no JSON/XML etc.

anmonteiro23:01:06

and for the second part: matching a query expression that your UI understands

malcolmsparks23:01:13

right - I've definitely unmarshalled it, but the data isn't appearing in my components

malcolmsparks23:01:44

I must have got something muddled up in the query expressions

anmonteiro23:01:58

I'd start by checking if the data is correctly merged into the app-state

malcolmsparks23:01:13

ah, good idea, thanks

anmonteiro23:01:37

if it is, make sure that your local parser can read the data once it's fetched & merged from the remote

malcolmsparks23:01:24

that's really helped - I can see the state and it's not what I expect, the server data is in there, just not in the right place

anmonteiro23:01:35

@malcolmsparks: so maybe the default merge-tree doesn't work for you and you have to override it

malcolmsparks23:01:18

the problem was that I was returning {:remote (:ast env)} from the read

malcolmsparks23:01:28

I changed it to include a :value key

malcolmsparks23:01:41

{:value v :remote (:ast env)}

malcolmsparks23:01:51

then it began to work

malcolmsparks23:01:15

many thanks for the tips, I was about to give up! simple_smile

malcolmsparks23:01:31

your blog articles have also been very useful

malcolmsparks23:01:39

thanks for those too