Skip to content
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

Access to parameters a component was started with #45

Closed
SevereOverfl0w opened this issue Oct 13, 2018 · 4 comments
Closed

Access to parameters a component was started with #45

SevereOverfl0w opened this issue Oct 13, 2018 · 4 comments

Comments

@SevereOverfl0w
Copy link

Very similar to #25. Perhaps also touching on #21.

I'm trying to print out some metadata about the running system in dev mode, namely running http server(s). My approach to this has been to query the integrant-repl.state variables system and config. However, I realized that (obviously) the config hasn't resolved ig/ref at all.

#21 would suggest that one solution is to have a printing-component, which has an #ig/ref to all components in the system (perhaps filled by a function which performs a transformation).

@weavejester
Copy link
Owner

For your particular problem, why not store the information you need in the system? So instead of just returning a HTTP server object, you could return a map like {:init-options {...}, :server ...}.

Alternatively, even though HTTP server objects aren't data, they can often still be queried to find information like the port they're running under, if that's what you want.

Another possible option is to define your own init and halt! functions that keep hold of the parameters. The Integrant functions are just one-liners that wrap build and reverse-run! respectively.

@SevereOverfl0w
Copy link
Author

For your particular problem, why not store the information you need in the system? So instead of just returning a HTTP server object, you could return a map like {:init-options {...}, :server ...}.

My reluctance to create a map is slightly aesthetic, but a big sell of integrant for me is that things don't need to be wrapped. Maybe this is something I need to concede on though.

Alternatively, even though HTTP server objects aren't data, they can often still be queried to find information like the port they're running under, if that's what you want.

The port was one part, the bit that was missing was the handler. I don't have access to that from my particular object. Using the handler, I can inspect it for bidi vhosts and use that to figure out which url(s) the user can find their application on.

Another possible option is to define your own init and halt! functions that keep hold of the parameters. The Integrant functions are just one-liners that wrap build and reverse-run! respectively.

That's an interesting idea to pursue. But does complicate integration with libraries such as integrant-repl.

@thenonameguy
Copy link

thenonameguy commented Dec 26, 2019

One way of doing this once you have an initialized system is to use this fn:

(defn conf-with-sys
  "Returns the configuration, replacing the references with the initated components,
  Same as what `ig/init-key` receives, just for the whole system."
  ([] (conf-with-sys integrant.repl.state/config integrant.repl.state/system))
  ([conf sys] (#'ig/expand-key sys conf)))

@weavejester
Copy link
Owner

This problem can now be solved with resolve-key, so it can be closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants