Fork me on GitHub
#om
<
2015-11-04
>
maravillas03:11:07

i've noticed that when i have my parser return {:value nil}, a component that uses that respective key in its IQuery impl just doesn't render. given the use of :not-found in the quick start, i assume this is not entirely unexpected behavior, but it's still surprising to me...i'm curious if there's some background i'm missing

leontalbot03:11:45

Hi, this is my first attempt to use Om Next. Disclaimer, I am a beginner. I want to build a form that shows additional fields (questions) when certain inputs get toggled. https://gist.github.com/leontalbot/1d57bb05c063a989757c

leontalbot03:11:57

Don't really know how to do the mutation to add question id to :questions/visibility

leontalbot03:11:46

Anybody have suggestions (and advice to improve my bad coding)?

dnolen03:11:33

@maravillas: just don’t return nil for now

grounded_sage03:11:28

@dnolen: I know you said it's awkward to use Datomic if not using JVM but I'm wondering whether the hassle of using it outweighs the benefits it provides as it would be awesome to use it. I found this https://github.com/edubkendo/datomex but this is using the REST API of Datomic. Which the whole point of Om Next is to move beyond REST am I right?

dnolen03:11:58

@grounded_sage: moving beyond REST is a non-goal, the point is just to not use it when it’s a bad fit - rich client apps

dnolen03:11:35

@grounded_sage: I can’t speak definitively about the Datomic REST interface you should ask on the #C03RZMDSH channel for more informed opinions

grounded_sage03:11:02

Cheers. Will do. Just good to confirm the Om Next side of things

leontalbot03:11:13

(going to sleep)

dnolen04:11:15

@leontalbot: you are very close. You just need to think about your app state as a database. In :questions/visibility you want the elements to be idents and then everything should just work. I would make sure you really understand the normalization wiki page.

taylor.sando04:11:22

@dnolen what do the cognitect people use for a lot of your front end apps? Have you guys started to move towards using om?

dnolen04:11:25

we use what the client uses

dnolen04:11:40

which means it could be pretty much anything including Om

taylor.sando04:11:40

@dnolen has there been much discussion of best practices of how to model things like widget-specific properties, such as what has focus? Or editing existing "model" values. You can do it in the app state, or you can do it locally, in the component state, i.e. react state. My preference on my projects has been keeping as much state as explicit as possible, and in the app state, usually datascript-backed. However, I was interested in what other people have found.

dnolen04:11:20

@taylor.sando: the only real answer to that is “it depends"

dnolen04:11:40

anybody that says otherwise is just focusing on their own problems and not looking at the bigger picture

dnolen04:11:56

but avoiding component local state unless absolutely necessary is a good rule of thumb

taylor.sando04:11:11

I could see local state being used for very component-related things, such as d3 properties.

dvcrn05:11:18

hmm any thoughts on the following? I have a map. Whenever the user moves the map, I want to pass the lat and long to my server so that the server can return information based on that

dvcrn05:11:43

what would be the best way to stuff this information into a query?

taylor.sando05:11:54

From what i have read, your query is like (:some-namespace/fn-name {param: val}), wrapped in transact call, om/transact!

taylor.sando05:11:31

Your mutate function needs to specify that it is a remote call. The currents docs aren't great for demonstrating how remotes work.

dnolen06:11:53

@dvcrn: seems like you want to encode something like :user-lat-lng or something like that then there is a key that hold extra info that can be read

dvcrn06:11:31

ah right, I completely forgot that you can pass parameters, whoops

dvcrn06:11:05

Trying my first 'real' app right now to put everything together

dvcrn07:11:46

to re-phrase my question: My component tree looks like this:

RootComponent -> MapComponent -> MapPinComponent
Queries: - MapPinComponent: [:id :lat :long] - MapComponent: [{:app/pins ~subquery}] Now what should the RootComponent do? Can I just do something like: [~subquery] or would it be smarter to embed everything inside a :app/data field? [{:app/data ~subquery}]

