Consider adding pluggable "middleware" support.

[davepeck]

There seem to be multiple types of middleware that we could support:

1. Middleware that participates in the instrumentation of the t-string, before parsing into a placeholder DOM tree
2. Middleware that alters the post-parsed placeholder DOM tree (these alternations could be cached, just like the placeholder tree)
3. Middleware that participates in substitutions of content values, attribute values, and/or component invocations
4. Middleware that alters the final post-substitution DOM tree (outside of the cache)

@pauleveritt I know you've thought a lot about this. Based on our previous conversations, I think your primary interests are probably (a) "participate in component invocation" and (b) "modify the placeholder DOM tree"?

There are a few ways that we could configure such middleware, but the simplest might be to add a bunch of keyword-only arguments to our html() function like instrumentation_middleware=... that takes a callable and... does stuff? Would need to consider how each of these offers plugability.

[pauleveritt]

I view "middleware" as separate from customizing the component lifecycle. But I could be talked into it.

Let's say our vision is to create a broad ecosystem of pluggable themes, components, tooling, etc. Then perhaps we do need to standardize on a couple of lifecycle points.

[pauleveritt]

But I don't think it should be part of the html() call. Then, everybody who makes an html() call needs to repeat the arg passing, all the way down the component tree, including 3rd part components.

[ianjosephwilson]

One thing I was experimenting with was using the "class" components as a place to provide "hooks" that would affect the children and/or rendering within those tags. Right now they are just created and then immediately passed into the the processors and _call__ is executed.

I'm not sure what mechanisms could exist for determining what is or isn't a regular component function but I was thinking maybe something the doesn't return a Template or some other detectable return type. Using the current usage would be convenient but I'm not sure if that is too magical. Ie. You put in the wrong return type and the error makes no sense at all.

Alternatively isclass might work but that doesn't allow for arbitrary factories.

A third option might be some "special" attribute, like __tdom__ or something that provides some information about what to do, ie. other methods to call to get more information or some configuration to use.

Finally, maybe as a compromise the "special" attribute could be checked if the return value, cached with the callable_info, didn't make sense.

[pauleveritt]

Sorry, I didn't get back to this. FWIW my middleware stuff has placeholder lifecycle phases. Your class-based approach could have method names to match.

For isclass I think I put in svcs-di a special __svcs__ (or intended to) to have a classmethod that would get called, if it existed, to do the construction. In my case, it would be passed the container. That kind of matches your __tdom__ special protocol suggestion.