scope thunks to allow managing resources

[jbolda]

Motivation

By scoping our thunks, we can rely on the context as set specifically in each thunk. With this adjustment, we can allow the user to pass a resource which we attach to a context. They may then use that provide()ed resource in any action which is created under this thunk.

A resource is specifically an effection-type resource. A relevant example would be a WebSocket connection or a worker, both of which are available in effection/x as a package.

Additional Design Notes

This pattern could also possibly be applied to the store. We could have resources at the "store level" which all thunks/apis would be able to use, or you could manage it at a specific thunk/api level.

[pkg-pr-new]

More templates

• vite-react
• starfx-parcel
• tests-rtl

npm i https://pkg.pr.new/neurosnap/starfx@64

commit: b731486

[jbolda]

Punting on a store .manage() for the moment though, as we really don't have a great place to handle / yield* the resources at the store. It is mostly a builder function which returns a .run to execute Operations in that scope.

I think if we want to enable that, we might have a scope one level above the store. Then the store would "register" in that scope similar to the thunks. This could also be a reasonable extension point where a store has the ability to .manage() or .create() a storage mechanism, ie immerjs resource vs yjs resource, etc. This extension point is in part inspired by this comment.

[neurosnap]

nice!