Fork me on GitHub
#om
<
2015-12-18
>
noonian02:12:28

@tony.kay: I’m not sure the rewrite semantics are entirely correct for process-roots. For your expected response for test-process-roots-can-promote-a-union-to-root it seems like you are “deciding” the ambiguity of a collection verses a single map in the rewrite rules, which may make sense since a server response is always a map. That is actually ok for my uses, but want to make sure its the desired semantics.

noonian03:12:30

@tony.kay: I opened a PR for process-roots, I didn’t see the github issue you had opened until after I had it working heh.

tony.kay03:12:44

@noonian: Great! I did post a follow-up response on the PR. Be glad to discuss the specifics.

tony.kay03:12:14

If you promote two things to root from a union, then it seems to me that you cannot possibly make rewrite work

tony.kay03:12:26

nor does your test cover that case

noonian03:12:05

its true that my test doesn’t cover that case, but thinking through it I think it only will occur if the subqueries have the same keys

tony.kay03:12:22

the keys on the subqueries are not part of the response

tony.kay03:12:25

[{:k { :t1 [:a] :t2 [:b] }}] should end up with a response like { :k {:a 1} } (singleton) or {:k [{:a 1} {:b 2}] } (to-many)

tony.kay03:12:39

:t1 and :t2 are not part of the response

noonian03:12:45

as I see it, we can either do a naive merge, make the function more complex so you can configure the merge, or document that it doesn’t work for unions with the same keys

noonian03:12:20

yeah, thats what I mean. It works in the case you just posted because the queries for :t1 and :t2 do not have “overlapping” keys

tony.kay03:12:53

ok, what if :t1 is a singleton and :t2 is a collection?

tony.kay03:12:10

or both singletons

noonian03:12:22

there is no “is a” basically because they only exist in the queries

tony.kay03:12:40

you get a real response, and rewrite should work in a consistent manner

noonian03:12:04

right, but :t1 and :t2 won’t exist in that response

tony.kay03:12:04

if I get two singletons, I cannot put them both at the same spot

tony.kay03:12:14

nor would I want to...they go to different places in the app state

tony.kay03:12:18

(if normalized)

noonian03:12:54

I don’t think you can have a response where they aren’t singletons since its just a map. i.e. promoting a root implies its a singleton

tony.kay03:12:31

no, I don't thnk it does...your own test query implies to-many. Perfectly fine for a union to be asking to a hetero list of items

tony.kay03:12:43

that is the union tutorial on the Om site, in fact

noonian03:12:46

correct, but if you promote the values of the sub-queries of that union, then it wouldn’t make sense because in the remote response the top level keys from each item would somehow have to be repeated in the servers response which is a map

noonian03:12:05

promoting a union itself makes sense for the non-singleton case, but this is also not currently supported

noonian03:12:20

the test you already have for unions tests that the response is a singleton

tony.kay03:12:40

the response, I believe, would work in either case with rewrite

tony.kay03:12:54

list or single

noonian03:12:55

what would a response look like that has a non-singleton?

tony.kay03:12:07

a vector, what else?

tony.kay03:12:21

like I showed above

noonian03:12:23

the response would be a vector? I thought that wasn’t allowed?

tony.kay03:12:42

the response to the UNION keyword portion of the query

tony.kay03:12:55

{:k [{} {}]}

tony.kay03:12:14

see 7:37pm comment

noonian03:12:29

right, but you wouldn’t have that key if you promoted the queries from the unions sub-queries

noonian03:12:41

using that example [{:k { :t1 [:a] :t2 [:b] }}]

noonian03:12:18

if :a was {:a [:id]} and :b was {:b [:name]}

noonian03:12:40

and those were the queries annotated with {:query-root true} meta data

tony.kay03:12:52

that part is fine...you get two responses. fine

tony.kay03:12:59

but rewrite cannot possibly rewrite

tony.kay03:12:15

so now you're kinda on your own

noonian03:12:28

no, because they are promoted to root your response is {:a {:id 17}, :b {:name “Foo”}}

tony.kay03:12:38

not arguing that

tony.kay03:12:49

talking about what you give to the callback, via rewrite

tony.kay03:12:01

rewrite is a functon that process-roots is writing for you

noonian03:12:05

ok, so if :b request [:id] like :a does, there is no way to express the non-singleton case in the servers response

tony.kay03:12:40

server response: {:a [{:id 17} {:id 18}] :b [...]}

noonian03:12:42

