add Podium context "invisible" getters for convenience and consistency

[digitalsadhu]

Overview

Here is a proposal to make switching between podlet and layout accessing of the context a little more consistent. I realise that they can't entirely be the same due to the need for fetch values to be respected in some cases. (eg. public pathname) but this seemed like a possible way to avoid the confusion when accessing context values in a layout route.

What?

This PR adds an "invisible" getter property (get only, no write, non enumerable) for each parser using the registered key as the property. Since these are non enumerable, they will not show up in any serialisation.

Why?

It's confusing to users to have to access context values via a snake case string that also must include podium- at the beginning. Eg. res.locals.podium.context['podium-finn-token']

Example

layout.context.register('finnToken', new FinnTokenParser());

app.get('/', (req, res) => {
    // this is confusing, especially when it's different in the podlet
    const finnToken = res.locals.podium.context['podium-finn-token'];

   // this PR makes it possible to do this
    const finnToken = res.locals.podium.context.finnToken;

  // but the context object will not show the getters
  const keys = Object.keys(res.locals.podium.context);

  /* keys:
  [
        'podium-public-pathname',
        'podium-mount-pathname',
        'podium-mount-origin',
        'podium-requested-by',
        'podium-device-type',
        'podium-locale',
        'podium-debug',
        'podium-finn-token',
    ]
    */
});

Caveat

If a parser is a function, the getter will still return the function, it will not call the function so there is still room for some inconsistency between the layout and the podlet.

[trygve-lie]

Yeah.. I totally see the need for this but I think we need to think a little bit further. Initially the context was not meant to be accessed in a layout server but the reality is that there is a need for accessing it in a layout also.

We also have a second need; defining logic during de-serialization. Currently the context let you define a logic for paring something into a context value (run in a layout), but we do have cases where we want to append logic on a context value upon de-serialization (run in a podlet). One example of such is handling jwt token (which is a custom parser internally at FINN) where we in the Layout create a jwt token which is put on the context but in the podlet this needs to be unpacked to be useful. Currently all podlets now need to do that unpacking them self and its being done in different ways. It would be very nice if this unpacking could be part of the context de-serialization process.

So, I would like a little bit larger rewrite of the context where we do as follow:

• The context module should be used in @podium/podlet to de-serialize context values.
• A context parser should in addition to a .parse() method, have a .unpack() (suggestions for a better name is welcome) method. The .parse() method is used to make a context value in @podium/layout. The .unpack() method is used to transform a context value (http header value) into something else in @podium/podlet.
• Upon register of a context parser in the context module, the property of the context on the context object on HttpIncoming.context should be defined. This so we create these in a static way instead of dynamically on each request.

It would also be very nice if we could make it so that we differentiate the built in context values in Podium from the custom context properties. Ideally it would be nice if a podlet could detect that on the request to a podlet there are custom context properties but the podlet is missing the required context parser to deal with it.

[digitalsadhu]

👍 sounds good.

[leftieFriele]

I really like this, as the difference is confusing when starting out with Podium, this will help moving between podlet and layout context easier 💯 👍