Component Process API Remix

[ianjosephwilson]

• Add ComponentProcessor extension point with example test
• Drop middleware api, "component object capturing", for now.
• Alter prep_component_kwargs
  • take in additional args via provided_attrs
  • add conditional flags to raise on positional only arguments and/or missing arguments
• Factor out embedded template extraction to "clear up" component processing

[ianjosephwilson]

This is closer but we should consider the middleware "concept" in #119.

[davepeck]

@ianjosephwilson Thanks for teasing this out. I think I'd settle on merging this PR, and considering #119 for the future. The middleware object in #119 feels pretty abstract to me, absent specific user needs. LMK what you're thinking now that you've had a few days to mull it over.

(To be clear, I suspect we'll want to revisit context, middleware, etc. many times as more people use this library; I'm okay with future breaking changes here. In fact, I expect them.)

[ianjosephwilson]

@ianjosephwilson Thanks for teasing this out. I think I'd settle on merging this PR, and considering #119 for the future. The middleware object in #119 feels pretty abstract to me, absent specific user needs. LMK what you're thinking now that you've had a few days to mull it over.

Yeah I wish I was always right the first time but after multiple subtle refactors I think this division of functionality is pretty good. I wanted to make sure we had a "spot" for the middleware idea and it looks like that should work out if/when we need it. The only change would be that IComponentProcessor would need to be changed to handle components that return the "tuple[Template, object]" form of Components that supply middleware. That seems fine though.

I think we should merge it.

[pauleveritt]

I'm happy to report that Claude was happy to port my previous context integration thing over to the new API. I'm now back on tdom main.