Why return dom and not just vec of the parts to (map dom/mark parts)?

@holyjak The strings can be very long. I guess I'm pre-optimizing (which I shouldn't do), but it seems like with many sub-ranges it could be quite a bit of work for the client, and would be better to do on the server.

I'm in agreement with that,no? I wrote the resolver would return those sub-ranges, the client just maps mark over them.

I’d define an additional resolver and a mock attribute :thing/long-string -> :thing.long-string/parts , which can define the first as its input, and the latter as its output.

I don’t recommend overloading keywords, since they often have specs/other expectations. But making a defattr with an odd invented type like :array-of-strings is fine. Just don’t give is a schema and no db plugin with touch it, and if you have RAD render it, make sure you install a renderer for that type.

(defattr long-string-parts :thing.long-string/parts :array-of-strings 
 ...)

The RAD renderer could define the array to automatically get wrapped in the proper DOM elements. That sounds convenient. Thanks for the advice. A little off-topic, but I always feel a little tension about :a.b/c style keywords. I like to use auto-resolved kws from my RAD model namespaces, and using these dot extensions doesn't work with that strategy. Although, @U0CKQ19AQ, I notice you don't use auto-resolved keywords for any of the RAD demo code. Am I wasting my time trying to use fully-qualified kw namespaces that map to files everywhere?

So, couple of comments: 1. Since a namespaced keyword should have a single meaning (I sometimes break this rule, but try not to), then intention of the narrowing (for me) so to indicate a related meaning. So, :invoice/customer and :invoice.customer/subset seems pretty good. The alternative is :invoice/customer-subset, which has distinct advantages (it destructures into something nice and still works with ns aliasing). The disadvantage is that it is not clear how to go both ways with the transform. It is trivial to reverse the former to get the base attribute keyword, but the latter doesn’t work (e.g. :invoice/customer-status -> :invoice.customer-status/someething-with-hyphens). 2. I don’t use fully-namespaced keywords in my data models. This is true in my production code as well. Part of that was that Clojure didn’t have good ns aliasing (without having to have a namespace) before 1.11, and it was just a royal pain to do it, for pretty much no distinct advantage (other than an imagined “someday I might want to integrate with some unknown other company in a way where we share databases”), but if that happens then I likely sold the company and cashed out, and it is now somebody else’s problem, and they are probably going to hire people that don’t want to work in clojure and port the whole thing to something else anyway…so, why buy the trouble 😛

I’m first a pragmatist, and then a pessimist 😄

Okay, sounds like there's quite a bit of personal preference to this choice and trade-offs in both directions. I did notice in the new server-pagination namespace that the pagination resolvers should use such "narrowed" keywords, so I suppose that's one place where the choice does matter.

Right, I’m using them in the library. For search parameters as well. It simplifies RAD code considerably to just have a standard that is also easy to be sure goes both ways. So, I think they’re a win there for sure.

In the end I found mark.js which supports all my use cases through markRanges():man-facepalming: 🙂 I did search before starting on all the manual string processing, but for some reason my searches didn't produce that library.

https://pathom3.wsscode.com/docs/resolvers/#unsupported-batch > The process works fine with maps and vectors but not with sequences, lists, or sets. That's because the later data structures don't support indexed updates for the elements in them.

I've tripped up on that a few times. My understanding is that Pathom generally just works best with Associative collections so I just stick to vectors and maps.

Thank you. I'm pretty sure the lists are created from lazy sequences that I forget to turn into vectors. 😭😱

I don't think this is batching. I think it is rather that Fulcro simply expects vectors. Off PC so can't check code.

@holyjak Yeah, you might be right there. But returning non-vectors has tripped me up more than once when using Pathom on its own, so I stick to vectors. Is there ever a case where there would be some benefit to returning a list instead?

A good #pathom question :)

The benefit is purely one of convenience: lazy seqs are returned by many many things. The sequence is unambiguous, but it is tough to know what you’re going to get on the client from a lazy seq on the server. NOTE: You can easily install a parser plugin to fix this yourself. Just use wrap-parser, and then post-process the result before returning it and convert lists to vectors.

