Fork me on GitHub
#om
<
2015-12-29
>
mudphone01:12:42

@anmonteiro: oh man, I tracked my refresh problem back to my server (I’m using the Phoenix Framework). It is apparently serving a new page, whenever I update my CLJS.

mudphone03:12:01

@crocket: I got a sensible cider + figwheel setup going in Emacs. he’s not here

mudphone04:12:22

also had to defonce my reconciler, is that normal?

anmonteiro04:12:09

@mudphone: good to know it's working; it's normal do have to defonce the reconciler

bplatz06:12:49

I'm having an error after merging an ident in, using datascript. The specific error is: Uncaught Error: Invalid key [:user/id "020b3e79-9f17-484c-9ea3-9f2428810072"], key must be ref or keyword

bplatz06:12:04

I'm using a custom :merge-ident function, which seems to be working fine, so I'm not sure why this is popping up. It is happening in (key->components [_ k] ...)

bplatz06:12:08

Any thoughts?

Oliver George06:12:44

I've been playing with a minimal om.next / sente setup today. Sharing here in case anyone is interested (also would love suggestions). https://github.com/olivergeorge/stripboard/tree/master/src/stripboard

Oliver George06:12:42

(My idea was that perhaps watching a server side atom is a nice way to visualise data while programming. Not sure if the idea has legs.)

jimmy10:12:20

hi guys can anyone give me a good example of parameterised read query expression ? I have tried this but it is a mutation ...

'[(project/page {:selector [:project/name
                                                {:project/developer [:db/id :developer/name]}]
                                     :project/name "Phu My Hung"})]

jimmy10:12:23

I got it, replace project/page with :project/page would turn it into read

jannis10:12:25

@nxqd: Try [... (<query expr> <param map>) ...]. You're close, except your project/page is not a query expression.

jannis10:12:49

Yep simple_smile Om treats (<symbol> ...) as a mutation

jimmy10:12:09

thanks for your help 😄

artemyarulin12:12:39

https://raw.githubusercontent.com/artemyarulin/ktoa/master/om-next-cross-platform-sync-state.gif With om-next when we have all the app state in one place it almost trivial to share it between different clients during development. I’m really happy with it simple_smile

jimmy13:12:06

@artemyarulin: your demo is sick. I'm looking forward to it 😄

nha14:12:29

I am blown away. Is there a repo somewhere ?

artemyarulin14:12:35

@nha: Kinda this as well. I’m working on om-next lein template currently which allows to do the same, but without spending too mach on environment setup

artemyarulin14:12:08

mobile development discussing goes in #C0E1SN0NM channel, welcome!

nha14:12:06

@artemyarulin: Awesome ! I am no mobile dev, but I will definitely check it out as soon as it matures a bit simple_smile

nha14:12:14

How do you sync state ? (I mean, atoms with watchers ? om ? websockets ?)

artemyarulin14:12:30

add-watch for app-state atom which calls figwheel custom ring handler which then append string with reset! (parrot) call to the file with a state, which then figwheel recompile and distribute across the clients. Hacky as hell, but it works and I spend 1 hour on this staff simple_smile

nha14:12:44

wow ^^ I see ^^I would probably have spent more than 1 hour

artemyarulin14:12:33

It’s not that hard simple_smile I guess I should create an issue for figwheel - it has a open websocket already, maybe we can utilise that

nha14:12:49

👍 anyway that's pretty cool ! I am very excited about a full stack clojure

rhansen14:12:34

Does anyone else experience that the parser reader is triggered when updating the component local state?

anmonteiro14:12:28

@rhansen: that's expected behavior AFAIK

anmonteiro14:12:23

Updating local state schedules re-rendering which in turn calls reads

anmonteiro14:12:44

I could be wrong

rhansen14:12:23

@anmonteiro: You’re probably not 😛

dnolen14:12:49

@tony.kay: what you wrote looks like a typo?

deplect15:12:39

How would you structure a multiple view single page app, I have experimented with various approaches now falling back to doing a new add-root! on every "page" switch, essentially mounting a new om.next class. The thing I want to solve is pass routing params to the root component (class) being mounted, after reading for a while through the code it seems its not that trivial, is there something I am missing?

anmonteiro15:12:57

@deplect: I have solved that using set-query! on every route change; I've put together a lein template which you might find useful (https://github.com/anmonteiro/aemette)

rhansen15:12:58

I have a nested query where :remote-read should, well, trigger a remote read:

[:url {:page [:test :remote-read]}]

rhansen15:12:51

Currently im using the following for the :page reader:

(defmethod reader :page [{:keys [parser query] :as env} _ _]
  {:value (parser env query)})
But this doesn't work (won’t trigger a remote read) as parser only returns the value of the query. How can I know if a sub-query specifies :remote?

deplect15:12:25