jonpither07:11:25

Is there any rationale (debunked or not, just want the argument), for not using cursors with Om Now? Best I can find is http://diogo149.github.io/2014/10/19/om-no/, but I'm not clear this is problem likely to bite or not.

dvcrn08:11:51

man this is complex. I have a python backend and writing something that is able to understand everything is really difficult. Does anyone here already have something working in python that I could peek into?

dvcrn08:11:51

I give up. Time to drop python and give clojure on the serverside a shot

leontalbot11:11:51

@dnolen: Thank you! It makes sense simple_smile I'll go through the normalization wiki page.

dnolen12:11:17

@jonpither: nobody wrote up anything that was particularly precise about the problem. but I can summarize.

dnolen12:11:58

a) users had to be aware of the caching nature - and thus had to understand issues of asynchrony

dnolen12:11:09

b) hardwired a particular storage mechanism (in-memory EDN tree structure) - challenging to wire in new storage. the default made it difficult to model identity

dnolen12:11:32

it’s very likely that neither of these problems are insurmountable - but the co-located query approach delivers the same conceptual functionality while solving both of these issues and bringing a lot more benefits

dnolen12:11:40

@dvcrn: can’t argue with using Clojure but also curious about what makes this so hard in Python

iamjarvo15:11:30

is there a way in the repl to see the javascript that the om component will render? (using react-native)

iamjarvo15:11:00

I am trying to add a NavigatorIOS to my app and I am pretty sure I am doing it incorrectly. here is my code, error at the bottom

dnolen15:11:18

@iamjarvo: might also want to take a look at what @dvcrn is doing

iamjarvo15:11:26

@dnolen: thanks. Are you referring to his om.next work?

dnolen15:11:45

yeah, he did a blog post about om.next + React native

anmonteiro16:11:54

@iamjarvo: FWIW I also couldn't add a NavigatorIOS to a react native app

anmonteiro16:11:06

the problem is the passProps property

anmonteiro16:11:17

it expects a JS object as props

anmonteiro16:11:42

but then passing a JS object as props to an Om component doesn't seem to work

iamjarvo16:11:56

@anmonteiro: is your code on github?

anmonteiro16:11:39

which bits would you like to see?

iamjarvo16:11:01

your approach to adding the navigatorios part

anmonteiro16:11:24

I have since deleted that since I assumed it wasn't possible

anmonteiro16:11:29

and switched to using the Navigator

anmonteiro16:11:15

also,you didn't share your code

anmonteiro16:11:22

in your message above

anmonteiro16:11:29

maybe by mistake?

anmonteiro16:11:36

oh you're not using Om Next

iamjarvo16:11:28

nope, i’ll check out om.next later today

anmonteiro16:11:48

is it your first time using Om?

anmonteiro16:11:05

I think your "search" component should be a function of 2 arguments

iamjarvo16:11:19

it should take data and owner

anmonteiro16:11:00

(defn search [owner]

anmonteiro16:11:05

this is how it looks like

anmonteiro16:11:12

maybe it's not required, I don't remember

iamjarvo16:11:12

I’ve used om for web stuff and have been able to just pass owner

anmonteiro16:11:44

yea I really don't remember, at a first glance this was what smelled to me

anmonteiro16:11:03

anyway, the error you're getting, I think it's pretty generic

anmonteiro16:11:18

I've also struggled with React Native's errors when using clojurescript

anmonteiro16:11:47

ATM I haven't been able to have it report e.g. Om's runtime errors

iamjarvo16:11:23

I am thinking the error I am getting is due to a javascript error and the code is bailing at that point

anmonteiro16:11:45

it's what I'm trying to say

anmonteiro16:11:54

let me try out your example

anmonteiro16:11:06

can you see anything else printed in the console?

dnolen17:11:09

@iamjarvo: the owner thing is gone now, defui makes real React JS classes

dnolen17:11:14

no more indirection

jeremyraines17:11:51

anyone gotten devcards working with om.next, specifically with lein-figwheel?

tony.kay17:11:34

@jeremyraines: Look back through the history of messages for the kanban stuff from Jannis

jeremyraines17:11:08

ok. I’m looking at their source now. Two issues I’m hitting is 1) they use boot, and I’m using lein-figwheel, and I’m finding I have to run lein cljsbuild to have the cards stuff build, rather than figwheel handling. Also the browser doesn’t connect to the repl on the cards page. 2) My defcard looks like theirs, but I get Invariant Violation target container is not a DOM node

