Fork me on GitHub
#om
<
2015-12-09
>
jannis00:12:05

Is there a way to obtain the query of the root component instance from the reconciler?

noonian00:12:05

yeah but might be an implementation detail

noonian00:12:04

(-> reconciler :config :state deref :root) I think works

jannis00:12:04

I see there's om.next/app-root but that returns the component (e.g. Root), not its instance, correct? So if you use (set-query! this ...) to change the query of the instance, is there a way to get that from the reconciler somehow?

noonian00:12:15

sorry, its (-> reconciler :state deref :root)

noonian00:12:29

the :state in config is your app state

jannis00:12:07

@noonian: Yep, that's what om.next/app-root does. I was wrong, it does the right thing, it returns the instance. I just had a local variable shadowing the result...

jannis00:12:10

So all good simple_smile

dnolen00:12:21

yep app-root is there for a reason simple_smile

noonian00:12:23

lol, I guess I should use app-root then

thosmos00:12:03

I simplified my version of the router-example (https://github.com/thos37/om-next-router-example/blob/simplify-datascript/src/om_router/core.cljs) to have the Root component just have a simple [:route] query: (om/get-query Root) -> [:route]. When it's parsed, it returns a map with the route as a key pointing to the data needed by the child Page component for that route: (parser {:state conn} '[:route]) -> {:route {:index {:pg/title "Welcome to Take 2", :pg/subtitle "Take 2 minutes to change your self. You're the only one who will."}}} Does this seem reasonable?

rberger00:12:03

Any hints on how to have (or even think about) streaming data from websockets drive multiple graphing widgets on a page in an om.next based app?

noonian00:12:24

when you get a message on the websocket, call merge! with the reconciler and new data to get it into the state

thosmos00:12:08

Is the main problem with having an opaque query like [:route] that it requires multiple round trips to the remote store on each page transition, whereas something like [{:pages {:index (om/get-query HomePage) :login (om/get-query LoginPage)}} :current-page] enables the server to send back more data up front?

bmaddy00:12:53

@marcol: I'm glad it saved you some time!

dnolen00:12:04

@tony.kay: getting close but not sure I will fix it tonight, so don’t wait up for me simple_smile

jannis01:12:12

The server-side parser does not include {:foo <val>} from the result if the read for :foo returns {:value nil}. Is that deliberate?

jannis01:12:34

A value of nil might be deliberate to indicate the thing isn't set or doesn't exist.

dnolen02:12:47

@jannis good point and easy to fix, file an issue

jannis02:12:21

Will do and will see if I can fix it as well

jannis02:12:35

And a test ideally.

noonian03:12:33

Hehe, I didn’t realize github updated in real time

noonian03:12:43

issues being closed as I read them 😛

dnolen03:12:01

@tony.kay: no rush, but I resolved OM-528, so if you want to look at OM-526 do so at your leisure

dnolen03:12:52

good example of how much a small amount of terrible code can have serious repercussions

tony.kay03:12:28

@dnolen: ok, will do. jannis supplied a reproducible case for the problem in db->tree as well. Something about the recursion limiting isn't quite right.

jannis03:12:54

@tony.kay: So you managed to reproduce it?

tony.kay03:12:10

and narrowed down the case

dnolen03:12:08

@tony.kay: so I actually resolved OM-526 with OM-528, what actually needs to be fixed are your own merge-union-join tests

dnolen03:12:02

test-merge-joins-on-non-merges is currently commented out

tony.kay03:12:23

Oh, ok. great. I'll do that

dnolen03:12:36

again no rush

tony.kay03:12:39

That may also resolve this db->tree issue

tony.kay03:12:45

I was just reading over your patch

dnolen03:12:08

do you have a test case?

dnolen03:12:19

would happily take a test case PR that shows we’re covered

jannis03:12:42

@tony.kay: I'm off to sleep but keep me posted on the progress or if you need any help (doubt it ;)). Thanks for looking into it

jaredly04:12:46

In react 0.15, I really like the stateless function components, and the simplicity of it (props -> vdom). In cljs, I’d like something like (defsimple name [props] (dom/div nil (:title props))). Is this a thing that’s supported in om? I could do it with a macro, but don’t want to reinvent the wheel.

jannis04:12:17

@jaredly: (defui Name Object (render [this] (dom/div nil (:title (om/props this))))) + (def name (om/factory Name)) not good enough? 😉

jaredly04:12:31

haha yeah a little wordy

jaredly04:12:55

hides the stuff I care about

johannjohann04:12:20

yeah you can do it with just functions with the caveat that it has to be a child of a stateful component

johannjohann04:12:47

inside yr defui / reified component thing you can build out helpers that take data and return vdom

johannjohann06:12:02

hey guys, i ran into an issue with react native and om next and datascript involving how rerenders from the root were handled. i made a gist of a reproduction case, as well as the reconciler implementation that seems to address the issue. https://gist.github.com/jobez/9ea1963b2b07454a28a6

octahedrion10:12:38

how can I disable React warnings ?

octahedrion10:12:01

"Warning: render(): Rendering components directly into document.body is discouraged, since its children are often manipulated by third-party scripts and browser extensions. This may lead to subtle reconciliation issues. Try rendering into a container element created for your app." - ok, ok

nblumoe10:12:51

I'm having trouble with queries in nested components:

Uncaught #error {:message "No queries exist for component path 
                   (example-app.views/Root example-app.views/Users example-app.views/User)", :data {:type :om.next/no-queries}}

nblumoe10:12:23

any idea why this might be failing?

nblumoe10:12:59

Obviously :class-path->query is missing the corresponding value, as the error message indicates and the gist code shows. Why might that be?

johannjohann11:12:40

how are your components queries structured

nblumoe11:12:35

hi @johannjohann I could narrow down the issue a bit more. let me get a gist ready with the components/queries

johannjohann11:12:32

are you trying to set a query

nblumoe11:12:15

@johannjohann: updated the gist with example components. I would prefer to define a query on Users however, this results in the error described above.

nblumoe11:12:22

Keeping Users without a query, but defining the query on the Root instead does not result in that error, because then the component class-path is Root > Account instead of Root > Accounts > Account

nblumoe11:12:43

But I would like to define the Query on Users

johannjohann11:12:29

if you click that little info icon in the upper right hand corner it has some pinned chats

johannjohann11:12:17

im dubiously trying to figure out how to link one particular dnolen statement lol

johannjohann11:12:31

dnolen Nov 10th 1) every component that wants to query must have it’s OWN query and it MUST be a vector

jetmind11:12:00

@nblumoe: If you want to include Users query in the Root component you should do this with a join, e.g. [:app/version :routing/current-route {:users (om/get-query Users)}], and Users query must be a vector as @johannjohann pointed out. Basically, you can't steal queries from another component. You can find some discussions about it from yesterday if you search for "steal queries" in this slack channel.

johannjohann11:12:50

is there like a tool that allows slack communities to reference convos in wikis and stuff

anmonteiro11:12:29

@johannjohann: not sure about that, but you do have this slack's logs here: http://clojurians-log.mantike.pro/om/

dnolen12:12:37

@jaredly: what’s needed to support stateless function components? it’s just a function right?

nblumoe12:12:33

"If you want to include Users query in the Root component" this seems to indicate, that this would be optional. From my understanding it's mandatory though. Doesn't the Root need to "collect" all queries of subcomponents?

nblumoe12:12:36

Not using a hash-map, but a vector for Users was, what I did first (according to the cited statement and the docs of HAVING to use a vector). However, I could not successfully merge that into the Root query then. Either ended up with an invalid query syntax, OR lost the meta data needed to identify the component that defines the query.

dnolen12:12:06

@nblumoe: the query that doesn’t work in the gist doesn’t make sense

dnolen12:12:18

as already state the query must be a vector but that’s not the actual conceptual problem

dnolen12:12:55

the parent needs to know the key in order pass on the child’s information

nblumoe12:12:07

