Fork me on GitHub
#om
<
2015-12-10
>
noonian00:12:11

Yeah, I definitely haven’t thought through the consequences of these decisions. All I know is that I would like some way to promote a query from a union heh.

tony.kay00:12:36

I will probably end up wanting the same, so I'm happy to keep banging heads on it simple_smile

noonian00:12:18

Ok, well I have to run right now but I read everything in here and I’ll probably be back on later tonight.

tony.kay00:12:33

ok. I'll give it a bit more thought as well

noonian00:12:45

Cool, thanks for talking this out with me

tony.kay00:12:52

@noonian: FYI, I just wrote a test that unions themselves can be promoted to root, and that works. Since unions can imply a one-to-many of heterogeneous type, the server would need that info in that case. So, promoting something deeper would have to imply that there is only one.

bplatz00:12:34

As per my early error inquiry, it was caused by re-definition of the reconciler however I'm not sure why, as I re-define it when I swap out different om-next apps during normal course and that works fine. Changing the reconciler to defonce solved the problem for now. FWIW.

bplatz00:12:48

This has to do with figwheel reloading the file my reconciler is defined in, along with my core namespace.

az01:12:07

@tony.kay: Thank you so much for awkay. Really excellent!

Tim01:12:10

er, is there some lein template to start off on om.next?

jethroksy04:12:14

@tmtwd theres a really outdated one

jethroksy04:12:23

Can't confirm if it works

jethroksy04:12:27

now that i try to search for it I can't find it. It's has an indian name...

jimmy06:12:49

hi guys I try to build a very simple tab component in om next, but the view doesn't change when I mutate the state: https://gist.github.com/rhacker/af34b460e149001b3a06 . Any suggestion would be great. thanks simple_smile

jethroksy06:12:30

@ianchow: yup that's the one simple_smile

nblumoe06:12:35

@tony.kay: the potentially outdated information on your wiki page (huge kudos for that btw!!) are the union queries. as @dnolen pointed out, queries MUST be vectors

roelof08:12:21

Can you use Om if you never have learned react as a beginner. and if so, what tutorial or book it then the best one to learn as a beginner

txus11:12:55

a colleague asked me to build a little app to upload some CSVs with parking spots data and a JSON with a k-nearest-neighbors clustering model to visualize the clusters by color on a map, and it took me exactly one day with om next, client-side only, and getting stuck many times. Now I could build it in a few hours! The more you get about om next it’s scary how fast you can develop stuff.

vijaykiran11:12:55

wow, cool - would you mind sharing some code ?

txus11:12:43

I’ll ask the CTO if I can open source it — there’s nothing sensitive really simple_smile

txus11:12:25

feedback is more than welcome — I’m still struggling with many concepts in om.next simple_smile

octahedrion11:12:52

I've read recently not to use core.async in your UI...I'm using it and it seems to work fine, and seems reasonable for what I'm using it for which is distributing input events (mouse, keyboard) via pub/sub

octahedrion11:12:34

what's a bad idea about this ?

anmonteiro11:12:03

@txus: cool stuff, one question though

anmonteiro11:12:22

why did you define this add-normalized-resources fn?

anmonteiro11:12:40

can you not use tree->db instead?

txus11:12:44

I figured, when new data comes in, I need to normalize it myself

txus11:12:57

didn’t know about tree->db

anmonteiro11:12:30

ok that answers my question 😄

anmonteiro11:12:04

maybe try with it, should simplify the code

txus11:12:09

that’s great!

txus11:12:14

thank you

anmonteiro11:12:21

and probably add-normalized-resources doesn't work for all cases

anmonteiro11:12:21

now I'm just nitpicking and you probably know this, but :normalize true is only needed when you pass an atom to the reconciler

txus11:12:30

ah yeah simple_smile

txus11:12:22

even style critique is very useful to me atm, I’ve seen a few different ways to do things and I’m open to adopting the better ones!

jannis13:12:23

Om Next kanban demo updated to alpha26. Thanks to om/db->tree the reads are much simpler now: http://jannis.github.io/om-next-kanban-demo/ simple_smile

dnolen13:12:04

@octo221: you just need to be careful when pairing core.async with React since core.async go loops are stateful resources

dnolen13:12:16

@roelof: you can learn Om though I wouldn’t say it’s the best starting point for people just getting into ClojureScript. It is important to grasp React fundamentals