{:a {:id 17}, :b {:name "Foo”}} is the value of the singleton at :k agreed?

tony.kay03:12:44

non-singleton

noonian03:12:57

yes, :a and :b could be non-singletons

noonian03:12:07

but it forces the union to be a singleton

tony.kay03:12:17

right, and rewrite has to put them both back at UI key :k

tony.kay03:12:37

because that is the UI join key

noonian03:12:04

yes, I think we are agreed and both were talking about two different things?

tony.kay03:12:34

possibly...I'm talking about making the API of process-roots consistent across queries...corner cases like this do not seem to be a proper case

tony.kay03:12:58

bcause it acts differently for different kinds of queries

tony.kay03:12:19

in one case rewrite is broken (or in need of extra help). In all others it is automatic

tony.kay03:12:27

your application use-case does not a library feature make

noonian03:12:58

heh, I think its a little broken already

noonian03:12:09

but I agree

tony.kay03:12:10

for unions, it is

noonian03:12:27

but I’m trying to understand those cases

noonian03:12:04

is the broken case you are talking about when :a and :b request joins on the same keys with different values?

tony.kay03:12:20

so, come at it from the two basic uses of a union: I want to switch on a singleton, where I have an ident in my app state that alters the query when I alter the ident.

tony.kay03:12:44

the other is I want to read a single list of hetero items

noonian03:12:28

I believe the semantics for the second case are not affected by my change. If you were reading single list from the server then you would have to promote the union with the key identifying that list.

tony.kay03:12:44

no necessarily

tony.kay03:12:04

ah, take that back

tony.kay03:12:11

that is an app-specific case, so you are right

tony.kay03:12:19

promote the entire union

tony.kay03:12:34

in the singleton case, your app-specific desire is to preload something that is not yet in the UI query

tony.kay03:12:48

(since the ident can only point to one type at a time)

tony.kay04:12:01

so that is a prefetch concern

tony.kay04:12:13

and not a concern of queries that are in the UI

tony.kay04:12:26

For prefetch, there is nothing stopping you from writing a side query, sending that to the server, and manually merging it on return

tony.kay04:12:35

no re-rooting needed

noonian04:12:36

I see process-roots as just a utility function trying to solve a common problem, so imo if you document its behavior then should be good. I think we need more tests and would not be surprised if there is a usecase we aren’t considering. I’m not quite sure what you mean with prefetch, I plan on using process-roots in my send function which may be triggered by the reconciler

tony.kay04:12:11

I mean that only one branch of your UI can be shown at a time...you're using the union for a UI switching concern, right?

tony.kay04:12:19

and only one of those things is shown at once.

tony.kay04:12:27

So, you are prefetching the non-visible side

noonian04:12:06

Ah, yes. And also I can even ensure that I only ever have a single branch of the union. But it would be nice if it worked in the general case.

tony.kay04:12:09

if you want that, why use a union at all? Why not just have a bit of app state that causes your render to only render one side and just have two joins?

noonian04:12:18

well, I’m not manually triggering a fetch

noonian04:12:31

just returning remote ast’s from my reads

noonian04:12:32

I’m just trying to explore the routing usecase of a union query. I would love to have some app state that determines which side to render (and which queries to use for data) but it is hacky (in my limited experience with om next) to get that working if you want to keep your app state in your app state atom and not in your component instance.

tony.kay04:12:20

I'm kinda out of time tonight...think through it some more. I think you don't want a union, and I disagree with the general idea of promoting more than one bit of the union. The app state approach is pretty simple, and I'm never using component local state...I want it all in the atom. All that said, I'm ok with the patch, and less ok with the test...I think promoting more than one bit from a union is a hacky thing to do that should be discouraged, since it breaks rewrite, but possibly not denied, since you should understand the implications and deal with the fallout if you want to use it that way.

tony.kay04:12:04

the tests should be in pairs to prove that rewrite works for the response

noonian04:12:07

wouldn’t you want at the very least all keys from a single branch of a union?

noonian04:12:14

I agree we need more tests

tony.kay04:12:43

I think once you've chosen a branch, the semantics of process-roots as they stand work out.

noonian04:12:44

anyway I opened the PR so we can discuss, no rush on getting it in there

tony.kay04:12:03

sure, I really appreciate you working on it

noonian04:12:10

so in other words, pre-filter you unions to a single branch before using with process-roots

noonian04:12:14

I’m cool with that

tony.kay04:12:14

I have not had time to work on half of what I'd like simple_smile

tony.kay04:12:51

The way I was going to write it was as follows: - Treat each branch as a join on the join key...as if it were just another join (and not a union) - If find a root, make that a root, and add the join key to rewrite for that

tony.kay04:12:02

once you've found one, stop looking

tony.kay04:12:11

since rewrite can only rewrite it once

noonian04:12:58

why can rewrite only do it once? well, feel free to take off if you have to 😛

tony.kay04:12:08

yeah, gotta go...talk more later simple_smile

noonian04:12:17

anyways, changing the apply concat to just pass the single branch is all that change would be

rburns04:12:05

Is my understanding correct that the indexer and merge functionality are the only parts of om.next that influence or access directly the application state? ie. outside of those concerns, the implementation of the app state is arbitrary.

noonian04:12:47

Well, it has to implement IAtom at least lol. I suspect there is only one person in this chat room qualified to answer that question authoritatively.

noonian04:12:08

And he’s probably asleep

johannjohann04:12:08

also when you change a component query dynamically

rburns04:12:13

thanks for the hints

mudphone04:12:19

Is there a good tutorial or writeup on how to do nested components in Om.next? Like how IQuery works and transact?

mudphone04:12:39

I’m getting Assert failed: transact! invoked by component [object Object] that does not implement IQuery and want to “read the docs"

johannjohann05:12:00

have you checked out the wikis

mudphone05:12:46

I’m probably missing something

johannjohann05:12:10

yeah no worries simple_smile

johannjohann05:12:32

(we all are lol [not a diss on om next but a general acknowledgement to human ignorance at large)

johannjohann05:12:13

so basically when you transact!

johannjohann05:12:24

om next wants to walk back up to the parent node, see if any of the parents of the transacting component want to manipulate the tx at all

mudphone05:12:45

@johannjohann: thanks, looking at the source helps to demystify this

mudphone05:12:05

I’m just failing the (assert iquery?…)

mudphone05:12:19

i need to figure out how to next my queries in a sensible way

mudphone05:12:11

sorry, no context,… I’m assuming it’s my responsibility to pull the right data in the queries, and pass the right data down to the nested components...

kahunamoore06:12:35

Any good/simple om next lein templates to recommend?

smeister10:12:33

How can i make the query of a parent component update after set-query in a child? I have a join in the parent component with value (om/get-query Child), yet the parent component's query does not change. Do i misunderstand something?

nblumoe10:12:03

When doing a mutate to a remote, how could I also have (a related, but different) local change before sending the data off to the remote? I tried using :action in parser/mutate but this results in the UI only being re-rendered for the local change, but not when the remote response arrives and gets merged (which works flawlessly when removing :action). The weird thing is, the same, unexpected behavior occurs when I move the expression from :action out to a dedicated, separate mutation function in the parser. How would you solve that?

nblumoe11:12:43

(like in the examples with optimistic updates, I am using swap on the app-state directly, which might cause the trouble... trying to use merge now...)

smeister11:12:36

It did a similar thing and it should work. I even set the same keyword, once before sending it off, and once after. It correctly re-rendered both times.

wilkerlucio11:12:07

@nblumoe: are you using devcards?

nblumoe11:12:37

@smeister: with a simple :action (swap! state update-in .... you mean?

smeister11:12:06

wait - is this exactly your code? The mutation function should be side effect free.

smeister11:12:19

(add a hash before the parens)

nblumoe11:12:37

oops, yeah. no difference though ;(

wilkerlucio11:12:46

:action #(swap! ...

wilkerlucio11:12:12

@nblumoe: remember that your parser may be called multiple times, that's why you need to make it stateless

wilkerlucio11:12:31

but I undestand that might not be your problem now

wilkerlucio11:12:03

can you please paste this parsing method entirely in a snippet?

nblumoe11:12:19

sure, give me a second

nblumoe11:12:00

also should mention, that I am using a custom merge-tree, as I am retrieving data from a non-Om REST endpoint.

nblumoe11:12:13

(but I don't see this being the problem)

smeister11:12:41

@wilkerlucio: do you know if set-query should work on sub components?

wilkerlucio11:12:17

@smeister: I didn't played with set-query yet, I don't know

anmonteiro11:12:36

@nblumoe: are you specifying the keys you wanna re-read after transact!?

nblumoe11:12:41

(for once I though adding :value did solve it, but I was not able to make it work again. guess I was wrong on that)

anmonteiro11:12:44

I meant when you call transact! e.g. (transact! this '[(user/verify) :users/list])

anmonteiro11:12:05

Notice I have specified users/list to be re-read

anmonteiro11:12:58

:value in mutate is just an indication, Om doesn't use it in any way

nblumoe11:12:10

I did not have it in transact! so far, but adding it made no difference

anmonteiro11:12:12

Is the state being updated correctly after the server response?

anmonteiro11:12:45

Does your parser know how to read the data that's coming back from the server?

anmonteiro11:12:57

(When it is local, I mean)

nblumoe11:12:27

The state is being updated, yes. Just checked that. I see the local change, as well as the server response being merged in already

artemyarulin11:12:44

@nblumoe: Can you show the code from merge-tree?

nblumoe11:12:17

will also add the transformed server response being picked up by that

smeister11:12:28

I have a problem with the following setup: i have a component that functions like a state machine to handle login stuff. If it sees a marker with credentials in the app-state, it stops querying for markers and changes it's query to one asking for an auth token from the server. But the component never gets the result props, which are correctly merged into the state. Somehow the local read seems to get the old query, which still asks for markers.

glv14:12:13

Does anyone here have any advice for using a canvas element with om next? I need to understand how best to get access to the canvas when it’s first created, to draw on it. Then, in response to changes in app state, I may need to do further drawing operations.

danielstockton14:12:23

doesn't sound om next specific glv, you can probably look for examples with plain react

dnolen14:12:42

@glv that is a React thing. You just need to set a ref on the canvas element. You can use this ref to get a direct reference to the canvas node after your component as mounted.

glv14:12:00

Ah, OK. I was trying to figure out how to get access to the underlying canvas element from the om component, and landed on refs, but clearly didn’t get deep enough. Thanks.

dnolen14:12:06

@glv in Om Next you can do this by passing :ref in props

dnolen14:12:43

(dom/canvas #js {:ref “my-canvas”} …)

dnolen14:12:13

then in a life cycle method (om.next/react-ref “my-canvas”)

dnolen14:12:20

to get a handle on the Canvas DOM node

glv14:12:35

Gotcha. Thanks, that gives me a lot to work with.

dnolen14:12:34

@glv we’re just re-using React functionality, so there’s no recommendation over existing popular patterns already at play in the React community

smeister14:12:35

@dnolen how would i best go about dynamical fetching of data in sub components? I currently try to use set-query but the parent components seem to ignore the set-query of children

glv14:12:46

Yep, and I’m coming to React straight through Om, so I’m not as up on React itself as I should be. simple_smile

dnolen14:12:59

@smeister: just ask questions like that to the channel please

dnolen14:12:09

there’s a lot of people in here now that know the answer to questions

nblumoe14:12:33

Btw I am still struggling with the issue described above. Meanwhile I am sure, that the app-state gets updated correctly. However, if I swap anything into the state before I get the server response, no rendering gets triggered after the response gets merged in.

nblumoe14:12:44

Any hints about what to look for, if an application state does not trigger a re-render, even though queries seem to be correct and adding corresponding "read queries" to the call to om/transact! do not help?

jdubie15:12:09

why does

static om/IQuery
(query [this] …)
take this as an argument? also why is it a function instead of components just being initialized with a query? the way to change a query is by set-query! not by having (query [this] …) return a different query

dnolen15:12:49

@jdubie: because instances can have queries just like classes do

dnolen15:12:00

so the signature covers both cases

smeister16:12:05

Has anyone used set-query in a realistic use case with nested components? I probably misunderstand something here.

smeister16:12:50

How can the set-query propagate up the component hierarchy?

dnolen16:12:30

@smeister: you have subquery but this might go away

dnolen16:12:07

but you can use it in the meantime until it gets replaced with something with the equivalent functionality

dnolen16:12:57

@smeister: the other alternative is to just declare everything but defer loading

smeister16:12:11

thanks! i'll have a look at subquery

dnolen16:12:09

@smeister: the second option is probably easier

dnolen16:12:22

also you should ask people have be messing around with routing

smeister16:12:26

hm it sounds like it would get messy

dnolen16:12:38

a lot of people have worked around this issue in satisfactory ways

smeister16:12:52

like having some management stuff in the app state

dnolen16:12:53

the total routing is actually not a bad idea

dnolen16:12:59

this is how web applications work - it’s fine

smeister16:12:12

and then decide on that what to load in the read.

dnolen16:12:20

total query + deferred loads

dnolen16:12:36

whatever I come with up with to replace subquery will just be riff on this idea

jdubie16:12:50

"total query" means querying over all routes - even routes that are not displayed. then defer loading the ones not visible?

dnolen16:12:38

the point is that most applications know the total query

dnolen16:12:47

you’re just not dynamically making stuff up

dnolen16:12:00

unless you have some kind of magical DB the world has never seen

dnolen16:12:14

but people are getting distracted by co-located queries

dnolen16:12:28

that’s just a convenience / modularity thing

dnolen16:12:36

but routing / application total query is a global thing

dnolen16:12:41

so think about it as global problem

dnolen16:12:55

subquery is just kind of busted because it’s inverted

dnolen16:12:02

global change with a broken local interface

glv16:12:32

Thanks for the help earlier with getting access to the canvas … all working now.

johannjohann17:12:36

@nblumoe there's a watch on your state that will schedule a rerender, maybe adding some debugging when reconcile! is ran

smeister17:12:57

Here's a gist demonstrating my current approach. @tony.kay said it sounds like a bug that it doesn't work as i expect it to. https://gist.github.com/SMeister/8d5d2ce1cdbed25cd6bb

johannjohann17:12:26

gratitude toward the bug finders simple_smile

johannjohann17:12:10

set-query! swaps against your state

johannjohann17:12:37

which schedules a rerender and thats how it would affect the root

dnolen17:12:53

@smeister: as I said that won’t work

dnolen17:12:58

it’s not a bug

smeister17:12:26

ok thanks. that's what i thougt after what you wrote anyway

dnolen17:12:31

I really don’t recommend trying to sort out routing yourself if you’re not comfortable with Om Next

dnolen17:12:43

it’s a terrible place to start

dnolen17:12:48

since there’s no obvious way to do it

dnolen17:12:00

other people have figured it out so I would look at what they have done

smeister17:12:06

routing isn"t really my problem, it works just nicely

smeister17:12:14

it's only the deferred loading stuff

dnolen17:12:50

@smeister: ok but if you’re expecting the changed query to visible from above without using subquery it won’t work

dnolen17:12:17

and trying to do routing without understanding this will just cause problems

smeister17:12:19

i just want to see it in the read function for the component, where it isn

dnolen17:12:46

in general I would recommend tackling only one concept at time

dnolen17:12:54

you should examine deferred loading in isolation

dnolen17:12:02

people keep trying to do 4 or 5 things at a time

dnolen17:12:07

without understand even one of them

dnolen17:12:14

you will just get stumped

smeister17:12:56

yeah like i said, i thought the routing stuff would work and went on to deferred loading, but didn't think about the subquery thing. Thanks for the answers, i'll try do it that way.

smeister17:12:12

And isolate it

jplaza17:12:15

Probably a newbie question, but I’m experiencing a weir behaviour, I’m using om/transact! and then swap! in the mutate fn, just like in the tutorial. But components won’t re-render on the first click, it always re-render when clicking the 2nd time

jplaza17:12:33

Never mind, it’s working now. Was probably because I was using (println ) inside the mutate fn

wilkerlucio17:12:40

I'm using the basic parser infrastructure of Om.next to create an async parser, my parser is only going to be called by me (not by Om directly), what I'm doing is returning channels as values and then managing to wait and read those. it works fine for reads, but when I tried now to use with mutations I got into a problem because of this assertion: https://github.com/omcljs/om/blob/master/src/main/om/next/impl/parser.cljc#L213

wilkerlucio17:12:35

since I'm returning a channel Om doesn't consider it a valid value, but if Om.next didn't enforced it would work fine for me

wilkerlucio17:12:52

@dnolen: any chance to remove this assertion?

dnolen18:12:00

you cannot return a value for a mutation that isn’t the permitted map

dnolen18:12:31

but we put the :result of the mutation into the :value map so you can get your channel from there

wilkerlucio18:12:31

ok, wrapping in a key like you said can make it work, thanks

henriqueqc18:12:30

I'm using om 1.0.0-alpha28 and ReactDOM is undefined. [cljsjs/react-dom "0.14.3-1"] is listed as a dependency,

henriqueqc18:12:18

Any ideas? The error happens when om tries to use ReactDOM to render. root-render #(js/ReactDOM.render %1 %2)

dnolen18:12:52

@henriqueqc: are you actually requiring om.dom?

dnolen18:12:01

you cannot just require om.next

henriqueqc18:12:23

yep, om.dom :as dom

dnolen18:12:14

I would examine your environment more closely

dnolen18:12:20

no one else has reported this issue

henriqueqc18:12:45

Ok, I'll check it more deeply

dnolen18:12:06

@henriqueqc: a good starting point is to follow the tutorial instructions word for word

dnolen18:12:19

then determine what is different between the tutorial and what you are trying

henriqueqc18:12:48

I'll look for diferences in the generated js output.

dnolen18:12:46

@henriqueqc: I don’t the generated output is going to tell you anything

dnolen18:12:51

this just sounds like a project config issue

thosmos19:12:28

@henriqueqc: I'm also using alpha28 and had something like that which I think was resolved by adding [cljsjs/react-dom-server "0.14.3-0"] to my deps.

henriqueqc20:12:32

@dnolen: @thosmos Ok, I figured out what was going on. If you have a dependency before om on the dependencies vector that depends on react 0.13 (before 0.14 where they added react-dom), lein will keep react at version 0.13 and use react-dom version 0.14 from om-next.

henriqueqc20:12:50

For the record, here's a discussion on how lein chooses the versions based on the ordering of the top level dependencies: https://github.com/technomancy/leiningen/issues/1337

henriqueqc20:12:46

Unfortunately the only way to see the warning that react-0.13.3-0 is being used is to run lein deps :tree.

Daniel Jomphe20:12:28

Hi, has anyone successfully provided an example of integrating Om Next + DataScript + DevCards?

Daniel Jomphe20:12:47

I've been able to integrate any set of 2 of those, but not the 3 together. I'm no master in either of those, so I'm thinking of dropping DataScript out of the equation for now.

Daniel Jomphe21:12:09

Another reason I might drop DataScript for now is I'm not sure at all how I'd be able to handle this complexity, e.g.: 1. Let's imagine a form with a first name input field. 2. We reconcile the field's onChange to DataScript, which... transacts each key pressed on the keyboard, in order for it to be displayed back in the field. 3. If I add a remote, I'll have a remote API call sent out after each transaction... that is, unless I could clarify the workflow to only call the remote when the form is submitted. But then... 4. ...I'd need to manage 2 state stores: a regular one to record what's in the form fields, and the DataScript store upon form submit, including remote call. So I'd end up having to deal with manual copying between them.

iwillig21:12:25

Maybe someone can help spot what i am doing wrong. I have a bunch of om.next Components and everything seems to be normalized correctly. I just added a new component and the data associated with it is not being normalize, let me post the code

iwillig21:12:44

specifically the customers table is not being normalized on line 329 https://gist.github.com/iwillig/3a74aaa66c66a2623a99#file-admin-cljs-L329

iwillig21:12:53

thats what my reconciler looks like

iwillig21:12:02

is there anyway to have om explain why a table why a table was not normalized ?

dnolen21:12:42

@iwillig: if something doesn’t get normalized that’s because your data does not match the query

iwillig21:12:21

got, thanks !

Daniel Jomphe21:12:41

no namespaces in the query attributes, right?

iwillig21:12:32

is that an issue ?

Daniel Jomphe21:12:02

I don't think, but it seemed irregular compared to your other components.

iwillig21:12:57

yeah this is because its from a different data source and not datomic

iwillig21:12:59

oh got it… I was return a list object in transit and not a vector

adammiller21:12:13

@danieljomphe: as far as your #2 above I typically store that data in the local component state then upon submission of the form is when i’d fire my mutation of the app state

dnolen21:12:22

@iwillig: yeah vectors and maps only for anything involved in queries

iwillig21:12:40

cool good to know

Daniel Jomphe21:12:58

@adammiller: ok this makes sense; I assumed we should walk away from component local state but who wants to track each key press... I'll try that, thanks

adammiller21:12:58

yeah, some say put everything in app state and I can see that there are some benefits to that…if you do that you’d just want a mutation call that didn’t have a remote: true part to it.

Daniel Jomphe21:12:18

> a mutation call that didn't have a remote So that on each key press, only the app state is (locally) mutated, and on valid form submit, remote is sent... ok this would make sense and this way, things would be much more symmetric. Thinking about it more, DataScript doesn't keep history, so it doesn't seem to be a big deal anyway to have it transact each key. (And if we want some kind of history, anyway, Om is already tracking app state mutations.)

thosmos22:12:30

@henriqueqc: in my case, when I remove the [cljsjs/react-dom-server "0.14.3-0"] dep, then I get this error No such namespace: cljsjs.react.dom.server even though my Om deps look like this:

[org.omcljs/om "1.0.0-alpha28"]
├── [cljsjs/react-dom "0.14.3-1"]
├── [cljsjs/react "0.14.3-0"]