Fork me on GitHub
#untangled
<
2017-03-16
>
wilkerlucio13:03:29

@tony.kay we are starting a new project from the template here, when we used the bin/rename-project.sh it created duplicates of most of project files, adding "" to the end of the file name, is that expected?

tony.kay16:03:25

Yeah, the rename is broken.

tony.kay16:03:41

sorry about that. Would love a patch...just have not had time.

adambrosio18:03:36

Taking a look, it seems like a patch about compatibility with older versions of sed is causing this, ill try to have a patch here soon

macrobartfast18:03:25

figwheel isn't reloading the devguide; what's the most common cause of this (playing lotto here)?

macrobartfast18:03:49

watching devguide in figwheel; ran (clean-builds); no dice yet.

macrobartfast18:03:44

shows 'figwheel: socket connection established'.

macrobartfast18:03:17

ran the repl with 'JVM_OPTS="-Ddevguide" lein run -m clojure.main script/figwheel.clj'

adambrosio18:03:49

@wilkerlucio i just pushed a patch that should fix it, tested it locally

adambrosio18:03:11

@macrobartfast i cannot reproduce, i just ran your command locally

macrobartfast18:03:36

@adambros thanks, and stand by... may have a solution in the works here.

adambrosio18:03:54

did you go to localhost:3449 ?

wilkerlucio18:03:09

@adambros thank you 🙂

macrobartfast18:03:21

@adambros I did... it looks like I'm editing a copy of the file that's not being watched... pebkap I think

macrobartfast18:03:55

@adambros stand by for 5 and I think I'll have it solved

rfhayashi18:03:11

@adambros, tested with @wilkerlucio and it worked, but it's not on the default branch "develop", could you merge there?

macrobartfast18:03:59

had been editing ./resources/public/js/devguide/untangled_devguide/A_Introduction.cljs instead of ./src/devguide/untangled_devguide/A_Introduction.cljs

adambrosio19:03:14

@rfhayashi woops! let me fix that, i will rebase as that was a total mistake, so make sure you force pull once im done

adambrosio19:03:04

@rfhayashi @wilkerlucio ok rebased so develop & master should be correct now you will have to force pull if you’ve been following along with me

therabidbanana22:03:08

So I'm finding that where (om/transact! this '[(widget/new ~(om/tempid))]) works as expected with regards to tempids, (om/transact! this '[(widget/new ~(om/tempid)) (widget/new ~(om/tempid))]) only resolves the second tempid.

therabidbanana22:03:42

Is that expected, and if not, is that more likely on the om.next or untangled side?

gardnervickers22:03:16

@therabidbanana Are you using a backtick for the macro quote? `

adambrosio22:03:54

doesnt seem like the problem if '[(widget/new …)] works

adambrosio22:03:48

@therabidbanana i would think the problem is with untangled-client, probably the networking related code

tony.kay22:03:05

@therabidbanana So, the problem is responses from the server come back in a map

tony.kay22:03:26

so sending both of those in a single transaction will end up with both going, but only one can response because there is only one slot in the response map

tony.kay22:03:32

for 'widget/new

tony.kay22:03:52

{ 'widget/new { :tempids { old new } } }

tony.kay22:03:11

and our server handling code isn't smart enough for that case

adambrosio22:03:29

wouldn’t you expect it to just merge the tempids?

tony.kay22:03:29

so, this is a bug on untangled server's merging of tempids into a response

tony.kay22:03:34

yes, I would

tony.kay22:03:43

feel free to open an issue.

therabidbanana22:03:49

Sorry - was away - yes I'm actually quoting with ` but that was harder to show with slack syntax

therabidbanana22:03:41

Okay - thought that might be the case, somewhere in the server, but wasn't sure where to dig in more

tony.kay22:03:12

that function needs logic to look for :tempids (mutations can return anything else as well) and do merges on the tempids ONLY

therabidbanana22:03:12

Is the expected case to also merge all keys, or just the tempids?

therabidbanana22:03:21

Heh, one step ahead of me

tony.kay22:03:26

we can't assume we know what the others are

therabidbanana22:03:57

Stepping back - is this functionality that should work and doesn't, or is it generally unexpected to chain together mutations like this?

tony.kay22:03:07

so, I'd say that we have a sort-of unsolvable case here. If you invoke a remote mutation more than once in a transaction that wants to return values you'll have to override this logic

adambrosio22:03:44

*other than tempids

tony.kay22:03:48

we might provide a hook for people to customize it

tony.kay22:03:05

right, other than tempids, and many people will never need anything other than tempids

tony.kay22:03:24

and most won't need to invoke the same mutation more than once per xaction

tony.kay22:03:31

so, it should be a rare case

tony.kay22:03:55

so, I'd say fix the tempid logic, and wait for someone to have further need

therabidbanana22:03:00

Yeah - I'm only doing this because it seemed most straightforward - I could easily just write a new multiple mutation

therabidbanana22:03:15

I felt like based on the way transactions work it felt like it should work?

tony.kay22:03:16

we've got a ton to do here, so no horsepower will be given to this...will accept a PR though

tony.kay22:03:56

Your case should work the way you wrote it...we just didn't write the plumbing right because no one thought of the case

tony.kay22:03:43

except David Nolen 😉 I wondered why he wasn't auto-raising return values

tony.kay22:03:23

well, he could have auto-raised, but you'd still have to decide on the merging of responses