@dhruv1 So here's a long-winded answer
I mean @dhruv1
The question I always ask about any tool is: What value does it provide me in this situation?
For Component, the short answer is: It provides dependency injection and lifecycle management.
Lifecycle management is obvious, and it doesn't appear that's your primary concern. (Though I will point out that you could create a resource pool for accessing App-B
, and then you would need lifecycle management. This isn't necessarily a good idea, but it's not necessarily a poor one either.)
The main benefit of dependency injection is: Flexibility.
You can dynamically configure how an interaction will occur at runtime.
So back to your scenario:
Idea1
: You've created a component that, I'm assuming, implements some protocol, and that can be swapped out with another implementation at any time.
Idea2
: You've created an implementation-dependent interaction. My-App
now must know 1) there exists a string that is a URL to App-B
, and 2) that string is contained in an atom.
My take is: If you're going to use a dependency injection scheme, make sure you're getting the full benefit from it. As far as I can tell Idea1
provides more flexibility than Idea2
.
That's not to say that you must use a dependency injection scheme. Some apps don't warrant that level of flexibility.
And I'm not sure what your use-case is.
But, if you don't need that level of flexibility, I would do the absolute easiest thing: (defonce url "http://...")
I should note that, in a professional setting, I would always opt for dependency injection. Most professional-grade applications have such a long lifespan that flexibility is key to longterm success.
One last observation: For Idea1
, you don't seem to need lifecycle management at all as it stands. I would just construct the record with a url (map->App-B {:url "http://..."})
and then mark it as a dependency of My-App
. I don't see what benefit associng/dissocing the url provides.