dnolen13:12:47

@nblumoe: union queries are the only exception to this rule

dnolen13:12:21

@nxqd I would try to get that working outside of devcards first

roelof13:12:18

@dnolen: any tips how I can learn the reacyt fundamentals as a beginner

dnolen13:12:47

@roelof: there are many online resources on React now, just go through the Facebook material

jimmy14:12:36

I see there are functions like :item/by-name or :item/by-id . Are they some magic functions defined under the hood ? ( in queries )

anmonteiro14:12:33

@nxqd: you should go through the "Components, Identity & Normalization" tutorial

anmonteiro14:12:04

it explains what you're trying to grasp

anmonteiro14:12:36

@nxqd: btw if you can't get your state to mutate in devcards, try transact!ing directly on the reconciler and not on the component

jimmy14:12:06

yes, Looking through how the wiki is written, I can see that there are many methods we can debug and use to add test without interact with the component, very nice 😄

jimmy14:12:21

@anmonteiro: ah, btw on the tab example above, I can mutate the state of component but the view doesn't seem to update accordingly. https://gist.github.com/rhacker/af34b460e149001b3a06

anmonteiro14:12:28

then try without devcards as David mentioned

jimmy14:12:25

woa it works -_-

jimmy14:12:53

thanks @dnolen . Is there anything wrong with devcards ?

dnolen14:12:49

@nxqd: there is yes, you have to be very careful

dnolen14:12:00

I can’t remember if @bhauman has fixed the state issue yet

jimmy14:12:16

awesome, it's good to know simple_smile Thanks for great work

jimmy14:12:28

the best thing ever I have seen on frontend development

peeja16:12:19

Hmm. I'm on [org.omcljs/om "1.0.0-alpha26"], and om.next/query->ast is evaluating to nil

peeja16:12:33

om.next/factory is a function, though

peeja16:12:15

and evaluating om.next/query->ast doesn't give me a WARNING: Use of undeclared Var (which I get from om.next/foobar)

peeja16:12:35

It acts like it's actually defed to nil

peeja16:12:46

Does that ring a bell for anyone?

tony.kay16:12:56

make sure you've cleaned and rebuilt. You'll get all manner of madness if you don't

tony.kay16:12:03

on a version bump

peeja16:12:05

Ah, maybe that's it

peeja16:12:15

Just ran lein clean and re-ran Figwheel, and I get the same behavior. Odd.

peeja16:12:46

#'om.next/query->ast evaluates to the var without an error, so there's definitely a var there.

peeja16:12:09

Bizarrely, it even has the correct metadata…

bhauman16:12:00

@dnolen: :watch-atom false prevents rendering on atom change

dnolen16:12:41

@bhauman OK great, will have to try that out

dnolen16:12:56

and update my own cards so that people understand the pattern

bhauman16:12:43

@dnolen: it will re-render after a compile though, to pick changes

dnolen16:12:10

right that’s fine, can use the atom to persist state like people normally do

bhauman16:12:29

@dnolen: I was also thinking that you can put the whole reconciler in as the init-data param as well

bhauman16:12:41

something to play with anyway

bhauman16:12:24

wow there are there are a bunch more docs in the om next wiki simple_smile

dnolen16:12:16

We've been busy :)

bhauman16:12:51

yes you have!

peeja16:12:04

Aha! That was silly of me. lein clean did nothing, presumably because I'm using Figwheel from a script, and not from lein

peeja16:12:19

