Feature request: Don't serve or export page when the page value is `nil` about stasis HOT 7 CLOSED

This is an interesting philosophical question. There are two reasons why I might be getting nil:

1. Intentionally, the page shouldn't exist
2. Unintentionally, I've made a mistake

The way Stasis works right now is not good in either case. For case 1) it breaks. For case 2) it gives bad error messages.

The backwards compatible fix would be creating good error messages. The breaking change would give us a more lenient API that's nice to use for case 1), but could result in some serious outage issues in case 2). Consider a rogue (some-> taking down the entire site.

Is there some way we could handle both cases without breaking the API? Maybe add an optional options parameter to these functions, making "nil punning" an opt-in feature?

from stasis.

My first thought when reading this was your last suggestion @magnars: Add an optional map with a parameter that specifies whether nils are expected or not when exporting. So 👍 from me!

from stasis.

@magnars @cjohansen Thanks for considering this! An optional options map would be great. I'll try adding that to the codebase. I should probably have it done in the next few weeks :)

from stasis.

@magnars @cjohansen

I started working on this and I need some feedback. I'm using :ignore-nil-pages? as an option name. I feel like there are two ways to go about this:

1. Include :ignore-nil-pages? in the current optional map that is used as the context.
   Pros: No added arguments to export-pages and serve-pages
   Cons: Possibly breaking change to someone already using that keyword, option is passed into the page functions and ring request maps with no clear benefit, just clutter.
2. Add another optional map just for Stasis options so the new functions will be like this: serve-pages [get-pages & [options new-options]]
   Pros: Surely won't break anyone, doesn't clutter context map and ring request maps
   Cons: Now there are two maps called options in the code.

I feel like option 2 is better because it 100% won't break any existing code, but there is a naming problem. Currently the first optional map is called options everywhere in the code, and I think if we're going to add another options map we should rename the former to context or config. context fits great with the code examples where the page functions accept an argument called cxt. Any thoughts?

from stasis.

What do you think of 1) with a namespaced key? :stasis/ignore-nil-pages?

from stasis.

@magnars I like that!

from stasis.

Ok the PR is ready for review 🤠

from stasis.