jannis17:11:00

@jeremyraines: I'd suggest getting figwheel and devcards to work without om.next first. It seems like you're having trouble setting things up, so I'd start solving that first.

bplatz17:11:45

I am just part way done with a fairly nested UI backed by datascript and I'm consistently getting query time warnings. Everything is rolling up to the root component. I've seen talk about Ident creating an independent query path, however the primary use case seems to be normalizing data which I don't need. Is there a solution to this that I'm missing?

jeremyraines17:11:11

@jannis OK, trying with a sablono one. Can you help me understand what’s wrong with this? I still get the invariant violation:

clojure
(defn foo []
  (sab/html [:div {} "hi"]))

(defcard simple-component
  "Test"
  (foo))

jannis17:11:51

@jeremyraines: defcard expects a function that creates a React element, not a React element.

jannis17:11:10

So try (defcard simple-component "Test" (fn [state _] (foo)))

dnolen17:11:17

@bplatz: you need think more about how queries work

dnolen17:11:11

if you’re always rolling up to root you’re definitely misunderstanding the basics - to be fair it’s not obvious and you should ask questions and people will answer when they have time

dnolen17:11:55

getting query errors almost always means there’s just something wrong with your query

dnolen17:11:15

(assuming you haven’t found a bug which is at this point still very possible)

jeremyraines17:11:15

@jannis: same error. I’m also confused about that statement b/c I’m looking at this: https://github.com/bhauman/devcards/blob/master/example_src/devdemos/two_zero.cljs#L71-L85

jannis18:11:23

@jeremyraines: You're right, sorry. It should be able to handle that.

jeremyraines18:11:41

hmm, ok. thanks for your help so far. your kanban project is a great resource. Going to try going back a version or several to see if I can land on a working version

jannis18:11:18

@jeremyraines: It's certainly not an Om Next problem but might have something to do with how you're setting up devcards. Calling start-devcard-ui! in the right place, passing :devcards true to the cljs compiler. Stuff like that I would investigate.

bhauman18:11:27

@jeremyraines: I think it may be easier to follow the devcards Readme. Jumping into the middle like this is always going to be painful

bplatz18:11:03

Thanks @dnolen, fair enough on queries rolling up to the root being me misunderstanding. I'd appreciate anyone pointing me to an example where an alternate method is used, the ones I've seen seem to to all roll up to root. @tony.kay in his tutorial also states "The overall query must compose towards (one or more) root".

jeremyraines18:11:10

I’m doing my best to do so. I can’t use the most basic part because I have an existing lein-figwheel project.

jeremyraines18:11:29

most of what I have is copy-pasted from the README

tony.kay18:11:42

@bplatz: (one or more) is in case you have more than one om-next app on the same page (e.g. targeted at different divs with add-root!)

tony.kay18:11:50

I should probably clarify that

jannis18:11:04

@jeremyraines: I suggest taking this to #C09GR9UJC.

dnolen18:11:50

@bplatz: there is no alternate method

dnolen18:11:59

you have sit down and understand how queries work period

dnolen18:11:31

if you don’t implement IQuery you cannot transact

dnolen18:11:10

you may need to create a query expression to move control down and make your application more modular

dnolen18:11:28

that’s really about it

bplatz18:11:44