(It's my first time running it that way)

dnolen17:12:39

@peeja: you have to tell lein clean what to clean. Figwheel is not involved script or otherwise.

peeja17:12:30

Oh, really? I wonder how I have it set up on my other project, then. I thought Figwheel injected its list of clean targets.

peeja17:12:49

Probably something set up long ago and buried in config…

noonian17:12:36

You will probably want something like this in your project.clj:

:clean-targets ^{:protect false} ["target"
                                    "resources/public/js/compiled"
                                    "resources/public/devcards/js/compiled”]

Tim18:12:58

what is people’s experience transitioning an app from om to om.next?

mattly18:12:08

tmtwd: I’m planning the transition out now, with the hope of starting in beta

Tim18:12:33

om.next is not in beta yet?

mattly18:12:42

nope, alpha 26 was yesterday

mattly18:12:08

long story short: I think I can do the transition piecemeal

Tim18:12:27

interesting

Tim18:12:17

are we supposed to be able to transition piecemeal or is it expected we write the apps from scratch?

mattly18:12:11

I can’t speak to that

mattly18:12:24

this is a larger app with a lot of shared components and behaviors

mattly18:12:45

and I tried to stick to react-isms (ie component state vs. app state) when possible

Tim18:12:50

interesting

naomarik18:12:59

are there any good comparisons of reagent vs om?

naomarik18:12:07

feature wise etc

Tim18:12:12

don’t know of any

Tim18:12:08

it feels like reagent tries to abstract away as much of react as possible

Tim18:12:30

while om.now is more of a thin layer over react with a bunch of extra features

Tim18:12:45

thats how I experience it anyways

Tim18:12:11

both have immutable data structures and use global atoms to manage state

Tim18:12:18

as far as I can tell

noonian18:12:25

I think they have very different scopes. IMO Reagent is more like a thin wrapper around the rendering part of React. It de-emphasises the react component lifecycle and emphasizes readability by defaulting to hiccup syntax. I don’t like how Reagent does change detection though, it uses macro magic and special atoms to update when data changes so I think you either have to use discipline and do things like single atom app state out of convention or you can end up with something that is hard to reason about. Om next is really trying to solve a lot more problems at once like server communication, data duplication/inconsistency on the client etc. Om next is tackling the issues that Falcor and Relay are as well as wrapping React and integrating it into a streamlined package.

tomc18:12:39

@naomarik: There was some discussion about the two on reddit: https://www.reddit.com/r/Clojure/comments/3vk58p/a_rant_on_om_next/ - a good bit of cruft to sift through but some good observations as well. So, reddit.

naomarik18:12:18

@tmtwd: what are the extra features you find worthwhile?

tony.kay18:12:30

@naomarik: It isn't really about features. It's about overall design. The features fall out of that. As engineers we're often way too concerned about features. If that is your criteria, you want Angular. Look at all those features! Form support, libraries, plug-ins. Wow a cornucopia! Om next is about simplicity: Move the complexity out of the UI. Eliminate complexity where you can. It is a "Simple vs. Easy" kind of project. That said, it can also be hard, in that you and your team have to understand higher level concepts to do it "right". You work turns into more thought, less typing. I'd recommend watching David's most recent talk on Om next at the conj, and concentrate on his first few slides about the goals. Features is not one of them simple_smile

naomarik18:12:10

thanks for the insight @tony.kay 😉

naomarik18:12:59

i'm just stepping outside of my rails cave into this world, there's a lot to learn and options to consider... i watched the first 20 mins of the talk a few days ago and i got a bit lost

naomarik18:12:15

but i have a bit more knowledge now it might make a bit more sense

tony.kay18:12:29

There really isn't much of a comparison to Reagent...they are approaching the problem in a totally different way. Lots of ppl are totally productive in Reagent. Lots of people like it. I have a team of 9 working on a product in Om next. There is a lot of "changing the way you thing about the problem". But, my team is confident that the long-term has good implications on maintenance and support, because, as Rich says, your ability to reason about your code is the most important factor in being able to deal with it in the long term. If you're doing quick one-off problems, do whatever is easy for you. Om may or may not be that....

tony.kay18:12:49

the fact that they use React underneath is about the only similarity

noonian18:12:05

Jafar Husain has some good talks on Falcor that might help understand the ideas behind the server communication and links/idents ideas in Om next. Om next also takes the co-located query idea from Relay, although I haven’t explored Relay as much as Falcor so I can’t recommend any resources personally.

tony.kay19:12:18

I'd recommend reading the intro docs to Relay...they are short, easy, and help a lot too

tony.kay19:12:23

particularly "Thinking in Relay"

tony.kay19:12:11

and realize that there will be more up-front work in getting started with Om than something like Reagent. Reagent is trivial to learn...Om takes more effort.

tony.kay19:12:31

long term benefit vs short-term cost

dnolen19:12:58

@tomc yeah I do not recommend reading through that Reddit thread

dnolen19:12:06

the quality of discussion there is depressingly low

naomarik19:12:19

i suppose both are nice to have, i've essentially been able to jump into reagent knowing nothing about react and having just gone through some clojure tutorials to prime myself on the language and get something nice working immediately which is pretty gratifying.

tomc19:12:45

@dnolen: I posted on reddit looking for help finding an apartment in an area good for dogs and it turned into a discussion on how I'll be incapable of raising children, so the fact that that discussion didn't devolve into personal attacks was good enough for me.

dnolen19:12:31

@naomarik: as everyone has said, reagent is quite nice and I nor anyone else here should deter anyone from using it

naomarik19:12:53

yeah @dnolen, im just asking questions trying to suss out the long term benefits om may provide me

dnolen19:12:53

if Om Next seems to solve the problems you care about then it may be a better fit

naomarik19:12:04

i'm watching you talk right now 😛

dnolen19:12:08

but the choice should be based on your problems, not what randos said on the internet

tomc19:12:28

I think yogthos always discusses things with a level head so I liked what he had to say there. Whether any of it will help with the Reagent or Om question is another matter.

Tim19:12:17

yeah yogthos is worthwhile to read up on

Tim19:12:34

I quite like reagent for smaller project…. I use om for everything now though

naomarik19:12:53

i had no idea about the data access queries as opposed to rest,.. that's absolutely massive

mattly20:12:00

@naomarik: depends on the use … but for a particularly cpu-intensive thing in our interface we actually got much better response times with websockets to the server and running that code there

peeja20:12:20

I'm running into a weird issue: I'm following the Remote Synchronization Tutorial (https://github.com/omcljs/om/wiki/Remote-Synchronization-Tutorial), and when I get to the end and try to run the autocompleter, I get Uncaught ReferenceError: ReactDOM is not defined

peeja20:12:50

But react.inc.js is on the page…

peeja20:12:31

I have a breakpoint on var ReactDOM = _dereq_(35);, and it does appear to be setting ReactDOM

peeja20:12:47

Oh. But that's var ReactDOM, not window.ReactDOM.

peeja20:12:24

So, anyone know what's support to export ReactDOM to window (using cljsjs/react-dom)?

noonian20:12:59

You will get that if you are trying to use sablono or something and not requiring om.dom. If that is your problem you can work around it by requiring either om.dom or cljsjs.react.dom

peeja20:12:31

Oh, of course! Thank you!

peeja20:12:37

That makes sense.

tony.kay20:12:00

So, I posted what I see as an async problem in the reasoning model of send: https://github.com/omcljs/om/issues/534 This problem only happens when auto-normalization is on, but it can be summarized as: - Send a query off to the server - Time passes - UI interaction changes the query - Server response arrives - Callback normalizes against the NEW UI query, possibly losing data if that portion of the UI isn't currently in the UI query (say because it has been "routed" away) The workaround is to turn off normalization and do it by hand (using a query of your choice and tree->db).

peeja21:12:06

Not sure if this is a sensible question, but: Is there a reasonable way to build an Om Next component tree and reconciler, and then mount it inside a larger React app? Basically, I'm looking for a way to make a small piece of our Om.Now app use Om.Next, to try it out and find bugs using a non-mission-critical part of the app (and eventually to expand as our migration path).

dnolen21:12:43

@tony.kay: agreed it’s a problem, some enumeration of possible solutions welcome.

tony.kay21:12:55

@dnolen: The only suggestion I have is to memoize the root query from the UI inside of the callback generation. The send that "receives" that callback only has queries in that context, so it seems like it fixes the reasoning. I don't see any problems (other than code wrangling) with that approach.

tony.kay21:12:31

Although we may find other subtle sequencing bugs in the same place...seems like we might end up wanting some kind of queue around sends so we can reason about them in order, even if there is out-of-order response from the server

dnolen21:12:37

@tony.kay: why do you need to memoize the root query?

dnolen21:12:48

to me the bug is that the query that was used to fetch isn’t used to normalize

tony.kay21:12:21

right, and remembering the query is the solution I'm suggesting

dnolen21:12:38

but this isn’t about the root query

dnolen21:12:41

it might not be a root query

tony.kay21:12:57

ah, I see your point, though currently the callback does normalization with the root query

tony.kay21:12:08

or did I misread that

tony.kay21:12:38

sorry wrong line

snichme21:12:21

I dont get the thing with links in the query to work. I’ve tried my own code and when that didn’t work i tested with the appendix code from the wiki page ”Thinking with Links” but I get nil for current-user. Using alpha24. Can anyone help me?

anmonteiro21:12:07

@snichme: working for me, be sure to clean your build

dnolen21:12:56

@tony.kay: right I would consider that to be the bug

dnolen21:12:09

send probably needs to take the original query

dnolen21:12:26

er excuse me I mean the callback

dnolen21:12:58

[response query] should probably be the callback signature

dnolen21:12:42

due to the laxness of JavaScript this means existing code won’t break and people can incrementally fix

dnolen21:12:42

but actually I think it’ll just have to be a breaking change since it effects merge

dnolen21:12:08

but not a big deal IMO, current behavior is just a glaring bug and we’re still in alpha

snichme21:12:06

@anmonteiro: and by clean you just mean

lein clean

noonian21:12:36

lein clean will only get rid of whatever lein knows about, you can configure :clean-targets in your project.clj. You will probably want to get rid of target and wherever you are generating your js and out files to.

snichme21:12:59

okey, will try that

Roman Liutikov22:12:41

I’m very new to Om. With queries in Om Next one can communicate with server. But how do I manage UI state, which needs to be mutated only locally?

tony.kay22:12:02

@dnolen: Yes, that would work, given that send does know the query...the query is already available there.

tony.kay22:12:39

it probably never really makes (safe) sense for callback to automatically decide to use the root query

tony.kay23:12:24

I'd be interested in what others are doing about UI state. We decided (so far) on a couple of add-ons that seem to work for all of the cases we've seen so far: 1. We namespace properties that need to be complected onto data that came from a server using a ui prefix (e.g. :ui/checked) 2. In send, we use clojure walk to strip these out of the query before sending to the server 3. We use a deep merge for merge-tree, so that we don't stomp on UI-related props that might have been on things we're updating from the server. 4. We also have an algorithm for resolving the problem of properties disappearing over time, which the deep merge might accidentally leave around. Basically, we use the query to understand what we asked for, and if we don't get a response for that property then our deep merge removes it as a post-processing step.

jonsmock23:12:15

That's basically what we've done (in a less sophisticated way). I've been trying to think of a good way to keep ui state completely separate and sort of "zip" them together upon query, but I haven't found a satisfying way to do that

jannis23:12:43

Sounds reasonable, I've used a combination of 1-3 so far.

jannis23:12:23

About 2 - wouldn't it be possible to strip the UI props from the AST for the remote in read?

jannis23:12:33

That's probably what I would do

tony.kay23:12:03

@jannis: walk lets us separate the concern in 2, and not repeat it all over the read code

caleb23:12:08

When you do a set-query! on a component, a read is performed on that component’s query. Do you think it would make sense for the env of that read to have a ref if the component ident??

tony.kay23:12:21

@jonsmock: In my app sample in the tutorial I originally did just that, but I settled on this latter method because separating the data caused other problems. Not saying it cannot be made to work, but it ended up being easier to just maintain them with the objects.

caleb23:12:42

I am playing around with loading data incrementally, and it seems like it would be useful to have that ref for forming remote queries

tony.kay23:12:43

the primary problem was the zipping made db->tree less useful

jannis23:12:49

@tony.kay: Right, I see. Another idea could be to do (def parser (om/parser {:read (comp strip-ui-props-from-remotes read) ...})) but that's basically what you do, except as part of send. 😉

tony.kay23:12:17

@caleb: Terminology...what do you mean by ref...that term gets thrown around loosly

caleb23:12:48

@tony.kay: You’re right. The ref in the Om sense [project/by-id 2]. When you run transact on a component that has an ident method, the env in the read function has the Om ref of the component that you called transact on

tony.kay23:12:10

ok, so the term is ident, not ref. An ident is a vector of two with kw as first ele

tony.kay23:12:17

ident is also the name of a method

caleb23:12:24

@tony.kay: Hmmm, yeah. Did idents used to be called refs? Because if you do run a transact on a component, you do get a :ref key that has an Om ident

dnolen23:12:29

I take the blame for that simple_smile

tony.kay23:12:12

so, yeah, as David says, there was some naming convolution (and some may remain)

dnolen23:12:27

@caleb: not sure about :ref as a result of transact.

dnolen23:12:41

even if it isn’t you shouldn’t be using it

dnolen23:12:55

@caleb in general if something has been written down somewhere you should avoid it