ok, good to know, so https://github.com/awkay/om/wiki/Om-Next-Overview#reads-and-the-query-grammar really is outdated by now (last query being a map)

dnolen12:12:08

but you’ve hidden that key by moving it into the child

dnolen12:12:37

most of these conceptual issues can be avoided by thinking about modularity

dnolen12:12:49

the parent must know all the keys for stuff it will pass along

nblumoe12:12:19

Ok, but is there a way to retrieve the keys from the children queries then?

dnolen12:12:33

no, there are no alternatives

dnolen12:12:41

everything I’ve stated is how it works and it will not change

nblumoe12:12:20

Oh, yes. Not talking about changing anything. Rather trying to understand how to use it properly and what the intended design is. simple_smile

dnolen12:12:47

“retrieving keys” from child queries is not a thing

dnolen12:12:02

parents do not examine child queries

dnolen12:12:16

again modularity

dnolen12:12:22

this said routing is a concern but it is a global one and one that we intend to support in a global way not at the level of individual component. this story is getting sorted out.

nblumoe12:12:34

Fair enough. Thinking in terms of React it also makes perfect sense to pass the data from the parent to the children.

nblumoe12:12:05

Thanks for the help. Back on track now!

txus13:12:33

I’m having some trouble with normalization, I have a chain of 3 components and for some reason the reconciler can’t normalize the data.

txus13:12:39

the queries are as follows:

txus13:12:13

Rootview -> Mapview -> ClusterView -> ParkingSpotView

txus13:12:19

(4 components sorry)

txus13:12:34

I’ve checked the metadata of the queries and it looks okay

txus13:12:11

hm the idents are all set up correctly it seems no? I’m confused

dnolen13:12:19

request for the channel can we please just share gists

dnolen13:12:23

this whole inline snippet thing is terrible

txus13:12:25

woops sorry

dnolen13:12:38

@txus please include the total query for stuff like this

dnolen13:12:51

in a comment so it’s easier to see what the data shape is and the expectation

txus14:12:55

I included the root query

txus14:12:23

as from (om/get-query RootView)

dnolen14:12:57

@txus I don’t see how you can expect that to work

dnolen14:12:01

the query obviously shows that it won't

dnolen14:12:59

automated normalization isn’t about changing some random shape into a db

dnolen14:12:05

the shape has to match the query

dnolen14:12:16

if you look at all my examples this is always the case

txus14:12:17

hm I’m not sure I see what’s wrong with the query...

anmonteiro14:12:24

@txus: you basically have one component too much

anmonteiro14:12:39

your root should be MapView

anmonteiro14:12:46

then everything works

anmonteiro14:12:59

because there's no :map-props in your data

txus14:12:02

I know, but isn’t this what we discussed yesterday, that you could make up artificial nestings to create a path between components?

txus14:12:25

where (defmethod read :map-props) just parser the query like (parser env query)

anmonteiro14:12:48

but that's unrelated to normalization

txus14:12:37

I was pretty sure I had something similar working yesterday though — a RootView that makes up an artificial nesting to pass data to subviews, and normalization I think it worked? maybe not

anmonteiro14:12:38

so in the normalization case, you'd have to wrap your state in a :map-props

anmonteiro14:12:57

then everything works again

anmonteiro14:12:04

and you can use the RootView component

txus14:12:23

what if I modified the query instead of changing the state? then I’d have the problem of RootView stealing MapView’s query no?

anmonteiro14:12:30

notice that it's a really simple rule: component's queries have to match the data's shape

anmonteiro14:12:19

what I don't understand is why you have one component too much, as I've said before

txus14:12:41

the idea is that RootView will have other subcomponents, not only MapView, that will have their own subqueries

anmonteiro14:12:44

your MapView component already has all the information in the state ( at least for this exampe)

anmonteiro14:12:13

then you'd want a union

anmonteiro14:12:18

or maybe not

txus14:12:19

that fixed my problem with the Rootview stealing queries

txus14:12:38

