Medium guides each post to have a Title and Subtitle. They are rendered
as the first two paragraphs: H3 and H4 respectively. If they exist, a
new PageConverter class extracts them and sets them on the page.
However, they aren't required. If the first two paragraphs aren't H3
and H4, the PageConverter falls back to using the first paragraph as
the title, and setting the subtitle to blank.
The remaining paragraphs are passed into the ParagraphConverter as
normal.
General CSS hygiene dictates that you shouldn't go beyond an H3 tag. H1
for the document title, H2 for section headings, and H3 for low-level
headings.
The CSS itself will take care of scaling the image height based on the
width. We still need to know the height to fetch the image because the
height is in the URL, but we don't need to render it in the HTML.
Example:
* Text: "strong and emphasized only"
* Markups:
* Strong: 0..10
* Emphasis: 7..21
First, get all the borders of the markups, including the start (0) and
end (text.size) indexes of the text in order:
```
[0, 7, 10, 21, 26]
```
Then attach markups to each range. Note that the ranges are exclusive;
they don't include the final number:
* 0...7: Strong
* 7...10: Strong, Emphasized
* 10...21: Emphasized
* 21...26: N/A
Bundle each range and it's related markups into a value object
RangeWithMarkup and return the list.
Loop through that list and recursively apply each markup to each
segment of text:
* Apply a `Strong` markup to the text "strong "
* Apply a `Strong` markup to the text "and"
* Wrap that in an `Emphasis` markup
* Apply an `Emphasis` markup to the text " emphasized"
* Leave the text " only" as is
---
This has the side effect of breaking up the nodes more than they need
to be broken up. For example right now the algorithm creates this HTML:
```
<strong>strong </strong><em><strong>and</strong></em>
```
instead of:
```
<strong>strong <em>and</em></strong>
```
But that's a task for another day.
The impetus for this change was to help make the MarkupConverter code
more robust. However, it's also possible that an Anchor can contain
styled text. For example, in markdown someone might write a link that
contains some <strong> text:
```markdown
[this link is so **good**](https://example.com)
```
This setup will now allow that. Unknown if UserAnchor can ever contain
any text that isn't just the user's name, but it's easy to deal with
and makes the typing much easier.
To enable the crystal formatting, the extension saves the crystal path
to a .nova folder. These paths are specific to my computer so I don't
need to store them in the repo
Instead of showing only: Click to visit embedded content
An embedded link now displays with the domain it's linking to: Embedded
content at example.com
This hopefully breaks up the links a bit so it'e easier to distinguish
between a bunch of them in a row (as long as they are on different
domains).
Instead of getting the full size image, the image can be fetched with a
width and height parameter so that only the resized data is
transferred. The url looks like this:
https://cdn-images-1.medium.com/fit/c/<width>/<height>/<media-id>
I picked a max image width of 800px. If the image width is more than
that, it scales the width down to 800, then applies that ratio to the
height. If it's smaller than that, the image is displayed as the
original.
Most images have a caption (or at least have the option of being
captioned). Instead of displaying the raw image, it's not rendered
inside a <figure> tag with a <figcaption> (possibly blank) as a
sibling. The <figcaption> can be marked up with links.
The API responds with a bunch of paragraphs which the client converts
into Paragraph objects.
This turns the paragraphs in a PostResponse's Paragraph objects into the
form needed to render them on a page. This includes converting flat list
elements into list elements nested by a UL. And adding a limited markups
along the way.
The array of paragraphs is passed to a recursive function. The function
takes the first paragraph and either wraps the (marked up) contents in a
container tag (like Paragraph or Heading3), and then moves onto the next
tag. If it finds a list, it starts parsing the next paragraphs as a list
instead.
Originally, this was implemented like so:
```crystal
paragraph = paragraphs.shift
if list?
convert_list([paragraph] + paragraphs)
end
```
However, passing the `paragraphs` after adding it to the already shifted
`paragraph` creates a new object. This means `paragraphs` won't be
mutated and once the list is parsed, it starts with the next element of
the list. Instead, the element is `shift`ed inside each converter.
```crystal
if paragraphs.first == list?
convert_list(paragraphs)
end
def convert_list(paragraphs)
paragraph = paragraphs.shift
# ...
end
```
When rendering, there is an Empty and Container object. These represent
a kind of "null object" for both leafs and parent objects respectively.
They should never actually render. Emptys are filtered out, and
Containers are never created explicitly but this will make the types
pass.
IFrames are a bit of a special case. Each IFrame has custom data on it
that this system would need to be aware of. For now, instead of trying
to parse the seemingly large number of iframe variations and dealing
with embedded iframe problems, this will just keep track of the source
page URL and send the user there with a link.
The basic idea here is to fetch the post with the medium API, parse the
JSON into types, and then re-display the content. We also have to fetch
each media object as a REST call to get things like embeded iframes.
