You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We discussed this in the daily sync and there are a couple of limitations with the current approach:
The type registry is effectively static for the lifetime of a module's execution, but the registry is dynamically constructed and requires a context.Context to use.
Related to 1, this implies that it cannot be used by methods that don't pass a context around, including the stdlib's encoding/json.
Currently the registry is only constructed in the generated main.go, which doesn't exist during tests, and thus the type registry cannot be used with ftltest at all.
A proposed solution is to:
Remove the existing context-scoped code and code-generation.
Modify the type registry to be globally scoped.
Extend the external_module.go template to register its types in an init() function.
alecthomas
changed the title
Discuss if global type registry in go-runtime is a good idea
Implement global registry + code-genned registration in the external_module.go template
May 22, 2024
We discussed this in the daily sync and there are a couple of limitations with the current approach:
context.Context
to use.encoding/json
.main.go
, which doesn't exist during tests, and thus the type registry cannot be used withftltest
at all.A proposed solution is to:
external_module.go
template to register its types in aninit()
function.eg.
This will automatically register the module's types whenever it is imported.
The text was updated successfully, but these errors were encountered: