Conversation
This made us able to do some unique things, like transforming content in our custom entities, that we were unable to do with our simpler approach.
| |> divvy_style_ranges(block["entityRanges"]) | ||
| |> group_style_ranges() | ||
| |> Kernel.++(block["entityRanges"]) | ||
| |> sort_by_offset_and_length_then_styles_first() |
There was a problem hiding this comment.
I'm unapologetic 😂
Unless you want me to be apologetic.
Then I'll be apologetically apologetic. 😏 🙇
|
Yeah aside from the one comment comment above I'm fine with merging this and tossing a refactor in the icebox. I would like to break this up further in the future so that this actually just builds the tree and then the lib user brings their own processor so that it can be used for rendering to non-html clients 🦄 |
| block["inlineStyleRanges"] | ||
| |> divvy_style_ranges(block["entityRanges"]) | ||
| |> group_style_ranges() | ||
| |> Kernel.++(block["entityRanges"]) |
There was a problem hiding this comment.
Alright took a little while to grok that the entityRanges weren't actually in the data until this point... I don't know if I have an immediate action point for this but I think this pipe could be a little cleaner. Probably no harm leaving it for the refactor you mentioned. Maybe a brief comment at the top would help though
2 participants
I did say "today" 😅
Admittedly I haven't worked with tree structures enough to know all of the paradigms, so there might be a way to write the
build_treefunction and friends that is a bit more idiomatic, fewer lines of code, and/or more logically recursive, I'd love to refactor to that end now that I finally have something working. 🎉