@anmonteiro: Thx! Browsing through your template gave me some valuable inspiration, essentially the componentWillUpdate in combination with the IQueryParams part in the ..components.app stuff was the pattern I was looking for simple_smile

glv15:12:58

I’ve run into a performance issue with om next where the speed of transacting a new value into the app state is affected by the size of the new value. (As in: if the new value is a map containing a 100-element vector, it’s pretty snappy. If it’s a map containing a 5000-element vector, it gets really slow.) I haven’t found the actual culprit yet, but it seems to be something about how the mutate expression is handled by the parser.

glv15:12:39

If I wrap the value within the app state in an atom, and then deref the atom whenever I need to use that value, things speed up dramatically.

dnolen15:12:26

@glv you must bound your queries

glv15:12:02

say more words, please? simple_smile

dnolen15:12:09

Om Next is completely anti putting large amount of query driven data into the ui data tree

glv15:12:37

Well, it’s not really query-driven, as I understand that. None of the queries look inside that value.

dnolen15:12:11

ok then you should have no trouble creating a minimal case that exhibits the issue

glv15:12:21

That’s what I’m going to work on next.

dnolen15:12:24

and open an issue for that

peeja16:12:14

So, that should help. simple_smile

anmonteiro16:12:44

@peeja: yep, no new ideas there wrt. the architecture, I just made it work with Om Next

jplaza16:12:16

@dnolen: you said yesterday that you wouldn’t build now anything for production using Om Next. When do you estimate to have a beta version?

peeja16:12:57

@anmonteiro: Well, you pushed the controller architecture into Om mutations, which—while it's the obvious thing—is also good to see written out before we go transform the giant app. So thanks!

anmonteiro16:12:58

@peeja: right, but the controllers are still used to trigger those mutations when the channels receive something

anmonteiro16:12:45

@peeja: I also have some ideas wrt. remoting that I didn't include in the template, if you want some suggestions later

peeja16:12:35

Yeah, I'd love to chat about that sometime

dnolen16:12:30

@jplaza: January February?

noonian17:12:17

@dnolen: is it intended behavior that a root component that implements IQuery but returns an empty vector for its query will not be rendered? I run into this when I’m starting out since I don’t need any dynamic data yet and just want to get a static view up. In order to render a constant UI that doesn’t use app-state you need to add a bogus key to the query just to get add-root! to work.

peeja17:12:12

@noonian: If you don't implement IQuery at all, you should get the entire state

peeja17:12:32

(Also, I believe, if you implement it to return nil instead of [])

noonian17:12:38

ah, yes that is the case

noonian17:12:05

great, nil seems to work now

jplaza17:12:49

@dnolen: Cool, perfect timing. I expect to have a beta too around march

tony.kay18:12:50