Or make a defresolver macro wrapper that checks your output and fixes it, etc.

It is probably also possible to fix tree->db to watch for those during normalization, but the expectation is definitely that a to-many result should be in a vector.

Great discussion, and glad to know I’m not the only person who’s been bitten by this. (Reflecting on this, I think what happens is that I map over a sequence returned from a database or whatever, and I forget it’s a LazySeq… …maybe I should get into the habit of using mapv in resolvers, or explicitly using vec at end of threading macro…) But knowing what I know (which I admit, isn’t a lot), I wish there were some defensive mechanisms somewhere in Fulcro (or Fulcro Inspect) to detect when this happens.

Thanks, all!

Tony, on the idea to wrap defresolver — based on advice on this channel, I typically use defattr instead of defresovler. Is there an easy way to wrap the resolver fn when using defattr? (And did I interpret the advice of using defatt over defresolver correctly?)

Hm, I got the opposite impression 😅 (prefer defresolver). But I might have missed this particular discussion...

You didn’t say if you were using defresolver, defattr with pco/resolve, or something else. I personally have security and improved code reloading baked into a custom macro for defresolver.

So in my project, I’d probably code it there…my second choice would probably be a pathom plugin

(Yes, I use defattr with pco/resolve — it indeed sounds like this is preferred, because of improvements you made over defresolver.)

Cc'ing @U066U8JQJ, because of the richness of discussion, instead of starting new thread in #pathom Thank you!

After a lot of experience using RAD I’ve found that I don’t use pco/resolve hardly at all, because it tends to lead to circular refs

I only use it when it’s trivial stuff that doesn’t need access to any kind of other project nses.

Oh! I think I misunderstood your previous reply — you use a defresolver, and specifically, a hardened version that is not included in Fulcro?

correct

security is kinda project-specific

but I want my macro to refuse to compile unless the security of a given resolver is defined

My add-ons: • Make resolvers hot reloadable (you can reeval them to update them without having to restart) • Add security enforcement • Auto-register themselves in a registry (so all I have to do is require the ns)

This also makes it so that if you add a new resolver you just need to load that ns, and reload the pathom ns (assuming you’re using mount which will restart the parser defstate)…again, instead of restarting completely.

https://gist.github.com/awkay/86a3d7b3be912f79961e7bffba91a6f2

It also adds tufte performance instrumentation around each one, which makes it much easier to find performance bottlenecks (if you do profiling).

The registry is just an atom holding a vector, with a register function that adds the resolver to it. Then the resolvers in the parser construction includes that deref’d atom

(Oh, the ability to not have to restart Fulcro! I almost want to weep, that sounds so awesome. In fact, I just fired up some code I wrote in kaocha , which reloads resolvers, so I can get faster feedback on changes to solve this problem…) (On our next call, I’d love to go thru this with you, and publish a sample project using it, because I’ve found it so useful: I started putting all the EQL queries as tests, to detect when I break things, with file system watching. And I’ve found it to be fantastic, sublime way to build out resolvers. So much easier than save file, reload all files, restart fulcro, manually send parse EQL to pathom.

hello, just joining the party 🙂 about collection types and Pathom, vector is for sure the favorite and should be used as much as possible. that said, Pathom 2 has some issues handling lists, Pathom 3 does a better job there, and will work with vectors, seqs and sets, except the batch thing (mentioned earlier here). one other thing that might confuse you when using lazy seqs is the pathom viz timeline, lazy seqs get wrong times because Pathom marks the end of a resolver after the resolver call, but if you get a lazy list, that means some heavy process might occur after the resolver is done running

@U0CKQ19AQ curious about the circular reference thing with defresolver, can you tell me more about it?

you misunderstand @U066U8JQJ. I have an option in RAD for defining a resolver on a defattr, but those are at the root of your data model and are needed everywhere, so defining a resolver that is likely to need other things there leads to circ refs. Nothing really to do with defresolver or Pathom in particular