Scopes and how I used nested registries #46

pauleveritt · 2022-04-21T16:18:15Z

pauleveritt
Apr 21, 2022

I think @Finistere is interested in re-thinking scopes. I know @flisboac also had an interest.

I'll describe what I did in Hopscotch, informed by wired, in support of what I wanted for my Sphinxy-componenty project. It's not a request for something similar, just as FYI.

I approach this as layers: the framework, the app, a site, a plugin, and site customizations. When the process starts up, it loads registrations for each layer...actually, with some static config that loads first.

When you want a result for something -- either imperatively or via injection -- the target is looked up, instantiated, and cached.
This might happen once for the app process lifetime. But it might happen in a per-request basis.

Let's do an example. Let's say there's a logo component in the top left. All pages have it and it doesn't change. You something asks for the <Logo /> and it locates the right implementation, constructs it, and caches it. (In a perfect world, persistently.)

But the page heading is different. It changes from resource to resource. When you ask for a <Heading /> for a page:

There might be multiple Heading implementations... class DocumentHeading(Heading), class ImageHeading(Heading), etc.
The inputs to the implementation are different from page to page... /folder1/doc27 has a title for that document

Even Logo is weird. You might have some pages that don't have a logo, or override it for just that page.

In Hopscotch, I have nested registries. So something like this:

def main():
    site_registry = Registry()
    site_registry.scan()
    for resource in resources:
        resource_registry = Registry(parent=site_registry, context=resource)
        this_view = resource_registry.get(View)
        output = render(this_view)

The registrations are done once at site startup. (Though not necessarily. I could always do resource_registry.scan(). But it seems a too-dynamic idea.)

The child registry gets some information added into it that specifies the lookups. This is similar-ish to qualified_by for inject.get[Hook].single(qualified_by=Event.SHUTDOWN) in Antidote, but it continues into all future lookups while in that child registry.

Notably, the cache is "as local as you can be". Some results are in the child registry. They are thrown out when it is deleted.

This idea is full of holes. But maybe it prompts some good ideas. Kind of like SQL transaction and sub-transaction. Or Python nested context managers. Or Docker "layers".

But it's for sure hard. Especially if you want to adopt "push"....something changes, you find its dependants and update them, and their dependants, etc.

Sorry, long note. Thanks for listening.

pauleveritt · 2022-04-21T18:39:39Z

pauleveritt
Apr 21, 2022
Author

I'll give a companion usage, besides just caching: <head>.

Traditionally systems treat this as a template slot problem. Others are a little more advanced, such as webassets or fanstatic, but prove to be there own little micro-architecture.

With per-request state, a component can grab a stateful service and say "include this CSS file as a link" or "inline this JS in the head". That state accumulates, then at the end of the request, gets consolidated and generated by a template/component. Somewhat like middleware or a Pyramid tween.

But with more framework support, more advanced and useful patterns of pluggability and generation could emerge.

0 replies

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Scopes and how I used nested registries #46

{{title}}

Replies: 1 comment

{{title}}

Select a reply

Scopes and how I used nested registries #46

pauleveritt Apr 21, 2022

Replies: 1 comment

pauleveritt Apr 21, 2022 Author

pauleveritt
Apr 21, 2022

pauleveritt
Apr 21, 2022
Author