@dnolen: It is, in fact, a typo (not in code, in slack): [ { [:current-user '_] [{:things (om/get-query Thing)}] }]

dnolen18:12:28

@tony.kay: seems to me that should work

tony.kay18:12:09

db->tree is fine with it, but transact!/`set-state!` cannot find the query for the child that renders Thing. I submitted an issue

jdubie19:12:58

I just updated my routing example to use the *total query* approach in favor of using set-query! on the root component. My implementation of the set-query! approach was probably naive but switching things to use total query removed a lot of logic from my components and made things much more testable. added an example of this to the README. https://github.com/jdubie/om-next-router-example

deplect20:12:10

@jdubie: yes I was just experimenting with the set-query! approach and it doesn't seem to be a natural solution. Your total query strategy seems more natural, like the way you pass along the route->query map and using it to resolve the query belonging to the component. Drawback of this approach is when you are in an interactive development flow and you change the query in the component you would have to repopulate the route->query map no? Wondering if it would make more sense to just do the resolving completely in the parser?

jdubie20:12:31

@deplect - thanks for taking a look. glad you agree. re: interactive development. i use figwheel and have defined route->query in a namespace that always gets reloaded when anything changes so can interactively change queries. i would warn against building that map in the parser - queries shouldn’t know anything about components

dnolen22:12:10

people opening issues

dnolen22:12:18

do not link to external repos

dnolen22:12:24

I will not look at them

dnolen22:12:36

in future if you do this I will simply close the issue w/o further comment.

dnolen22:12:59

changes around error handling means I'm killing off the possibility of ever passing nil props

dnolen22:12:22

I don’t see any value in supporting such a thing and it’s a simple way to detect that an error has occurred

dnolen22:12:50

that is … you should never pass nil but we may internally pass nil for internal error handling reasons

glv22:12:21

@dnolen: Thanks for setting me straight on that. Missed that part of the Contributing doc.

dnolen22:12:42

@glv no problem I need to be more proactive in sending people there

dnolen22:12:52

also people in this channel here and elsewhere should do the same

dnolen22:12:17

issues need to be very high signal / noise or I just will not look at them

glv22:12:50

Makes complete sense

dnolen22:12:54

@glv I’m pretty sure your issue is due to the path marking traversal in om.next.parser

dnolen22:12:33

om.next.parser/path-meta

glv22:12:05

That’s what the Chrome profiler was pointing me to, but I haven’t understood that code well enough yet to see the issue clearly.

rhansen22:12:18

@dnolen: Not sure if you saw this question earlier or not, but is set-state! and update-state! supposed to trigger a query when they are run? They schedule the component for re-rendering, which makes sense, but I had this impression that the component query is only run on mount and on transactions 😕

dnolen22:12:22

information added to the ticket

dnolen22:12:57

@glv not sure when I will get to it since it’s a finesse thing at this point - higher priority architectural stuff needs sorting out first.

dnolen22:12:16

happy to take a patch of course - the idea would be to use the query to figure out what values to ignore

glv22:12:08

No worries … for my actual project, I can use the atom-wrapping trick as a workaround for now, and I’ll try to find time to dig into the code and figure out how to patch it. I’m a bit intimidated by that code, though. simple_smile

dnolen22:12:37

@rhansen some advice as well as any other newcomers to this channel

dnolen22:12:51

do not direct questions at me if your problem would clearly be a stow shopper for actual usage

dnolen22:12:23

assume you are making some simple mistake that other people can answer if clearly the problem would prevent everyone from proceeding

glv22:12:45

Mind if I add a note to that effect to the channel topic?

dnolen22:12:35

@rhansen: also at this early stage referring to source is a really, really good idea

dnolen22:12:35

all calls to set-state! and update-state! must go through this

dnolen22:12:03

all re-render must go through this

dnolen22:12:33

@rhansen: the key thing to understand is ui->props

dnolen22:12:12

it should be self-evident there is no such thing as calling set-state! and not re-running queries

dnolen22:12:34

read the source

dnolen22:12:41

if your expectations of the source are not met

dnolen22:12:46

then we have a bug we can talk about

dnolen22:12:53

at some point in the future this will be less necessary but we are not there yet simple_smile

dnolen22:12:13

if you’re jumping on board a certain level of engagement is going to be required to both advance your understanding

dnolen22:12:16

and the quality of the project.

johannjohann22:12:18

source is pretty interesting to read also!

dnolen22:12:54

also I’m actually very happy to explain how the source works

dnolen22:12:05

less happy to answer the same questions over and over again

dnolen22:12:08

“learn to fish” etc.

dnolen22:12:12

@glv yeah atom wrapping trick works for the time being - will definitely get to it post error handling / routing hooks work

johannjohann22:12:45

@dnolen i wonder if theres a slack integration that would allow you to tag the repetitive questions and build an adhoc wiki--did a little googling and found this. might be useful. https://slack.com/apps/A0FHVR2R0-guru

dnolen22:12:53

@johannjohann: hrm maybe, the problem is not precisely getting the same questions over and over again

dnolen22:12:31

rather newcomers who are just starting out who have questions about anything working at all

dnolen22:12:01

in the longer term hopefully this will get addressed by a cookbook / structured guide

dnolen22:12:34

encouraging the former and kick starting the later are definitely on my todo list for 2016

selfsame22:12:39

have to admit the learning curve is rough

dnolen22:12:57

no disagreement there - it’s very steep

dnolen22:12:13

thus the need for something more structured & hand holding

dnolen22:12:23

from the basic stuff to fully working non-trivial thing

johannjohann22:12:53

yep. its principled, and for good reasons, but i think its somewhat easy to want to fall into old habits of building up stuff--you get maybe 40% there without really taking in the principles, get confused etc

rhansen23:12:13

@dnolen: I should’ve read the source first, but in this case I probably would’ve had the same question. After some brief hammoc time I’m chucking this down to me not understanding the differences between Om and React and will make changes accordingly.

dnolen23:12:58

@rhansen: it’s also easier to understand misconceptions with some minimal example

dnolen23:12:05

"I expect this example X to work"

rhansen23:12:26

I was using component local state to store the contents of several input fields in a form component. But that would be bad in the case of remote queries in the tree.

dnolen23:12:45

rather than vague "does concept Y in Om Next work at all?"

dnolen23:12:59

the later gives no guidance for anybody to understand what you are going through

selfsame23:12:32

the awkay devcard tutorial is great for that

rhansen23:12:56

@dnolen: No argument there, and it should be self-explanitory. I will do better.

dnolen23:12:15

@rhansen: as a rule and really it applies to everyone - when you encounter a problem take the 5-10 minutes to make some smaller case of something that fails your expectations

dnolen23:12:28

this will eliminate tons of lost time of people trying to read each other minds simple_smile

dnolen23:12:03

usually with an example many more people can chip in and identify the problem

dnolen23:12:07

and usually very quickly