from my point of view I’m doing nothing different from that, but for some reason normalization doesn’t work in this case :S

txus14:12:09

so my map-props would be a join that references Mapview’s query, in this wording

anmonteiro14:12:13

I got your example to work with a hacky thing that I'm not sure it's supposed to be used

txus14:12:26

hmm oh okay

txus14:12:34

it seemed to work wonders simple_smile but maybe it’s not the way to go

anmonteiro14:12:34

which is basically using that approach

anmonteiro14:12:48

of my snippet

anmonteiro14:12:05

but you'd have to pass the state to the reconciler like this: (om/tree->db MapView init-data true)

anmonteiro14:12:24

so basically is just working around the problem that you have, it's not really solving it

anmonteiro14:12:51

because your data only matches your queries up to MapView

txus14:12:59

okay, so what I should take away is that component queries must always match the shape of the data, no matter what

txus14:12:08

I’ll have to find a different way to solve the query stealing problem

dnolen14:12:08

@txus not no matter what

dnolen14:12:20

it’s important to understand what I’m saying

dnolen14:12:24

“auto-normalization"

dnolen14:12:44

if you want automatic normalization then your query shape must match the data shape

dnolen14:12:54

if you don’t want that, then doesn’t matter at all

anmonteiro14:12:27

it handles exactly the case where you can't have "auto-normalization", to steal David's words

txus14:12:34

I see hm, so auto normalization has its price and you can choose to pay it or DIY

dnolen14:12:02

@txus think about what auto-normalization is actually about

dnolen14:12:16

most of the of the time the data isn’t here, it’s THERE somewhere else on some server

dnolen14:12:32

you will send a query over the wire and get exactly what you requested

dnolen14:12:35

in the exact shape

dnolen14:12:52

this won’t be normalized, and we can automatically normalize because … of course!

dnolen14:12:25

but in this case you’re doing some local state stuff

dnolen14:12:32

where you’ve picked some arbitrary data layout

dnolen14:12:37

which has nothing do with the queries

txus14:12:56

true. it makes more sense thinking of some remote server

txus14:12:00

where map-props means nothing

dnolen14:12:39

still note you can normalize anything you want

dnolen14:12:48

provided you supply the right query for it

dnolen14:12:18

in fact you can write a query you never use for anything except the normalization of local state

txus14:12:38

aha, that’s an interesting point

txus14:12:55

then I can not use auto-normalization with the RootView query but rather normalize it myself and pass it as an atom to the reconciler

txus14:12:18

nice, makes sense!

txus14:12:07

ah this morning I still wasn’t completely sure if normalization had to do with the parser reading the data lol. The concepts are slowly getting clearer in my head, even though I’ve been using om.next for quite a while now heh

dnolen14:12:12

@txus it take's a while to see that all of these things are a la carte things

dnolen14:12:20

they aren’t tied together in anyway at all

bostonou14:12:24

@dnolen: why did factory become a top-level thing with om.next when all the details were hidden away with om.now?

dnolen14:12:02

@bostonou: mostly a syntactical thing, I didn’t want to auto-generate stuff

dnolen14:12:20

or complicate defui to support giving the factory a name

anmonteiro14:12:37

@txus: note that this is what I've done with your example; normalized it and passed it into the state

dnolen14:12:42

and in the end factory is useful - you can do validation, :keyfn all these other things there

dnolen14:12:58

putting them into defui was just gross - I tried a few things

bostonou14:12:42

@dnolen that makes sense. it struck me as something “new” to learn for om.next that didn’t seem crucial to the problems next is solving

bostonou14:12:51

figured there was a reason

dnolen14:12:06

@bostonou: it’s actually awesome IMO

peeja14:12:09

@dnolen: Getting my head around factory: Is there ever a reasonable case for having multiple factorys for a single defui component? Would you ever use different :keyfns or :validators for different cases?

dnolen14:12:31

one thing that nobody has pointed out is that it with :keyfn it just kills off all of this build-all junk

bostonou14:12:46

i did notice that simple_smile

dnolen14:12:49

