search

laravel / folio

Page based routing for Laravel.
MIT License
568 stars 46 forks source link

[1.x] Custom Folio Extensions #71

Closed snellingio closed 1 year ago

snellingio commented 1 year ago

This is a first pass at making #70 possible.

It turns out, the FolioManager class has a $renderUsing closure. This PR makes it possible for users to tell Folio to actually look at other file extensions other than .blade.php.

(See renderUsing here: https://github.com/laravel/folio/blob/master/src/FolioManager.php#L25)

It's still unclear whether including a heavier "markdown" extension out of the box is worth it r/e the cost of complexity and maintenance. However, because Folio allows users to pass in a custom Render function, if we allow passing in of extensions, this will give end users the ability to extend this functionality themselves.

snellingio commented 1 year ago

A couple of thoughts:

  1. Technically it's possible to not have to do anything with Folio. You can close this issue if you don't want to work towards making Folio more extendable. I've wip'd a package together: https://github.com/snellingio/folio-markdown
  2. My approach on the package is bad, it technically duplicates all the work of the router. This PR is a much better avenue.
  3. The extension order actually does matter when passing them in if they overlap. Kind of sucks. We could make a note of it, sort it from longest -> shortest, or something else?
  4. The renderUsing is kind of a hack... because I don't really want to override the default Blade rendering, only custom extensions. So it might be more thoughtful to store a map of extension -> handler
  5. Some additional thought on things like the InlineMetadataInterceptor which really should be pulling from the front matter, instead of using PHP. I've done that in my package, but I've literally just swapped the singleton in the container.
  6. What extensions" do you support, and how? I really do think having .md by default out of the box is a no-brainer... but if you give a mouse a cookie... IMO this moves the package closer to VitePress or Astro territory, and inevitably someone will want to stick their images next to the markdown files.

In light of the above, I'm going to move this to draft status. And I'm leaning away from you merging this without more thought. I'm also open to someone taking a completely different shot at how to implement it.

I just want this feature 🙏

nunomaduro commented 1 year ago

Thank you for proposing this. We putting this on hold for now!