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?
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