https://fulcro-community.github.io/guides/tutorial-advanced-minimalist-fulcro/#_routing combined with url routing or DIY routing with html history

Thank you!

ok, so we know it is a join (the query tells us that). The only possible values in the denormalized tree there is therefore a map (to one) or a vector of maps. Lists are technically “ok” data for a scalar (as are sets and anything else that you can encode on the wire). We are detecting that it is a join, and so I do agree with you that changing vector? to sequential? should probably be ok.

it’ll end up converting it to a vector in that case, and lists there are currently not working in any useful way, so I guess I’d accept it.

https://github.com/fulcrologic/fulcro/pull/519 @U013CFKNP2R @U6VPZS1EK would you be interested in trying to run 👈 in your applications to have a real-world smoke test checking that this change does not break something crucial?

Thanks Jakub. Very happy to try although my application very small.I'll see if it is possible to fetch your PR as a repo so I can use locally.

It was trivial to clone the repo containing the PR so I will try it now.

It all seems to be working, but of course, I have since switched my server implementation to return vectors... so will have to spend a bit of time undo'ing those changes and checking it works 🙂

Ok just did a search and replace across project and turned all resolvers containing vec and mapv into resolvers returning lists and your change has worked. I then switched back to Fulcro 3.5.24 and double checked that returning the joins as lists does not work.

Thank you! BTW with deps it should be simple to add the PR as a git dependency over original fulcro without cloning, by I don't know the right incantation 😅

I guess st. like

com.fulcrologic/fulcro {:git/url "" 
                        :sha "4b454ce796884c11c2572248bbdfd654ce653e47"}

I just cloned locally and used :local/root in my deps.edn

But you're right - I should have thought about just specifying the SHA.

Exciting, @U0522TWDA — I’ll give it a try tonight! Thank you, as I think this is a fantastic change that will make working with resolvers more forgiving of an apparently somewhat common error!

True but you won't be getting those from Transit

What about a remote that isn’t using transit? Such as one doing local loopback things synchronously, where the result of the resolver might direcly be placed in the result? It isn’t all networking, remember, it’s all generalized.

Once again you see far more than I do 😅

I understand that