New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Keeping init-key args around for a later halt-key! should be an implementation detail #25
Comments
Just for posterity: I also bumped into this limitation. It's not too hard to work around but certainly something people are used to as being easy coming from component. |
Thanks for writing up the conversation @aroemers! |
What do you mean? Component has the same problem, but worse, in that any dependancy with a lifecycle needs to be wrapped in a record. |
I mean in Component I have access to all values that I had access to when I guess the situation in Component would be similar if you would be allowed to return anything else than the record being started... |
In Component, |
@weavejester I think @martinklepsch is referring the the fact that, as a consequence of using records, you can have access to the original configuration bindings in all protocol methods no matter what you return from
That said, I'm so used to writing my components in record-based frameworks by assoc-ing on the original config map (like @aroemers's second example) rather than returning something novel, that I never really thought of this as an issue. |
This is now solved with the introduction of the |
Hi @weavejester,
As discussed on Slack, we talked about how integrant's
halt-key!
method could have access to the originalinit-key
arguments. It was the following example that spurred the discussion:How to access the
logger
at the???
inhalt-key
? A solution would be to have the following:However, in my opinion this exposes an implementation detail (
::datasource
wanting to access the logger, so the actual datasource is inside a map) to the "consumers" of this component.We discussed three possible solutions.
halt-key
's arguments to something like[_ pre-init-value post-init-value]
. Upside is, that this is fairly straightforward. Downside is, it's not clear how to do this without breaking backward compatibility. The example however would be changed to the following:Unref
protocol having anunref
function, together with some helper functions. Integrant will callunref
ifinit-key
's return value satisfies theUnref
protocol, before passing it to other components. For example:Or, with some helper function:
Benefits of this approach are backward compatibility and the developer can keep even more values than just the pre-init value.
::build
metadata on a system.As I also stated on Slack, I am just getting started with Integrant, so we agreed we would both ponder if this is an actual problem, and if so, what the best approach would be to solve it.
The text was updated successfully, but these errors were encountered: