Testing with the protocol support is insanely cool

I love how readable it makes the tests

@mitchelkuijpers Thanks. Our practical experience has been mixed, but I'm pretty happy with the idea 🙂

you using Datomic?

I only use it for the client-side mutations for now I am about to learn if the serverside stuff is nice

the client-side stuff is the sweet spot for now

the server-side setup is too hard at the moment, and I cannot really recommend it unless you want to help refine that 😉

the idea is solid. The execution is too hard

I’ll take a look at that we already have a lot of plumbing for testing with datomic and setting up the right db state

So that might help us (just guessing)

ours is underdocumented, but the tempid/seeding support in untangled is really solid

for testing etc

the hard part is that we really should have an easier way to "process" the server mutations without involving so much. it's too tangled, unfortunately 😕

Do you guys have any experience btw with mocking (.preventDefault e) for now I have just moved it to a function that I can mock

exactly. That is something we should do better in spec if possible, but I haven't looked too hard at the problem yet

Seems like a very hard problem, and you can argue that you should put this kind of stuff in helper funcs

well, that and protocols are a problem

and inline

Yeah inline would be very hairy I think

Anyone interested in a minor contribution: the generate stubs that @wilkerlucio was talking about earlier is a problem in our figwheel setup. https://github.com/cursive-ide/cursive/issues/1532#issuecomment-257904363 If anyone wants to figure out the specific fix I'd be glad to put take a PR for it. Affects template, om-css, and about every other project in Untangled

@tony.kay fix: https://github.com/awkay/untangled-template-workspace/pull/1

@wilkerlucio figured it would be easy 🙂

thx

Even with :marker false, load-field-action still replaces the destination in app-state with nil/dissoc the key, when the read starts, and then finally fills it in with the value with the read finishes.

this causes UI to flicker as it first renders nil, then renders the value during a load, even though, initially the global app state had real values (from a previous load-field-action)

@jasonjckn on 0.6.0-SNAPSHOT? I thought I got all of those

if so, open an issue. It should be an easy fix. Maybe load-field-action isn't passing marker false through

haven't tested 0.6.0-SNAPSHOT, will do

is it fully backwards compatible with 0.5?

ok read the changelog, it looks backwards compatible, but deprecated api.

my co-worker tried 0.5.7 which had the marker false fix in the changelog, and he says it's still swapping in nil into global state during a loading phase

i will double check this on 0.6.0 tomorrow and file a bug report

I raised this issue in bidi, but haven’t seen a response

has anyone here dealt wit this?

https://github.com/juxt/bidi/issues/145

using tempids in bidi routes

@currentoor why would you want that to be in bidi itself? looks like you have exactly what you need to make it work

i might also just be reading your code wrong

aand i was reading it wrong

so i tried this locally and it worked:

you may be doing a few things wrong, but i would guess that your [[tempid :id] “/edit”] is what’s wrong

or you may not be doing the extend-protocol right

can you fully namespace methods in an extend-protocol?

@adambros i believe that works because you’re not giving id a type, so it just defaults to a string, which is not what I’m trying to do

this way types are enforced and encoded into the route

so it works with the built in types like long and uuid

so the [tempid :id] part is saying it should be transformed with tempid?

exactly

i want to be able to use tempid as a first class type

what i have works but it’s a hack IMO

but i can (om.tempid/tempid “asdf”) ;=> <#C06DT2YSY|om>/id[”asdf"]

yes you can, and i would like bidi to do that for me, by me implementing a protocol or two

just like it does for uuids

well i think i’ve exhausted my bidi knowledge then

sorry

no worries 😄

if i can get this working i might make an untangled-router 😅

we’ve got it in our app and it works pretty well

if you can or can*t* get it working?

not sure what you mean

did you mean, if i cant get this working i might make an untangled router?

oh wait i think i just misunderstood again

if i am able to figure out how to extend the bidi types to support om tempids, then i will try make a router for untangled, from the one we have in our app