like (map item […]) just works

dnolen14:12:05

so that’s more important to me than the complaints

dnolen14:12:21

since writing a factory is kind of a once thing, and the other stuff you have to deal with constantly as you change your app

peeja14:12:42

Oh, right, that's what makes that work now

dnolen14:12:44

@peeja: yes you could have multiple factories

peeja14:12:20

I mean, would that actually be useful?

peeja14:12:44

I'm trying to get my head around whether factory being a separate form in the file is functionally useful or just syntactically easier

dnolen14:12:48

@peeja: I’m sure someone will find it useful yes

dnolen14:12:12

anyways people can voice their thoughts about factory but it’s not going to change

dnolen14:12:18

it was heavily considered decision and it’s done

bostonou14:12:34

@dnolen are there actual (legitimate) complaints about factory?

dnolen14:12:48

@bostonou: only from people who are starting

peeja14:12:54

I'm not trying to change it. simple_smile I'm trying to lean on it to glean some understanding of the thinking behind it.

dnolen14:12:58

nobody that’s been using it for a while say anything about it

peeja14:12:14

I figure if it feels weird to me, then I'm missing something

bostonou14:12:16

i’m just spending hammock time on next, so making sure i spend time on stuff that isn’t rock solid in my mind

bostonou14:12:30

definitely not complaining, just trying to understand simple_smile

dnolen14:12:56

right it’s just place to do constructor customization that I don’t want to put into defui

dnolen14:12:06

it’s really that simple - means fewer protocols, less magic

dnolen14:12:41

less syntax

bostonou14:12:14

it did make me revisit some React stuff that i didn’t need to really think about before. i’m cool with that, because i got burned too many times by magic i didnt understand

bostonou14:12:09

but, i did want to understand and be able to articulate the benefits of simplifying the factory code

dnolen14:12:22

yes Om Next UI components are just legit React components

bostonou14:12:18

right. you’re just helping finish the last section of my next blog post simple_smile

dnolen14:12:27

there were many brittle hacks in the previous Om in the attempt to avoid this that are now gone

bostonou14:12:57

cool, thanks for the help

tony.kay16:12:40

@nblumoe: Let me know if there is a specific thing that is out of date in that overview. I'll fix it. Working on a tutorial that will probably supersede that, but I don't want it saying things that are wrong or misleading.

selfsame17:12:46

