You can use (m/app my-fn ?x)
to apply functions to your data.
Glad that multiple rewrite rule worked for you. We are thinking more about if keys should match even if they don’t exist in the map in the next version of meander. It is a gotcha people often run into.
I think multiple matches is probably the best answer for what you are looking to do.
As follow up of yesterday, I’ve been able to create a pretty good mapping with your hints (`m/some` and m/app
). Now I’m running into the point that it is almost perfect, but not completely and I cannot easily find out. Mismatches are silently ignore. Not sure how to fix this. Here is my current mapping https://gist.github.com/jeroenvandijk/62e3a52550f3aef5b69e4f0e91b73d18#file-meander_import-clj-L19-L82 The original data is also linked in the gist if you are interested
Great thank you! I managed to get it working (probably with the worst hacks, given your feedback), but I’ll incorporate your changes
The next step i’m considering is flattening the datastructure. Eventually this data needs to be transacted in Datascript/Datomic db. I’m not sure if this is feasible, but given your Hiccup example I feel this might be possible. I’ll play around with this idea first
It’s easy to do something like that with search
👍
@jeroenvandijk how’d things end up?
Maybe I need to apply more strict mapping with m/some
for all the fields that I know will be there for certain?
m*/attempt
is what is silently ignoring things. That is the point of attempt.
I know you are doing that be because you are doing bottom-up which will match on things smaller than just maps.
You could add a clause that was something like to the very end of your match:
{& ?data} [:this-fell-through ?data]
To find out what maps are being ignored.I’m not really consciously using attempt 🙈, but now you are mentioning it. It makes sense that it is silently ignoring things. Without attempt it cannot work i’m affraid, at least nog in the recursive manner?
Your trick doesn’t catch the missing items. I’m guessing the data is being eaten at other levels. Ok I’ll need to study this better I’m affraid
But the trick does get me further when I disable other rules
Thanks for all the help!
Glad you got things working!
I rarely use the strategy namespace for stuff like this; I’d recommend using rewrite
and m/cata
if possible because it allows for much more control and will probably result in a snappier transform.
I took the gist you shared — which was awesome, thanks — and https://gist.github.com/jeroenvandijk/62e3a52550f3aef5b69e4f0e91b73d18#gistcomment-3301768 for you which seems to work out pretty well. Let me know if it does the trick.
I noticed that you were using m/some
on keys, use m/some
on the values. Also, for the "children"
key, use m/seqable
and m/cata
to recursively transform the values, this handles nil
automatically and avoids the need for separate rules. It will also make your output consistent i.e. you will always have :node/children
that at least will be an empty vector.
If you want to have more control over how children are rewritten, I can show you another technique.