Astronomy and similar packages within Mantra - shared code between server and client(s)

[dtwist]

@arunoda, @jagi, @tomitrescak, @makstr —If any of you, in particular, feel your contribution here would help others too, please chime in. — Not to discourage anyone else with something to share, of course!

I've been reading about Mantra, toying with some examples, and exploring all the various repos on mantrajs over the last couple weeks—One thing that I've yet to wrap my head around is how I can incorporate the Astronomy package in such a way that I can share Astro models across client and server, while still adhering to Mantra's principal of strict client/server separation.

• Note: I'm using Astronomy as an example, in part because I do want to use it, but also because two of the available kickstarter repos include the package ^{1, 2} (though they don't actually incorporate any working code), and there have been vague references in Github issues across various repos about using it with Mantra. The same question would apply though to any number of packages that could serve a valid function on client and server.

I whole-heatedly agree with the principal of avoiding universal apps, and yet I am starting to get the (hopefully inaccurate) impression that Mantra is more like Dogma in this regard. Part of the reason I jumped into learning Meteor was the ability to share (appropriate) code between client and server. The idea of having a single canonical codebase for schema, validation and permissions across clients and server is a very big draw.

Would the solution be to maintain 1+n npm Mantra modules? One that contains core, shared code and another for each client?

Am I just completely missing something obvious?

Would appreciate any insights. :)

Cheers, David

[smooJitter]

I struggled with this as well (https://github.com/mantrajs/meteor-mantra-kickstarter/issues/26). Although I was enthused about using Astronomy + React via Mantra, I can't really see how much value it adds. For example both

• https://github.com/mantrajs/meteor-mantra-kickstarter/issues/26
• https://github.com/mantrajs/mantra-dialogue include the Astronomy package but other than defining Astro Classes, I can't see where Astronomy methods nor model invocations are called.

I suspect client side references to Astronomy classes would be found in Actions or in Method Stubs; however, the approach taken in the mantra-sample-blog-app (does not use Astronomy) seems more transparent. Furthermore, it seems that Astronomy, if not appropriately leverage, can lead to "side effects". Yet still, Astronomy can lead to random objects floating around without a local state manager. I am particular curious about whether Astronomy adds much value in the context of mantra+react-native, a setting with minimongo limitations. Perhaps Astronomy's value proposition is best appreciated in a Blaze or React w/o Mantra setting.

[lukejagodzinski]

I haven't used Mantra at all so I don't not exactly what discussion is about. I don't think that there should be any big problem when using Astronomy with any package/tool. Of course there are some limitations (some of them where fixed in 2.0) but overall it should work pretty well. Maybe if you could give specific example of the problem.

[zimt28]

@dtwist There seems nothing wrong with putting your Astronomy models in your lib folder and then importing them.

[dtwist]

@jagi Ah, sorry. I thought you had some familiarity based on comments I'd read in Astronomy issues threads. Mantra isn't a package or tool exactly, but rather an opinionated architecture. I'm quite certain that Astronomy can be used without any technical issues. I'm looking for the best way to incorporate it in a Mantra project so that I don't run counter to Mantra's organizing principles.

---

@smooJitter Sorry I missed that recent issue of yours. Those are the two repos I found too. The dialogue project looks to be a fork of the kickstarter. In both of them, while Astro models are defined in the lib directory, those files are not imported anywhere. Looks like work-in-progress to me. I pinged @makstr since he committed the change that added astronomy to the meteor packages hoping he know more about the intention there.

I agree that Astro models would be used in actions and method-stubs. Can you say more about what side-effects you see using astronomy?

---

@zimt28 Yeah, I'm coming to the conclusion that's the consensus approach. But it still feels at-odds with the idea of strict module separation, which is what I'm hoping to better understand.

---

Perhaps the issue is that I'm misreading the motivations behind, and intentions of, Mantra modules. In my mind the strict separation, the use of npm to distribute them and discussions of building up a library of re-usable Mantra modules over time implies a very loosely coupled system—Which seems to rule out using the library as described above to import dependencies. If modules had a set of abstract dependencies that we were required to provide through DI, that would start to make more sense to me.

All that said, I'm beginning to see other reasons why a truly re-usable Mantra component (outside of my own projects) is unrealistic:

• routing conflicts
• styling differences (bootstrap vs semenaticui vs bespoke, etc.)
• differences in dom naming methodology (bem syntax vs oocss, etc.)
• overlap in functionality between modules' varied dependencies (Astronomy actually being a good example, as compared to another module using collection2, or two modules using different routers)

Mixing any of these will make for a jambalaya of an app. (Now I'm hungry for cajun... : )

So, in summation, I still feel like I'm missing something fundamental...

[lukejagodzinski]

@dtwist ok cool :)