-
Notifications
You must be signed in to change notification settings - Fork 26
Replace paragraphs with line breaks in message output #834
Conversation
ec0d055
to
2e059e5
Compare
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #834 +/- ##
============================================
+ Coverage 88.08% 88.29% +0.20%
============================================
Files 161 114 -47
Lines 18167 16722 -1445
Branches 971 631 -340
============================================
- Hits 16003 14764 -1239
- Misses 1908 1929 +21
+ Partials 256 29 -227
Flags with carried forward coverage won't be shown. Click here to find out more.
☔ View full report in Codecov by Sentry. |
2e059e5
to
cab8b83
Compare
a9b654a
to
d0a6ad8
Compare
d0a6ad8
to
74337c9
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't have all the context but the premise makes sense, and intuitively approach taken with the implementation makes sense to me and seems like a good direction to bring things. Just a couple of clarifications.
We should probably merge #842 first or we may see even more paragraphs in the message content, maybe we can merge it in to re-run tests.
_ => ComposerUpdate::keep(), | ||
} | ||
} | ||
DomNode::Container(_) | DomNode::LineBreak(_) => match start_type { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we convert paragraphs to line breaks do we still need LineBreak
type internally in the Dom?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The function to add line breaks is deprecated and fell out of use at the point of doing #472 I believe, so the Dom shouldn't contain these nodes. However, the LineBreak
node is still being used to represent line breaks in the Dom immediately after parsing, before being post-processed into paragraphs.
This is a bit problematic because although we can expect that the Dom should no longer contain LineBreak
s, there is a lot of existing code that expects that it might which is effectively dead code and a maintenance burden.
Perhaps we can either
- Remove the
LineBreak
node and parse<br>
directly toContainer
. It will be the most effort but, after this PR, we have compatible tests to make this easier. There is also the question of whether this would put too much logic in the HTML parser. - Keep the
LineBreak
node but refactor it to something likePlaceholder(LineBreak)
, adding an invariant assertion that it should not exist in the Dom. We could remove any logic that handles this node type and replace it with anunreachable!
error.
What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for that. I'm ok with either option, was more trying to understand it's current use.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
dom | ||
} | ||
|
||
// Group consecutive inline nodes into paragraphs. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you describe a bit the needs to group consecutive inline nodes into paragraphs?
Is it that we are removing the linebreak type and adding the requirement of inline items to be grouped in a paragraphs, to simplify the implementation and assumptions we can make?
…into jonny/paragraph-to-line-break
It's a snapshot test that's failing and I downloaded both files, they both look the same(used an online tool to compare) and I can't see any pixels that change but the content is different. So I think we can just accept the new one. |
This reverts commit 9ed1a4f.
- Reverting snapshot as I think the latest difference might be because of running locally on my machine(maybe as it's intel chip). - Check if changing input to <br/>'s fixes it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Works on my Mac for this test (if using iOS < 17.0).
Also it's needed to update the other block quote test that way to preserve functional snapshot tests:
func testMultipleBlocksContent() throws {
viewModel.setHtmlContent(
"""
<blockquote>Some<br/>\
multi-line<br/>\
quote</blockquote>\
<br/>\
<br/>\
Some text<br/>\
<br/>\
<pre>A\n\tcode\nblock</pre>\
<br/>\
<br/>\
Some <code>inline</code> code
"""
)
assertSnapshot(
matching: hostingController,
as: .image(on: .iPhone13),
record: isRecord
)
@langleyd is there any change still needed on iOS to fix the test failures? And about #834 (comment), am I ok to open a separate issue? |
Kudos, SonarCloud Quality Gate passed! 0 Bugs No Coverage information |
Changes
Context
<p>
to represent line breaks in message output #832