For reading joins on collections can I do (mapv #(parser (assoc env :state (atom %)) query) col)?

dnolen17:12:32

@selfsame: you should try to replace custom parsing with db->tree whenever possible

selfsame17:12:35

aha totally missed that

bplatz17:12:02

I fairly consistently get the following error on figwheel reloads, anyone get the same and possibly know the cause?

bplatz17:12:04

Cannot read property 'call' of null

bplatz17:12:30

It gets thrown at reconcile!

bplatz17:12:42

(empty? q) ((:render st))

bplatz17:12:32

I'm assuming it is a load order or something like that, but haven't been able to track it down yet.

dnolen18:12:24

@bplatz: haven’t seen anything like that

tony.kay18:12:48

@dnolen: Design question. In send, the callback is essentially merge, which in turn uses the current root UI query. If I've fetched something that is not in the UI (yet), is there a recommended approach to getting that data into app state?

dnolen18:12:04

@tony.kay: not sure I follow

dnolen18:12:13

you sent a query that you obviously have

tony.kay18:12:30

I want to prefetch data, so I augment the query during send to get that extra data

tony.kay18:12:49

it is not currently in the UI (e.g. through a branch of union not yet active)

tony.kay18:12:04

or as a query fragment that isn't being used yet

tony.kay18:12:42

Or even I go to a REST server and ask for data from legacy software

dnolen18:12:17

@tony.kay: so my question is, is this not working for you for some reason?

tony.kay18:12:35

Perhaps I'm doing something illegal: Is it legal to put a query fragment into query params?

tony.kay18:12:49

and compose that into a query for that component

dnolen18:12:17

I don’t see any problems with that no

tony.kay18:12:54

well, then that query fragment might not be part of the current "Root" query.

dnolen18:12:18

for various reasons you may want the process by which you create queries to be more flexible for some reason

dnolen18:12:41

@tony.kay: I think what you’re asking is

dnolen18:12:02

“I understand how Om Next works, I now I see that I have superpowers. Is this OK?"

dnolen18:12:06

the answer is yes

tony.kay18:12:31

😄 As I think about it, I can solve my immediate concern with unions. My real question is "is it OK to grab app state during send and swap against it?"

dnolen18:12:52

yes if you know what you’re doing

tony.kay18:12:26

ok. I can definitely see ways to plug into merge-tree et al. Just didn't know if watches on that atom would cause problems somehow

dnolen18:12:54

I can’t think of anything, I’ve tried to ensure that swap! works

dnolen18:12:14

for swap! the main problem is avoiding re-renders from the root if you don’t want that

tony.kay18:12:24

ok. That answers it. Mostly I'm asking so when I'm working on docs I don't mis-state something.

jannis18:12:19

Did I share http://github.com/jannis/om-mantras / http://jannis.github.io/om-mantras/ yet? Only two components so far but I'm happy to add more if there are any good ideas. simple_smile

jannis18:12:12

The idea behind creating this was that there are cool widgets out there (like selectize) but they all come with heavy styling that's a pain to override. And they don't use Om. 😉

tony.kay18:12:57

Yeah, looks good. Filed an issue for you with ideas on how to fix your known issue on selectable.

thosmos19:12:16

wow, @jannis that's rad

tomc21:12:32

@jannis: Both of those components are great.

tony.kay21:12:02

@dnolen: From a design standpoint, does it make sense to have something meant to generate query/ident objects that are not UI? I know we can use defui for this, but in cases where I'm using defui to generate artifacts for dealing with the fact that my server query/response does not match my UI (e.g. I just create them so I can leverage tree->db), it seems like a lighter weight defquery might make more sense.

dnolen21:12:40

@tony.kay: it’s possible but not going to consider something like that now

dnolen21:12:59

at the moment just interested in working through the blockers to Beta wrt. features

dnolen21:12:21

I have pondered the same thing - but gotta finish the “boring" stuff first simple_smile

tony.kay21:12:04

no problem...easy enough to rename our uses of it later. I'm sure the shape will remain.

jannis21:12:39

How are the Om tests run?

jannis21:12:55

lein cljsbuild test?

dnolen21:12:51

@jannis I just run them at the REPL

dnolen21:12:06

I’ve stopped using Lein for my own Om development

jannis21:12:48

Understandable

dnolen21:12:08

it’s really just a REPL start time thing

dnolen21:12:45

I can’t get Lein to do what I want, and I’m already a Cursive user, so I just created a pom.xml with all the dependencies I actually want

dnolen21:12:07

I still use the project.clj for deployment of course

dnolen21:12:46

that said if somebody wants to wire up doo or something, I’m not anti

jannis21:12:51

I'm not a cursive user (yet) but I might be if it had good support for boot, which I can get to do what I want, unlike lein - like you say

dnolen21:12:18

as long as it doesn’t interfere with what I currently have setup

dnolen21:12:43

I’m also not against a boot file for dev if that makes contributors lives easier

dnolen21:12:56

again as long as it doesn’t interfere with pom.xml or project.clj

jannis21:12:08

How do you run the tests from the REPL then? I tried (in-ns 'om.next.tests) (run-tests) but that doesn't work.

dnolen21:12:22

you need to load the file first

dnolen21:12:37

(require ‘om.next.tests) (in-ns ‘om.next.tests) (run-tests)

dnolen21:12:49

for me, in Cursive the first two things are bound to key commands

jannis21:12:23

No such namespace om.next.tests. Weird.

jannis21:12:08

I can't figure it out somehow, but will try again later

jannis21:12:06

@dnolen: Fancy an alpha26 release? 35 commits since alpha25 and quite a few useful fixes

noonian21:12:59

you need to get the src/test dir into your source paths for however you are running the tests

noonian21:12:37

I don’t have them working personally though, but I think that is the problem you’re having

jannis21:12:43

Yup, I tried adding it to the figwheel config

anmonteiro21:12:41

@jannis: how are you running the figwheel script?

jannis21:12:06

@anmonteiro: I'm not a figwheel user so I may be doing it wrong: rlwrap lein run -m clojure.main script/figwheel.clj

anmonteiro21:12:33

so if you're using lein you need to add "src/test" to you lein :source-paths vector

jannis21:12:53

Done that: jannis@columba ~/o/om> grep test script/figwheel.clj :source-paths ["src/main" "src/devcards" "src/test"]

anmonteiro21:12:05

in project.clj

anmonteiro21:12:39

I thought about it but didn't write it, how silly

jannis21:12:49

Hehe, it's ok

dnolen21:12:01

@jannis yes will do that later

jannis21:12:27

This is one of the reasons why I'm not using either of lein and figwheel - just don't know where to put what and then you have :source-paths in different places...

jannis21:12:30

@dnolen: Cool, thanks

jannis21:12:06

@anmonteiro: Perfect, that worked

anmonteiro21:12:52

@jannis: btw you should try the node repl instead of figwheel's

anmonteiro22:12:04

faster startup time

anmonteiro22:12:22

so rlwrap lein trampoline run -m clojure.main ./script/repl.clj

jannis22:12:31

figwheel is blazing fast compared to boot repl 😉

dnolen22:12:58

I claim fastest 😄

dnolen22:12:13

but yes I run Node.js REPL for the regular tests

dnolen22:12:17

and Figwheel for the devcards

noonian22:12:34

figwheel changed my life

noonian22:12:01

and makes for really awesome demos to JS devs

jannis22:12:17

Ok, tests are running, my new test for #531 fails (as it should) and a quick "fix" breaks other tests. Nice simple_smile

dnolen22:12:07

this is how fast a tuned Node.js REPL can start

dnolen22:12:25

I suspect another second could get shaved by switching to Transit for analysis caches

dnolen22:12:36

but that’s for another day

jplaza22:12:49

Since Om Next UI components are just legit React components, using a JS React component (like this one https://github.com/zippyui/react-date-picker) should be straightforward right?

dnolen22:12:13

@jplaza: using React components was always pretty straightforward

dnolen22:12:32

but yes you should be able to use them easily with Om Next components

noonian22:12:38

I think the hard part will be getting it included in your build (and surviving advanced optimizations). It looks like that component uses commonjs or w/e for modules and may not be on cljsjs

jplaza22:12:08

Great! We love Clojure and use it heavily for our backend services. So I was hoping to start using CLJS really soon.

jplaza22:12:12

Just wanted to be sure I could speed up dev using third party components, you know how product people are just thinking about features ASAP.

jplaza22:12:25

@noonian: how hard could that be?

dnolen22:12:50

@noonian: @jplaza the standard thing to do is to just build all your JS stuff with React Tools or whatever

dnolen22:12:22

and include that as a single foreign lib

dnolen22:12:56

annoying, but it’s not something you have to do much and there’s pretty good documentation out there and examples thanks to CLJSJS

dnolen22:12:27

eventually we’ll get a good CommonJS story but that requires more support from Closure

noonian22:12:40

Yeah, its definitely doable. It just isn’t as easy as using a cljs lib or js lib that has already been packaged for cljsjs.

jplaza22:12:22

@dnolen: last thing I read, Maria Geller was working on making this less painful, or was it something else related to JS dependencies?

dnolen22:12:40

@jplaza: yes and it even works OK

dnolen22:12:46

but there’s more work to do

jplaza22:12:15

OK, thanks. I will start playing with Om Next and hope to have something in production in a couple of weeks simple_smile

dnolen22:12:54

@jplaza: haha, things are coming along but we’ve probably got a solid month or so before Beta simple_smile

dnolen22:12:05

people in this channel are really good at finding bugs and feature holes

peeja22:12:25

Can someone explain to me what Object means in a defui? It appears to be the protocol that defines render, but clearly that's not right…

jannis22:12:01

Object means all functions below it are regular JS object methods, which render is as well - it's the regular render method from React, I believe.

peeja22:12:45

Ah, I see. Is that a defui thing, or is that already part of ClojureScript somewhere?

dnolen22:12:21

Part of CLJS since day 1

peeja22:12:56

Where else does it come up? I've never seen it before.

peeja22:12:07

Oh, I see, reify takes it

jannis22:12:39

(defrecord Foo [bar baz] Object (hello [this] ...)) should be possible as well I guess?

jannis22:12:38

I'm only assuming

dnolen23:12:03

Object is just a thing, again it existed 4 years ago

dnolen23:12:14

anywhere a protocol can appear, it can appear

noonian23:12:55

process-roots doesn’t handle unions yet, right?

tony.kay23:12:52

@noonian: tip of master should work now

dnolen23:12:07

1.0.0-alpha26 released

jannis23:12:42

That parrot icon makes me really nervous.

tony.kay23:12:35

@noonian as should alpha 26 simple_smile

noonian23:12:38

@tony.kay: I see the bug is fixed, but queries in the union do not seem to cause process-roots to promote the queries to the root.

tony.kay23:12:27

Ah, I see. So, you're not trying to just walk past the union to the target subquery, but instead include one of the specific items of the union as the root query?

noonian23:12:54

well, I don’t think either works right now. I do want specific items of the union as the query, but I also tried manually annotating the union’s query with the meta data {:query-root true} and that didn’t seem to do anything either.

tony.kay23:12:47

Hm. So, I'm not using unions with process roots yet, and it is likely that more thought needs to go into it. When you do a local parse phase, you make a real choice (X is what I see in the app right now). When doing the remote parse phase you can also look at the app state and resolve "which path" is of interest right now. I was assuming that you would walk down a bit from there, and bottom out at server data, then mark that bit as a root.

noonian23:12:00

In my parse phase I make a real choice about which remote queries to return also

noonian23:12:19

I agree it probably needs more thought btw.

tony.kay23:12:15

it is possible that neither of those works. The only test is that if we see a union, we preserve it. Basically, the updated code tries to resolve the issues that are obvious (more than one subquery might promote to root). As I think through it, I did not address any union case other than preserving it. If you want, let's think through it.

tony.kay23:12:24

{:join-key {:typeA subqueryA :typeB subqueryB}} is the element of interest

tony.kay23:12:02

does it make sense to turn that into [some-subquery-of-A some-subquery-of-B]?

tony.kay23:12:15

if both branches mark some subelement as root

tony.kay23:12:21

the response is a map, so I think not

tony.kay23:12:40

there is only one actual value we can put in the result at join-key

noonian23:12:45

In my case, my union is just to support routing. So in my read function for the :join-key, I call the parser recursively in remote mode to get the remote query of the current page.

tony.kay23:12:05

right, so just subqueryA for example

noonian23:12:36

What I’d like to be able to do, is just add :query-root true to my default read function, and not have to do any custom logic anywhere else so process-roots just works

noonian23:12:40

in that case,

noonian23:12:02

it would be each element of subqueryA that has a query annotated with {:query-root true} metadata

noonian23:12:37

next most convenient that I’d also be happy with is in my read for :join-key manually adding the metadata to the remote query subqueryA

noonian23:12:15

I think you’d want to check each branch and compose all the root queries into the result root query

jannis23:12:38

@tony.kay: @dnolen: I mean, you have a test for this now, but I can confirm the recursive query fix works simple_smile

jannis23:12:10

This is amazing

noonian23:12:42

now that I think of it, the default read doesn’t make sense

noonian23:12:22

so I now think subqueryA or subqueryB should be the things promotable to root

tony.kay23:12:01

or some sub-portion thereof, but only for one (side) at a time

tony.kay23:12:47

BTW, process roots is targeted at joins