Clarification on importing vs. injecting

[ndarilek]

It would be nice if the spec could clarify when a thing should be injected vs. imported.

For instance, the context in the blog sample injects the Collections object it imports, but I've been importing it throughout my own app. Similarly, Meteor is injected into the context. I don't understand why it isn't imported instead. If it substantially saved on code then I'd get it, but both are a single line.

I recently refactored an app to Mantra, and every time I modularized a piece of code I wondered whether to import it each time I used it, or inject it into my context. It makes sense for a global like state, subs-manager or the like where you're creating an instance, but why Collections/Meteor?

[arunoda]

Okay. Here's the thing.

Every related to Meteor packages should be injected via the context. Basically, anything including collections.

That's only for the client.

In server, you can import them. Since there is no something called context in the server.

[fermuch]

Why is that? With Meteor 1.3 you can simply import a package from Meteor. Isn't it better to have an explicit import than a global dependency in the context?

[arunoda]

@fermuch yes that's true. But importing everything makes the project into un-maintainable state. (Yeah! In know, we can argue)

There are things we import like components and containers. Specially for anything in Meteor packages we do not import them inside in the context.

We do it for better testing isolating Meteor specific things into a single file. Trust me, Meteor packages will die sooner or later. That's why we built mantra in the first place.

[ndarilek]

Got it, so basically inject things you may want to mock out for testing and import the rest. Is that it? If so, thanks, that makes sense. Might be useful to lay that out in the spec. Whenever I moved something into Mantra, it was never obvious whether I should import or inject it. If I'm right then this helps.

[fermuch]

Ah, I see. I wasn't thinking about testing, and you are right.
Testing while importing something from meteor is hard, really hard.
Importing only NPM is a lot easier.

I am with you with this issue, @arunoda.

Em 30-03-2016 08:44, Arunoda Susiripala escreveu:

@fermuch https://github.com/fermuch yes that's true. But importing
everything makes the project into un-maintainable state. (Yeah! In
know, we can argue)

There are things we import like components and containers. Specially
for anything in Meteor packages we do not import them inside in the
context.

We do it for better testing isolating Meteor specific things into a
single file. Trust me, Meteor packages will die sooner or later.
That's why we built mantra in the first place.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#168 (comment)