feat: automatically generate post ids

[paradox460]

Generates the post IDs from the title, if they are not specified by the frontmatter.

Generated IDs are the title, stripped of all non-alphanums, camelized, and prefixed with Post.

[mhanberg]

I think doing this has some potential edge cases.

If we compute the module name from something that the user might change during the course of writing their post, their will then be two modules wthat write to the same location, and one is stale and might win out.

one way to go about this is to save all the post modules in some kind of state or a cache, and before running the post extension again, purge those modules (think you would use :code.delete/1 and :code.purge/1.

Where do we hold that state? I'll leave that part to you 😎

[paradox460]

Looking at most other SSGs, they kind of adopt a "rebuild the world" approach, where all pages are purged and rebuilt every time a generate is handled. While that does have a generation time cost, which can become prohibitive on larger sites, it also saves you having to deal with stored state and such like that.

Since we'd, presumably, like to avoid the whole rebuild-the-universe, and adding a wholly separate cache via something like DETS seems a bit overkill, perhaps we namespace all posts (including those with custom ids) to a parent module, and then use :code.all_loaded/0 to see what's loaded at compile time, compare it with what modules we have on the internal posts list, and remove any that are not within the union of the two lists.

---

As an aside, I'm not seeing any .beam files being written for posts when i run mix tableau.build, and running it via IEx shows them as being file-less modules:

  {Update.Volume3, []},
  {Update.Volume4, []},

Perhaps the edge case only occurs when using the real-time serve option, and is not an issue during build?

[mhanberg]

Perhaps the edge case only occurs when using the real-time serve option, and is not an issue during build?

Yes, this was the case I was thinking of, I should have clarified.

[mhanberg]

I think the path forward for this is to start an agent or some process to hold the page and post modules, and then when when we create the modules on the next request, we purge and delete them using the functions i stated above, clear that cache, and then move forward.

and this is only for development, meaning mix tableau.server. I have already ran into this a couple times where you change the ID in the frontmatter, and then there are two pages, the real one and the stale one.

And when you do mix tablea.build, it just shouldn't matter

[paradox460]

I think I might have solved it, without needing any agent or other state keeper. Check out what I just pushed up.

Autogenerated posts are namespaced into AutogenPostID.

The caveats are:

The generated HTML pages aren't pruned. If you have a permalink that uses the title, i.e. news/:title, and are sitting at /news/an-awesome-post in your browser, and you change the title to An Even More Awesome Post, the old page will exist, but will not update.

I only purge/delete posts with autogenerated IDs. If you specify :id in your frontmatter, I leave whatever you put alone.

A way around the not-purging of manually specified ids is to namespace all posts, and do the comparison there.