Thanks. I make extensive use of iQuery on (most) components, and roll up using om/get-query to build a large nested graph. Most components are represented using a join, and I recursively call the parser to get the nested joins (in order to simplify/distribute the read functions).

bplatz18:11:42

I'll review docs an examples again to see if I'm missing something. My concern is that I'm already at 20+ms query time and just part way done, although the app itself does not seem laggy.

dnolen18:11:53

@bplatz: ok then I misunderstood what you were saying

dnolen18:11:07

that’s fundamentally how Om Next works, this is exactly the same as Relay

dnolen18:11:22

the root has the total query composed via om.next/get-query

dnolen18:11:29

@bplatz: 20ms query time if you’re not doing animation is no big deal

dnolen18:11:52

(it will be a big deal on mobile however)

dnolen18:11:10

busy with ClojureScript this week, but I’ll get around to the path optimization stuff

dnolen18:11:33

this will allow you to laser in on only the part of the query that needs to rerun

bplatz18:11:08

@dnolen Perfect, that was my question. I had seen some talk that components implementing Ident could do that and was asking if that was the case (as my use of datascript seems to obviate the need for Ident).

dnolen18:11:46

@bplatz right you’ll still want to be able to run the narrowed query regardless of DataScript/default DB

dnolen18:11:56

it’s a known issue - and it will get resolved before we go beta

monjohn18:11:08

@dnolen: the process.hrtime is a known issue?

dnolen18:11:22

@monjohn: fixed in master or should be as far as I know

dnolen18:11:28

ClojureScript master

dnolen18:11:35

release coming on Friday

dnolen18:11:50

however note everyone will need to upgrade their tooling to make the jump

dnolen18:11:01

fixes have been applied to Boot, cljsbuild, and Figwheel

monjohn18:11:14

@dnolen: got it. Thanks.

noonian18:11:07

@jeremyraines it might be sablono causing the error too. I recommend installing a sablono snapshot locally (the snapshot version has updated react deps) and also I had to exclude react from devcards deps.

jeremyraines18:11:54

good to know — thank you

martinklepsch19:11:25

are there any thoughts yet wrt migration paths from Om Now?

martinklepsch19:11:23

I assume I can’t just mix components of the different versions in the tree?

dnolen19:11:34

no thought about migration path yet and there probably won’t be for a while

dnolen19:11:17

after things settle down will spend some time on it, at the least will support both in the same repo for forseeable future

martinklepsch19:11:32

Cool, thanks for the update.

drcode22:11:31

Just out of curiosity, can someone who knows Relay and/or Falcor give me a quick yes/no if they are also friendly for client-only data stores, like Om is? (Exploring options for a dayjob javascript project which won't have a remote back end)

drcode22:11:45

(Thanks in advance for any answers simple_smile

dnolen22:11:10

yes Falcor should definitely be, Relay should be as well though - https://facebook.github.io/relay/docs/interfaces-relay-network-layer.html

dnolen22:11:27

I would probably go with Falcor since it’s considerably simpler

dnolen22:11:48

just fixed the getInitialState issue

dnolen22:11:22

getInitialState -> initLocalState

dnolen22:11:36

also can disable logging by giving reconciler false-y :logger option

tony.kay23:11:33

@dnolen: Planning to support recursive pull notation ala Datomic? E.g. [:a :other {:c ...}]

tony.kay23:11:48

I remember you showing an example, but I'm on alpha 14 and it just says it is not ISeqable

tony.kay23:11:54

when I try it

dnolen23:11:47

@tony.kay: planning but it’s not there yet - net thing on my list of things to do

dnolen23:11:53

will require a few steps

tony.kay23:11:06

ok, thanks. Was trying it out too soon simple_smile

dnolen23:11:05

added a simple way to abort parsing in the case of some unrecoverable issue https://github.com/omcljs/om/commit/fec028c433e7fb5acd97e2a3a4a6f9ddd10465df

dnolen23:11:15

more useful in the server case