dashbitco/nimble_publisher

Can I skip the markdown conversion?

g-kenkun opened this issue · 4 comments

The idea of this library is so awesome!
However, I would like to parse the markdown on the client side, not the server side. I'm currently running code from this library that skips the parsing process.
I'd like to add an option to skip parsing if possible, what do you think?

For example, something like this

use NimblePublisher,
  build: Article,
  from: Application.app_dir(:app_name, "priv/articles/**/*.md"),
  as: :articles,
  highlighters: [:makeup_elixir, :makeup_erlang],
  skip_parse: true # Default is false

This option is not supported at the moment. If we are going down this route, I would rather support multiple extensions. For example, .text and .markdown, and the .text is kept as is.

Surely supporting multiple extensions rather than skipping parsing as an option is the way to go in the future!

With that idea, the following process, for example

entries =
for path <- paths do
{attrs, body} = parse_contents!(path, File.read!(path))
body = body |> Earmark.as_html!(earmark_opts) |> highlight(highlighters)
builder.build(path, attrs, body)
end

It would look something like this

    entries =
      for path <- paths do
        {attrs, body} = parse_contents!(path, File.read!(path))
        body = 
          case Path.extname(path) do
            extname in [".md", ".markdown"] ->
              body |> Earmark.as_html!(earmark_opts) |> highlight(highlighters)
            
            _ ->
              body
        builder.build(path, attrs, body)
      end

or

    entries =
      for path <- paths do
        {attrs, body} = parse_contents!(path, File.read!(path))
        body = convert_body(Path.extname(path), body, opts)
        builder.build(path, attrs, body)
      end

  ...

  defp convert_body(extname, body, opts) when extname in [".md", ".markdown"] do
    body |> Earmark.as_html!(earmark_opts) |> highlight(highlighters)
  end

  defp convert_body(_extname, body, _opts) do
    body
  end

Exactly. The second version looks cleaner to me. PRs are welcome, Thanks!

@josevalim Thanks for responding after all this time! I've created a pull request, please review it!